toad.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server operated by David Troy, a tech pioneer and investigative journalist addressing threats to democracy. Thoughtful participation and discussion welcome.

Administered by:

Server stats:

273
active users

#fep

0 posts0 participants0 posts today

Once again, #Fediverse crowd: What's the best way of adding user-centric feedback that might want to end up in a dedicated #FEP (and eventually get implemented at some point), assuming I'm in no way likely to draft a full specification or even implement this somewhere?

Situation, and given environment: Again and again I end up with wanting to use different federated platforms for different kinds of content. Like: Vernissage or a dedicated Mastodon profile for pictures. Peertube for videos. Friendica, or maybe at some point Ghost, for longer posts. Mastodon or something like that for microblogging. It would be good to encourage people to use the "right" tool for the right job. But using the right tool for the right job always comes with tremendous clutter: You end up following the same profiles over and over again. You end up seeing the same stuff in (n) different timelines on different platforms. You might even end up with people reaching out to contact you on (n) different platforms, subsequently leaving you in need to keep track of (n) different inboxes on all of these.

Clients can't really ease this well at the moment, and the servers / network doesn't support that either. What's missing, at this point, seems some way of "joining" different accounts on different platforms into one. Expectation would be, here: If "joining" my accounts (like, Vernissage, Friendica, Mastodon), I can post on each platforms just the way I'd like to, but I see the same notifications on all of these. I can respond to each and every notification transparently from whichever platform I am logged in to. I have a kind-of "unified" timeline that avoids me seeing the same content as "new" again on each of these platforms separately. This is a bit all along the lines of how Friendica does integrate Tumblr and Bluesky accounts, but for other AP platforms. At the moment, the load added / time needed to handle multiple accounts in parallel is one of the reasons I see people focussing essentially on Mastodon because it seems to work best for most and every additional account just adds much more complexity and friction than it provides real benefit.

No idea whether this is possible or desirable, and (given even some of the resistance against Hubzilla-style Nomadic Identity in pars of the Fediverse) don't see this happening anytime soon but still it would be interesting to try and ... well, leave this as kind of a "change" request somewhere out there.

Replied in thread

@z428 yes, these are the realities of working with the social dynamics in chaotic grassroots environments. ActivityPub is among the few commons based open standards, I think.

In the current process the best-practices gathered from throughout the decentralized developer ecosystem aggregate by emergent forces to form the fediverse at large. The #SocialHub #FEP process acts as a funnel that directs experience towards further adoption in formal #ActivityPub et al open standards by the W3C #SocialCG

Replied in thread

@blenderdumbass hi there 👋

I follow the #ActivityPub hashtag and see this same msg for the 10th time or so and it becomes a bit spammy. The best way to get attention is to ask concrete questions that people can help with. There are also a number of places on the web to consult or interact with like socialhub.activitypub.rocks dev community, the W3C #SocialCG mailing list and AS/AP repo issue trackers. There is the #FEP process at codeberg.org/fediverse/fep and fedi-resources at delightful.coding.social

SocialHubSocialHubWhere ActivityPub developers coordinate their efforts to make the Fediverse a great space for cooperation
Replied to silverpill

+1 to @silverpill's contribution. As the linked doc says;

"ActivityPub specification hasn't been updated since 2018. Many developers consider it incomplete and/or outdated."

codeberg.org/ap-next/ap-next/s

Following the current spec to the letter is a good exercise in understanding it, but by itself it will not get you smooth interop with existing AP implementations.

I'd also recommend familiarising yourself with the Fediverse Enhancement Protocol process;

codeberg.org/fediverse/fep/src

#FEP

@douginamug

Codeberg.orgap-next/guide.md at mainap-next - ActivityPub Next

I want open file formats with alt-text metadata that are compatible with most Fediverse software:
Upload an image or video to Mastodon, Pixelfed or whatever, that has alt-text metadata and it will automatically display the alt-text in the Fediverse.
Download the file and it will keep the alt-text.

Bonus: A metadata field for Fediverse creator. So people can download and repost media files and they will display the original creator just like Mastodon can do with link previews.

