Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Technical Discussion

Technical discussion about ActivityPub-related topics.

108 Topics 954 Posts View Original
  • Is Zotum following FEP f228?

    fep f228
    2
    1 Votes
    2 Posts
    21 Views
    @julian (I replied to this from Hubzilla, but it doesn't seem to have showed up, so reposting from Mastodon... sorry for the duplicate)Yes, it does.I think FEP-171b is the relevant spec; Mike Macgirvin's description of Conversation Containers might be relevant too.It's running Hubzilla, which is already listed as an implementer of FEP-f228. @fentiger@zotum.net @silverpill
  • 2 Votes
    6 Posts
    27 Views
    NodeBB now sneaks in a mention to the category/community, and this gets pre-filled in the Mastodon composer. I tested it against piefed's crust instance, and the response from Mastodon to my post on NodeBB successfully made its way to crust for distribution :tada: @rimu@piefed.social [image: 1772652313700-020a80cf-d0b0-4fbf-aa5a-20b951a109ef-image.jpeg]
  • Re: Expanding collections on delivery

    4
    0 Votes
    4 Posts
    11 Views
    @julian If forwarded activity doesn't have a signature (FEP-8b32 or LD signature), you can fetch it by its ID. Mitra does this. Not all activity IDs are dereferenceable (hello Mastodon), but some are :)@trwnh @eyeinthesky
  • Expanding collections on delivery

    activitypub
    15
    0 Votes
    15 Posts
    34 Views
    @silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s(this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)
  • 0 Votes
    1 Posts
    8 Views
    RE: https://theforkiverse.com/@klemens/115915313316598172this person is working on a mac app specifically for #theforkiverse #fedidev
  • 0 Votes
    1 Posts
    9 Views
    #askfedi #peertube #makertube #spectravideo #activitypub #fediverse I've recently been trying to remote follow some accounts from my own peertube instance from https://makertube.net and https://spectra.video and at first it seems as though it's successful, but shortly after the subscription disappears.Is anyone else having this issue?
  • @julian that is why:

    2
    0 Votes
    2 Posts
    12 Views
    @julian @pfefferle ActivityPub spec says IDs are URIs, I think that means non-ascii characters should always be encoded.Mitra rejects IDs that are not URIs, most of the time this doesn't cause any issues (WordPress was the only notable exception).
  • WP group actor ID URL encoded?

    wordpress activitypub
    3
    0 Votes
    3 Posts
    18 Views
    @pfefferle@mastodon.social I'm frankly surprised I ran into a side effect of this so soon after you updated the site :laughing: Either the PR is to be reverted or perhaps WP should handle requests to the URL encoded address :shrug: But after briefing myself on the root cause, it does seem weird that there exist actors with unicode in their ID. Might be if that is the case you should disregard them as non-compliant, who knows. cc @silverpill@mitra.social
  • 6 Votes
    1 Posts
    13 Views
    I've seen hints of backfill working really well, but hadn't seen good examples until recently. As more and more instances upgrade to the newer versions of Mastodon that support context, backfill from Mastodon instances will improve across the board. Today one of the most popular topics on my NodeBB instance was an update from the admin of The Forkiverse, a brand new up-and-coming instance. Despite following only one person from that instance, I was able to see every single reply from that instance, even from users I don't follow. Super stoked to see resolvable contexts and backfill working in the wild. Who says the Fediverse is quiet? Not me, anymore 😅
  • Browser.Pub and Anubis

    browserpub anubis
    15
    1 Votes
    15 Posts
    47 Views
    @js otherwise please stop follow me if you do not want help. @julian
  • FEP-f15d: Context Relocation and Removal

    activitypub fep threadiverse
    6
    2 Votes
    6 Posts
    36 Views
    Hi @silverpill@mitra.social right; Move and Remove are explicit actions concerning membership of a context in an audience. Update is overly broad and receivers would have to infer audience change based on what the updated object contains (e.g. Audience Y is suddenly missing, and Z is new, was this always the case?) It is likely that sending audience as an array will not be correctly interpreted by existing software, so this property is an unreliable indicator of context audience membership at best Existing threadiverse apps check addresses, and audience may not be used at all in some. There is no conflict with Move(Person), and I have not heard a convincing reason to adopt a new activity type when these two AS activities work quite well to describe what we want to accomplish.
  • ActivityPub API Client Reputation

    10
    0 Votes
    10 Posts
    32 Views
    @evan said in ActivityPub API Client Reputation: > @thisismissem said in ActivityPub API Client Reputation: > > > I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix. > > Oof. Let's hope they get around to it before the bad guys do. I'd rather we all don't learn a lesson about security the hard way. One could hope, but they weren't willing to back the huge amount of work to deprecate non-expiring access tokens, so that'll probably be exploited first, since there's quite literally millions of non-revoked access tokens out there. I tried to do the work to fix it on my own, but it's literally months of work to implement correctly with enough test coverage. Without them either paying me or promoting/acknowledging my work, I ran out of my own budget to be able fix their problems. > > You can't Flag a non-activitypub JSON document. > > I think you can, if you use the Link type. > > json > { > "@context": "https://www.w3.org/ns/activitystreams", > "type": "Flag", > "id": "https://social.example/activity/flag/1", > "actor": "https://social.example/user/3", > "object": { > "type": "Link", > "mediaType": "application/json", > "href": "https://client.dev/oauth/metadata.json" > }, > "content": "This is an example Flag activity for a CIMD document." > } > That'll flag it at this point in time, and the contents can change. And software in the fediverse is unlikely to be able to understand receiving a flag like that. > At the very least, manual moderation is important. "This app isn't allowed on this server." That depends on human judgement, CVE reports, whatever. Yeah, requires folks to actually build moderation tools for that and ensure moderating against an application revokes its access completely. Revoking access tokens doesn't prevent usage of data already harvested or whatever, but does prevent ongoing abuse
  • Using the ActivityPub API for cross-server interactions

    5
    0 Votes
    5 Posts
    14 Views
    @evan thanks! I would attend but unfortunately a winter storm hit and I'm at home watching three kids today 😑
  • 0 Votes
    14 Posts
    24 Views
    @box464 Piefed's gallery view is the closest approximation I know of. Pinetta was more directly focused trying to be a Pinboard alternative hasn't been updated in a couple of years.
  • "Critical concept: IRIs are opaque identifiers.

    activitypub
    1
    0 Votes
    1 Posts
    7 Views
    Guest?
    "Critical concept: IRIs are opaque identifiers. You cannot infer meaning from the string pattern — only by dereferencing and inspecting the data." [1] This applies to URIs too. Sadly, almost no #ActivityPub implementations use this principle. Multi-tenant servers and simple account portability (with personal domains) would be relatively easy if they did.🙄 It is what it is.../cc @melvincarvalho [1] https://socialdocs.org/docs/concepts/uris-iris-linked-data/
  • 0 Votes
    13 Posts
    43 Views
    @julian@activitypub.space @julian@fietkau.social well, in theory, you can have private likes and public likes. misskey and pleroma do public likes. mastodon does private likes, but then shows them publicly if anyone asks the origin site. because addressing is just a suggestion, apparently ;)
  • Happy New Year!

    1
    1
    0 Votes
    1 Posts
    4 Views
    Happy New Year! Hope you all had a good holiday. It’s shaping up to be a great year on the open social web! We’ve been busy working on new features, internal improvements, bug fixes, and exploring new networks over the last couple months. Here are the noticeable changes on the bridge since our last update: DM notifications for interactions from non-bridged users (more) Mastodon to Bluesky support in Bounce (more) Expand blocking to Bluesky blocklists, multiple at once, web UI, and more… Support setting Bluesky handle back to the default *.ap.brid.gy (more) More support for fediverse => Bluesky pinned posts Make images/videos on Bluesky more reliable: Refresh them periodically Handle the same file at multiple URLs Upgraded to a paid CloudImage account for proxying Threads images/videos Customize Bluesky labels based on keywords in fediverse content warning (thanks @KDederichs!) Improve GoToSocial compatibility Bridge Web Monetization wallet addresses For Bluesky profiles bridged to the fediverse, make the link back to Bluesky “verified” (green check) in Mastodon Add support for new (invisible) website field in Bluesky profiles Web UI: improve handling of IDNs (domain names with emoji) and punycode RSS feeds: support application/rdf+xml Web UI: reload profile on login Bug fixes: …for race condition on writing to Bluesky repos …for bridging Bluesky handle changes to fediverse Webfinger address …for bridging web posts, replies, etc after we’ve already seen them …for deleting bridged fediverse profiles on some servers …for bridging Bluesky profile pictures to the fediverse …for links in post text When there’s an unbridged dependency, only skip that one protocol, not all Add missing PropertyValue in AS2 @context …for duplicated images in posts bridged to Bluesky Internal: Bluesky: Reliability improvements for firehose server/client Scale past ~10qps bottleneck in allocating sequence numbers (more) implement listBlobs Expand continuous deploy flags Various cost optimizations added up to savings of 40-50%: As usual, feel free to ping us with feedback, questions, and bug reports, and please support us on Patreon! You can follow the now label on GitHub to see what we’re currently focusing on. See you on the bridge!
  • WP replies not federating back out?

    11
    1 Votes
    11 Posts
    10 Views
    @pfefferle in the admin panel!
  • I need opinions on #Smithereen API.

    Moved smithereen activitypub mastodev
    3
    0 Votes
    3 Posts
    11 Views
    To be more clear, here are examples of the two options I'm undecided between. Which one do you like more? Which one would be easier for you to work with?
  • 0 Votes
    1 Posts
    8 Views
    Fedify 1.10.0: Observability foundations for the future debug dashboard Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities. We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications. This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface. Enhanced OpenTelemetry instrumentation Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values. The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations: activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation Additionally, Fedify now instruments previously uncovered operations: activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo. Distributed trace storage with FedifySpanExporter Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers. The new @fedify/fedify/otel module provides the following types and interfaces: import { MemoryKvStore } from "@fedify/fedify"; import { FedifySpanExporter } from "@fedify/fedify/otel"; import { BasicTracerProvider, SimpleSpanProcessor, } from "@opentelemetry/sdk-trace-base"; const kv = new MemoryKvStore(); const exporter = new FedifySpanExporter(kv, { ttl: Temporal.Duration.from({ hours: 1 }), }); const provider = new BasicTracerProvider(); provider.addSpanProcessor(new SimpleSpanProcessor(exporter)); The stored traces can be queried for display in debugging interfaces: // Get all activities for a specific trace const activities = await exporter.getActivitiesByTraceId(traceId); // Get recent traces with summary information const recentTraces = await exporter.getRecentTraces({ limit: 100 }); The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace. This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234. Optional list() method for KvStore interface Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries. interface KvStore { // ... existing methods list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>; } When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method: MemoryKvStore — filters in-memory keys by prefix SqliteKvStore — uses LIKE query with JSON key pattern PostgresKvStore — uses array slice comparison RedisKvStore — uses SCAN with pattern matching and key deserialization DenoKvStore — delegates to Deno KV's built-in list() API WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle. The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers. NestJS 11 and Express 5 support Thanks to a contribution from Cho Hasang (@crohasang@hackers.pub), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4. This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications. What's next Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available. The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release. Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies. Acknowledgments Special thanks to Cho Hasang (@crohasang@hackers.pub) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features. For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository. #fedidev #release

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • 1 Votes
    18 Posts
    63 Views
    @soapdog@toot.cafe hmm... just thinking aloud here. You posit in another post that the network effects inflate exponentially: > Push models are resource hogs that approach exponential growth in a large network like the fediverse That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further. If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances! Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic. If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.
  • 1 Votes
    1 Posts
    6 Views
    @bsky.brid.gy@bsky.brid.gy what! NodeBB has been sending out preview for quite awhile now, but there are exactly zero receivers. Mastodon doesn't support it. I think with this change BridgyFed would be the first one. cc @quillmatiq@mastodon.social
  • 0 Votes
    31 Posts
    143 Views
    @trwnhthe type information is largely unnecessary and shouldn't factor into handling CRUDServers needs to know the core type / class in order to determine the "owner" of an object (actor, attributedTo, etc).how does the server know which ids to assign and which ones not to?The result property could be declared as special in the FEP. Servers will be required to assign IDs to embedded activities. What is a blank node identifier, id: null? Using this to indicate a need for ID is a good idea too.I don't think side effect activities should be fragments.lastly as:result itself maybe doesn't have these semantics defined, so should a subproperty or different property be used, or do we skip non-CRUD results?Why skip non-CRUD results? I think side effects shouldn't be limited to basic activities like Create/Update/Add/Remove.@steve
  • 0 Votes
    13 Posts
    65 Views
    @cwebber @eyeinthesky @evan > There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.Yes. I posted something on the same subject today.https://social.coop/@smallcircles/116119597745488218