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.

70 Topics 584 Posts View Original
  • 6 Votes
    1 Posts
    0 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
    3
    1 Votes
    3 Posts
    1 Views
    @js@podcastindex.social thanks! 🤘
  • FEP-f15d: Context Relocation and Removal

    activitypub fep threadiverse
    6
    2 Votes
    6 Posts
    6 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

    7
    0 Votes
    7 Posts
    12 Views
    @thisismissem said in ActivityPub API Client Reputation: > Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation. I think that some centralisation is fine, as long as admins or even users can choose their reputation data provider. We do this with blocklists for instances already; there's no reason to think that client blocklists would need to be any different. They'd have to have the same caveats; a trusted provider, transparency in the process, etc. > You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration. Agreed. The best I can think of is using the redirect_uri, but that's not really unique -- especially for command-line clients that use localhost! I think the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal. I think it'd be a similar issue for ActivityPub API clients. > That's why we wrote the CIMD spec. Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers. > But OAuth security and trust models are complex and generally proprietary I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be: How many people on this server (or other servers) have authorized the client What the average rating has been (but you need a way to rate clients!) How many Flag activities have been submitted for this client (you need a way to report clients) Reviews of the client (you need a way to write a review of a client) That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.
  • Using the ActivityPub API for cross-server interactions

    5
    0 Votes
    5 Posts
    5 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
    6 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
    1 Views
    "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
    12 Posts
    16 Views
    @julian@fietkau.social that's a great idea! I should adopt that, there's no downside.
  • Happy New Year!

    1
    1
    0 Votes
    1 Posts
    1 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
    0 Views
    @pfefferle in the admin panel!
  • I need opinions on #Smithereen API.

    Moved smithereen activitypub mastodev
    3
    0 Votes
    3 Posts
    1 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
    1 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
  • @evan yes, yes, of course.

    8
    0 Votes
    8 Posts
    0 Views
    @mariusor that's too bad. All I have left is mussels, French fries, large-scale bureaucracy, and peeing statues.
  • @mariusor woot!

    12
    0 Votes
    12 Posts
    7 Views
    I'd generally discourage RFC7591 in decentralized systems due to the fact that it creates client sprawl (this is currently a problem with Mastodon's client registration mechanism, which is why we created CIMDs) — every client in RFC7591 is a distinct client, with its own client_id and client_secret, which can make client management interfaces difficult to implement (e.g., every time you login on a mobile device or SPA, you'll get a brand new client_id). CIMDs solve this by anchoring client metadata to a URI, and using that URI as the client_id. If you need to test clients using CIMDs in development, there is cimd-service however, it's currently targeting the AT Protocol ecosystem (so has a few specifics that at present there that would not necessarily make sense of ActivityPub)
  • 0 Votes
    2 Posts
    4 Views
    @reiver it's going to be great!
  • Announcing Key Transparency for the Fediverse

    1
    0 Votes
    1 Posts
    4 Views
    Announcing Key Transparency for the FediverseI'm pleased to announce the immediate availability of a reference implementation for the Public Key Directory server. This software implements the Key Transparency specification I've been working on since last year, and is an important stepping stone towards secure end-to-end encryption for the Fediverse. You can find the software publicly available on GitHub: PHP Server software: PHP SDK (client-side):https://soatok.blog/2025/12/15/announcing-key-transparency-fediverse/
  • 0 Votes
    14 Posts
    4 Views
    I think the wrapping in <p> is just plain good practice because otherwise rendered content could be injected somewhere resulting in invalid HTML. Not that browsers ever reject bad HTML anyway heh</p>
  • 0 Votes
    1 Posts
    3 Views
    One person's request for Fediverse applications —Alex wants to be able to choose what the preview image is for a video, chosen from the frames in the video....I can imagine editing tools (in Fediverse applications) would also be useful.It is also common elsewhere for people to be able to use custom images for preview images.#FediDev #FediDevs #FediUX #Fediverse #FediverseUX #PreviewImage #Video
  • 0 Votes
    11 Posts
    7 Views
    @chris @reiver @ezeno789 the key is that other servers have to consult the `replies` collection when they show the replies. Fortunately the original server sends `Add` and `Remove` activities when items are added and removed, so remote servers can keep a cached copy.
  • 0 Votes
    14 Posts
    6 Views
    ok yeah. we don't have the follower thing is I think the main thing. Which I could totally see being added. It should essentially be the same as subscribing to a community. The trust cafe thing is great though as it has a 0 to 100 sorta percent rating system so 100 is like subscribing/following and 0 would be like blocking and the numbers in between sorta give more nuance. I believe the way it works everything not rated is treated as 50.

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @evan thanks!

    I would attend but unfortunately a winter storm hit and I'm at home watching three kids today 😑

    read more

  • @julian The ActivityPub API Task Force has a meeting today at 11AM EST. https://meet.jit.si/activitypub-api

    read more

  • read more

  • @julian hmm, I believe it tries to make each AP call from the browser first, then falls back to a cloudflare worker if that fails.

    I just checked the cf worker and found this gem in it, so that might work for you too

    read more

  • 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 😅

    read more

  • 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.

    read more

  • Hm, it appears that none of my objections have been addressed.

    Once again, why there are two activities Move and Remove, and not a simple Update or a new activity type?

    read more

  • Hey @js@podcastindex.social, I enabled Anubis for my site, but now requests from Browser.pub don't work :cry:

    Is there something I can write a rule against, perhaps a header or user agent string that is unique to browser.pub?

    read more
Post suggeriti
  • WP replies not federating back out?

    Technical Discussion
    11
    1 Votes
    11 Posts
    0 Views
    @pfefferle in the admin panel!
  • ActivityPub API Client Reputation

    Technical Discussion
    7
    0 Votes
    7 Posts
    12 Views
    @thisismissem said in ActivityPub API Client Reputation: > Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation. I think that some centralisation is fine, as long as admins or even users can choose their reputation data provider. We do this with blocklists for instances already; there's no reason to think that client blocklists would need to be any different. They'd have to have the same caveats; a trusted provider, transparency in the process, etc. > You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration. Agreed. The best I can think of is using the redirect_uri, but that's not really unique -- especially for command-line clients that use localhost! I think the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal. I think it'd be a similar issue for ActivityPub API clients. > That's why we wrote the CIMD spec. Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers. > But OAuth security and trust models are complex and generally proprietary I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be: How many people on this server (or other servers) have authorized the client What the average rating has been (but you need a way to rate clients!) How many Flag activities have been submitted for this client (you need a way to report clients) Reviews of the client (you need a way to write a review of a client) That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.
  • 6 Votes
    1 Posts
    0 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 😅
  • 2 Votes
    6 Posts
    6 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.