EDIT: In the replies we've gathered so far:
* There is an existing issue for Mastodon: github.com/mastodon/mastodon/i (I don't open Microsoft GitHub™, so I didn't read it)
* PNG and probably many other file formats already have appropriate metadata tags that could be used.
* Fedi devs have to agree on one way to implement this -> #FEP
* While uploading a file you should be able to edit or replace the metadata alt text with your own alt text and then be able to choose whether you want to replace the file's metadata or not (So your post can display the alt text that is specifically relevant to your post, while the file can be downloaded with a more general alt text).

GitHubPre-polulate the image alt text field from the description field in EXIF metadata · Issue #14903 · mastodon/mastodonBy craigS89

Two upcoming changes in the #FEP process:

- Withdrawing stale proposals. If a proposal remains inactive for 2 years, its status is changed to WITHDRAWN. Previously, the period was 1 year after submission, and facilitators were supposed to contact authors before withdrawing (that didn't work well).
- Implementation tracking. If a proposal has type: implementation attribute, we will automatically count list items in the "Implementations" section and display that number somewhere (probably in README). If your proposal is implementable, I recommend adding type: implementation attribute to it. Also, don't forget to mention implementations if they exist - this information is very important.

Codeberg.orgFEP-a4ed: Withdraw stale proposalsFEP-a4ed requires facilitators to contact authors of a stale proposal before withdrawing it. As our experience shows, that doesn't work. In this PR I propose withdrawing stale proposals after 1 year of inactivity without contacting authors. This is a major change. I think even if we agree on i...

»#PostQuantumPrivacy for #PostPlatformInternet. — #Fediverse pilots: #ActivityPub with #Dilithiumsignatures. While #Mastodon and other ActivityPub servers still use #RSA-#HTTP-#Signatures by default, developers in the #SocialHub community are working on a #FEP (Fediverse Enhancement Proposal) to clarify signature processing and accommodate #quantumsafealgorithmshackernoon.com/post-quantum-pr #Fedizen #Fediverse #ActivityPub #News

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:

{
  "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.

Codeberg.orgfep/fep/844e/fep-844e.md at mainfep - Fediverse Enhancement Proposals

The Work Continues: What’s Next

Details will follow soon — but the work on events in the #Fediverse is far from complete. Key upcoming milestones include:

  • Improvements and new features for the Event Bridge for ActivityPub plugin for WordPress
    Continued development to maintain, fix issues, enhance, and expand functionality.
  • Work on Fediverse Enhancement Proposals (FEPs)
    Ensuring a robust final status of FEP-8a8e and focus on recurring and irregularly scheduled events.
  • Support for event interoperability in other Fediverse applications
    Contribute to other Fediverse applications and help them to explore and improve support for Event objects. For example, @linos@graz.social has outlined a potential roadmap for Mastodon.
  • Contribution to GatherPress
    Active involvement in the GatherPress project — a modern and truly FLOSS community oriented WordPress event plugin — to ensure full ActivityPub compatibility, including RSVP support and advanced federation features.
  • Community engagement and outreach
    Participation in conferences, public talks, and direct conversations to foster knowledge exchange, gather feedback, and grow the ecosystem around federated events.

Additional updates and technical details will be shared soon. Input, testing, and collaboration from interested parties are always welcome. Or if you know any conferences we should attend, let us know.

Codeberg.orgwordpress-event-bridge-for-activitypubIntegrating popular WordPress event plugins with the ActivityPub plugin.

"I was also pointed to another interesting topic: the FEDERATION.md file and the Fediverse Enhancement Proposals initiative (one of which is precisely the FEDERATION.md file). After reading about this file and reviewing other proposals on the project’s site, I have to say it’s fantastic. It’s an open process for standardizing and documenting extensions and proposed changes to the ActivityPub protocol and other technologies used in the Fediverse"

@mczachurski, 2025

vernissage.photos/news/7504383

vernissage.photos · Platform update - May 2025
More from Marcin Czachurski

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?

community.nodebb.org/post/1048