| Code | https://codeberg.org/silverpill/ |
| Matrix | @silverpill:unredacted.org |
| XMPP | silverpill@were.chat |
| $XMR | 884y9LmsWY7PQNsyR7bJy1dvj91tuF5spVabyCnPk4KfQtSuzFbQobTFC7xSemJgVW1FWAwnJbjTZX5zZWbBrfkv62DB62d |
| XMR subscription | https://mitra.social/@silverpill/subscription |
| PGP | 0541 49E3 0F91 C6D7 8FFA C49C 955F 5A6E 2123 25F0 |
| OMEMO fingerprint | 689a2fb0ec87a9481fb45cb7d8870da6aeb4d8247bd69a39017701133b901f04 |
| Matrix (backup) | @silverpill:poa.st |
Only Mastodon and Iceshrimp.NET didn't accept actor documents without @context. It is not clear why Mastodon requires it, because Mastodon doesn't use it, as far as I know. The related issue has been open since 2018.
Meanwhile, @context has been restored for @nomad and now it can be followed from Mastodon too.
RE: https://mitra.social/objects/0197759b-8413-2f5c-d7ec-83509cedf468
Which Fediverse services can see this actor? @nomad
It looks like Mastodon can't parse it, what about others?
FEP-521a: Representing actor's public keys has been finalized!
https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md
I've been working on a new site to help transparency in the #FOSS world:
This is an evolution upon my prior confusion cases work, intended to make the information more accessible, functional and easier to maintain, while now also featuring projects which are committed & transparent regarding free and #OpenSource software.
Fixes #34943 This effectively downgrades compatibility with non-FEP-044f quote posts to only treat them as quote posts in the REST API if they are accepted. In practice, this means fast-track (self...
>Mastodon will begin displaying quote posts from other servers and software
Anyone knows what it really means?
Initial version of their FEP was based on FEP-e232, but in the end they decided to drop it and introduce a new property, quote. I guess "other servers" actually means "other Mastodon servers".
The reason for introducing a new property, by the way, was
We believe each of those to have significant drawbacks, such as re-using a namespace that has no definition for them, implying the value is an URL or URI, or using an unusual naming scheme
So now we all need to support an additional representation because the color of the bikeshed was wrong.
RE: https://mastodon.social/users/Gargron/statuses/114625891198289108
FEP-844e: Capability discovery has been published to the FEP repository:
https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md
I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:
Dan Brown
nicole mikołajczyk{
"generator": {
"type": "Application",
"implements": [
{
"name": "RFC-9421: HTTP Message Signatures",
"href": "https://datatracker.ietf.org/doc/html/rfc9421"
}
]
}
}
All important information is embedded, so additional HTTP requests are not necessary.
Published the code of my tiny FEP-ae97 server:
https://codeberg.org/silverpill/fep-ae97-server
I used this project to test some ideas before implementing them in Mitra, so it is unlikely to be developed into a finished product. But maybe someone will find the code interesting.
The server is built using apx_sdk and is compatible with fep-ae97-client.
Mitra v4.4.0 supports verification of RFC-9421 HTTP signatures. It is known to be compatible with @fedify, but I haven't tested it with Mastodon or Streams yet.
Outgoing requests are still signed according to the draft-cavage. I don't plan to implement double-knocking, but something like FEP-844e could be supported in the future, though this is not urgent.
My implementation of a parser is available in APx library.
RE: https://mitra.social/objects/01974018-9b83-c1ec-a109-24a72a579235
Backfilling Conversations: Two Major Approaches
In February 2025, I presented a topic at FOSDEM in Brussels entitled The Fediverse is Quiet — Let's Fix That! In it, I outlined several "hard problems" endemic to the fediverse, focusing on one particular complaint that is often voiced by newcomers and oldtimers alike; that the fediverse is quiet because you don't ever see the full conversation due to some design considerations made at the protocol level.
Since then there have been a number of approaches toward solving this problem, and it is worth spending the time to review the two main approaches and their pros and cons.
N.B. I have a conflict of interest in this subject as I am a proponent of one of the approaches (FEP 7888/f228) outlined below. This article should be considered an opinion piece.
Crawling of the reply tree
First discussed 15 April 2024 and merged into Mastodon core on 12 Mar 2025, @jonny@neuromatch.social pioneered this approach to "fetch all replies" by crawling the entirety of the reply tree. When presented with an object, the Mastodon service would make a call to the context endpoint, and if supported(?) would start to crawl the reply tree via the replies collection, generating a list of statuses to ingest.
This approach is advantageous for a number of reasons, most notably that inReplyTo and replies are properties that are ubiquitous among nearly all implementations and their usage tends not to differ markedly from one another.
N.B. I am not certain whether the service would crawl up the inReplyTo chain first, before expanding downwards, or whether context is set in intermediate and leaf nodes that point to the root-level object.
One disadvantage is this approach's susceptibility to network fragility. If a single node in the reply tree is temporarily or permanently inaccessible, then every branch of the reply tree emanating from that node is inaccessible as well.
Another disadvantage is the reliance on intermediate nodes for indexing the reply tree. The amount of work (CPU time, network requests, etc.) scales linearly with the size of the reply tree, and more importantly discoverability of new branches of the reply tree necessitate a re-crawl of the entire reply tree. For fast-growing trees, this may not net you a complete tree depending on when you begin crawling.
Lastly, in the ideal case, a full tree crawl would net you a complete tree with all branches and leaves. Great!
Mastodon is the sole implementor of this approach, although it is not proprietary or special to Mastodon by any means.
FEP 7888/f228, or FEP 171b/f228
Summarized by @silverpill@mitra.social in FEP f228 (as an extension of FEPs 7888 by @trwnh@mastodon.social and 171b by @mikedev@fediversity.site), this conversational backfill approach defines the concept of a "context owner" as referenced by compatible nodes in the tree. This context owner returns an OrderedCollection containing all members of the context.
A major advantage of this approach centers around the pseudo-centralization provided by the context owner. This "single source of truth" maintains the index of objects (or activities) and supplies their IDs (or signed full activities) on request. Individual implementations then retrieve the objects (or activities). It is important to note that should the context owner become inaccessible, then backfill is no longer possible to achieve. On the other hand, a dead or unresponsive intermediate node will not affect the ability of the downstream nodes to be processed.
The context owner is only able to respond with a list of objects/activities that it knows about. This does mean that downstream branches that do not propagate upwards back to the root will not be known to the context owner.
Additionally, consumers are also able to query the context owner for an index without needing to crawl the entire reply tree. The ability to de-duplicate objects at this level reduces the overall number of network requests (and CPU time from parsing retrieved objects) required, making this approach relatively more efficient.
Additional synchronization methods (via id hashsums) could be leveraged to reduce the number of network calls further.
A number of implementors follow this approach to backfill, including NodeBB, Discourse, WordPress, Frequency, Mitra, and Streams. Additional implementors like Lemmy and Piefed have expressed interest.
One technical hurdle with this approach is technical buy-in from implementors themselves. Unlike crawling a reply tree, this approach only works when the context owner supports it, and thus should be combined with various other backfill strategies as part of an overall conversational backfill solution.
Conclusion
2025 is shaping up to be an exciting year for resolving some of the harder technical and social problems endemic to the open social web/fediverse. It is this author's opinion that we may be able to make good headway towards resolving the "quiet fedi" problem with these two approaches.
It is important to note that neither approach conflicts with the other. Implementations are free to utilise multiple approaches to backfill a conversation. Both methods presented here have pros and cons, and a combination of both (or more) could be key.
Feel free to use this as a starting point for discussions regarding either approach. Does one speak to you more than the other? Are the cons of either approach significant enough for you to disregard it? What other approaches or changes could you recommend?
julian