I have added Mastodon-style (FEP-044f) quote post compatibility to my @DailyRucks bot.
Technical Discussion
7
Posts
2
Posters
27
Views
-
RE: https://fietkau.software/daily_rucks/ap/activity/2025-11-08
I have added Mastodon-style (FEP-044f) quote post compatibility to my @DailyRucks bot. You can now quote post the daily voice lines as much as you want! 🥳
This would be noteworthy on its own if there weren't already a bunch of non-Mastodon implementations, but I'm actually late to the party. WordPress, Bonfire, micro.blog, dotmakeup, and ActivityBot all got there before I did.
However, I think my approach is novel for being *stateless*. Thread incoming.
🧵 1/6
-
RE: https://fietkau.software/daily_rucks/ap/activity/2025-11-08
I have added Mastodon-style (FEP-044f) quote post compatibility to my @DailyRucks bot. You can now quote post the daily voice lines as much as you want! 🥳
This would be noteworthy on its own if there weren't already a bunch of non-Mastodon implementations, but I'm actually late to the party. WordPress, Bonfire, micro.blog, dotmakeup, and ActivityBot all got there before I did.
However, I think my approach is novel for being *stateless*. Thread incoming.
🧵 1/6
You may have read that Mastodon quote posts are technically opt-in. To give you the options to opt out of being quoted or to revoke a prior quote permission, each post that tries to quote you applies for an individualized “permission slip” behind the scenes.
This permission slip actually points back to your own server, allowing you to revoke a quote post permission without needing the cooperation of the server where you're being quoted.
Full technical details: https://codeberg.org/fediverse/fep/src/branch/main/fep/044f/fep-044f.md
🧵 2/6
-
You may have read that Mastodon quote posts are technically opt-in. To give you the options to opt out of being quoted or to revoke a prior quote permission, each post that tries to quote you applies for an individualized “permission slip” behind the scenes.
This permission slip actually points back to your own server, allowing you to revoke a quote post permission without needing the cooperation of the server where you're being quoted.
Full technical details: https://codeberg.org/fediverse/fep/src/branch/main/fep/044f/fep-044f.md
🧵 2/6
This bureaucracy is necessary for verification of consent, but it is a bit of a pain for software implementers who want to give blanket quoting permissions, like bot authors.
Making your account quotable by Mastodon takes more than a simple declaration: it has to have the ability to respond affirmatively to quote requests, and to confirm or deny the legitimacy of existing quotes.
Generally this means having to at least keep track of everyone who has quoted you.
🧵 3/6
-
This bureaucracy is necessary for verification of consent, but it is a bit of a pain for software implementers who want to give blanket quoting permissions, like bot authors.
Making your account quotable by Mastodon takes more than a simple declaration: it has to have the ability to respond affirmatively to quote requests, and to confirm or deny the legitimacy of existing quotes.
Generally this means having to at least keep track of everyone who has quoted you.
🧵 3/6
While reading FEP-044f, I had an idea for getting around that requirement. It's difficult to explain without getting extremely technical, but I think it could be interesting for platform implementers who want to offer blanket quotability to Mastodon users, but who have shied away from FEP-044f for its state management requirements.
Basically, a quote authorization stamp payload (see https://codeberg.org/fediverse/fep/src/branch/main/fep/044f/fep-044f.md#example-of-quoteauthorization) has to contain the IDs of the quoting post and the quoted post.
🧵 4/6
-
While reading FEP-044f, I had an idea for getting around that requirement. It's difficult to explain without getting extremely technical, but I think it could be interesting for platform implementers who want to offer blanket quotability to Mastodon users, but who have shied away from FEP-044f for its state management requirements.
Basically, a quote authorization stamp payload (see https://codeberg.org/fediverse/fep/src/branch/main/fep/044f/fep-044f.md#example-of-quoteauthorization) has to contain the IDs of the quoting post and the quoted post.
🧵 4/6
That's why it's not possible to simply reply “ya sure” to every quote verification request. The response has to affirmatively state which quote it is for.
So I thought, instead of keeping a list of prior quotes in a local database, why not embed them in the ID (URI) of the verification stamp? That way the code could simply echo them back out for any future request.
Turns out this works! You can see an example here: https://fietkau.software/daily_rucks/ap/quoteAuth?stamp=2025-11-08;https%3A%2F%2Fexample.com%2Fsome-post
🧵 5/6
-
That's why it's not possible to simply reply “ya sure” to every quote verification request. The response has to affirmatively state which quote it is for.
So I thought, instead of keeping a list of prior quotes in a local database, why not embed them in the ID (URI) of the verification stamp? That way the code could simply echo them back out for any future request.
Turns out this works! You can see an example here: https://fietkau.software/daily_rucks/ap/quoteAuth?stamp=2025-11-08;https%3A%2F%2Fexample.com%2Fsome-post
🧵 5/6
This way, @DailyRucks gives out permission slips which are “shaped” in a way that is instantly verifiable, no database and no internal state required.
The only problem is that the ID of the quoting post is an arbitrary URI, and passing full URIs as query string parameters is brittle. It seems to work for Mastodon post IDs, but other platforms might have more complex URI schemas.
I guess we'll see what happens! 😀
Project website with link to the git repository: https://fietkau.software/daily_rucks
🧵 6/6
-
This way, @DailyRucks gives out permission slips which are “shaped” in a way that is instantly verifiable, no database and no internal state required.
The only problem is that the ID of the quoting post is an arbitrary URI, and passing full URIs as query string parameters is brittle. It seems to work for Mastodon post IDs, but other platforms might have more complex URI schemas.
I guess we'll see what happens! 😀
Project website with link to the git repository: https://fietkau.software/daily_rucks
🧵 6/6
@julian Nice workaround. They should describe it in the FEP
Gli ultimi otto messaggi ricevuti dalla Federazione
-
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 instrumentationFedify 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 representationAdditionally, 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 usedThese 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 FedifySpanExporterBuilding 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 interfaceFedify 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 patternWhile 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 supportThanks 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 nextFedify 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.
AcknowledgmentsSpecial 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
-
-
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>
-
>Can you explain what goes on in mitra?
When mediaType is text/markdown, the entire content is wrapped in a <p> tag. This was done for compatibility with PeerTube. I think <p> was needed to create a space between the title (name) and the content, since title is prepended to content in Mitra (also a compatibility hack -- for Mastodon API clients).
-
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)
-
Speaking of handling markdown. I created funfedi.dev Media Types a while ago (and just added it to the navigation). I lost interest when I saw that nobody properly handled the mediaType attribute of a note. Not that I know what I expected.
Can you explain what goes on in mitra? When mediaType is text/markdown. It changes __bold__ to <p>__bold__</p>, otherwise no paragraph tags. I'm pretty sure, I was once told to use __ for bold and * for emphasize. So my markdown should be good.
Full example ... input activity -> mitra api response
Final note: I am not sure what I would want a proper data format to do. I find the solution of W3C ActivityPub (not W3C ActivityStreams) proposes of putting HTML in content and adding source with the original, from which the HTML was generated ok. Of course, this leaves the existence of the summary and name field superfluous.
-
@reiver@mastodon.social add in NodeBB as well. Markdown first, and probably HTML too, although it will probably be sanitized to death on the way out.
-
@mariusor that's too bad. All I have left is mussels, French fries, large-scale bureaucracy, and peeing statues.
