Salta al contenuto

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

177 Discussioni 1.4k Post View Original

Technical discussion about ActivityPub-related topics.

  • Backfill from Mastodon working really well!

    fediverse activitypub 7888 f228 mastodon
    1
    6 Votazioni
    1 Post
    26 Visualizzazioni
    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 Votazioni
    15 Post
    57 Visualizzazioni
    @js otherwise please stop follow me if you do not want help. @julian
  • FEP-f15d: Context Relocation and Removal

    activitypub fep threadiverse
    6
    2 Votazioni
    6 Post
    44 Visualizzazioni
    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 Votazioni
    10 Post
    41 Visualizzazioni
    @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 Votazioni
    5 Post
    21 Visualizzazioni
    @evan thanks! I would attend but unfortunately a winter storm hit and I'm at home watching three kids today 😑
  • So what’s the ActivityPub version of Pinterest?

    pinterest activitypub fedidev
    14
    0 Votazioni
    14 Post
    33 Visualizzazioni
    @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 Votazioni
    1 Post
    21 Visualizzazioni
    Ospite?
    "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/
  • Does anyone know if mastodon broadcasts replies to posts?

    mastodon activitypub
    13
    0 Votazioni
    13 Post
    63 Visualizzazioni
    @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 Votazioni
    1 Post
    9 Visualizzazioni
    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 Votazioni
    11 Post
    14 Visualizzazioni
    @pfefferle in the admin panel!
  • I need opinions on #Smithereen API.

    Spostato smithereen activitypub mastodev
    3
    0 Votazioni
    3 Post
    23 Visualizzazioni
    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 Votazioni
    1 Post
    18 Visualizzazioni
    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 Votazioni
    8 Post
    16 Visualizzazioni
    @mariusor that's too bad. All I have left is mussels, French fries, large-scale bureaucracy, and peeing statues.
  • @mariusor woot!

    12
    0 Votazioni
    12 Post
    12 Visualizzazioni
    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 Votazioni
    2 Post
    22 Visualizzazioni
    @reiver it's going to be great!
  • Announcing Key Transparency for the Fediverse

    1
    0 Votazioni
    1 Post
    13 Visualizzazioni
    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 Votazioni
    14 Post
    37 Visualizzazioni
    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 Votazioni
    1 Post
    22 Visualizzazioni
    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 Votazioni
    11 Post
    32 Visualizzazioni
    @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 Votazioni
    14 Post
    33 Visualizzazioni
    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.