Fediverse tech roadmap 2025
General Discussion
7
Posts
4
Posters
11
Views
-
Fediverse tech roadmap 2025
One year ago I published Fediverse tech roadmap for year 2024. How did we do?
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just
did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra.
- End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix.
- Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious.
- Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial).
- Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments.
- Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune.
- Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform.
- Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024.
- Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing.
- URL handlers. No significant progress.
- Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations.
- Markets. No significant progress.
- Quoting. FEP-e232 is now supported by 8 platforms.
- Forge federation. Forgejo implemented federated stars, and the development of other features has started.I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial.
- Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61).
- ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar.
- End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop.
- Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation. -
Fediverse tech roadmap 2025
One year ago I published Fediverse tech roadmap for year 2024. How did we do?
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just
did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra.
- End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix.
- Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious.
- Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial).
- Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments.
- Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune.
- Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform.
- Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024.
- Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing.
- URL handlers. No significant progress.
- Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations.
- Markets. No significant progress.
- Quoting. FEP-e232 is now supported by 8 platforms.
- Forge federation. Forgejo implemented federated stars, and the development of other features has started.I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial.
- Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61).
- ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar.
- End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop.
- Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.@silverpill no mention of feditest.org?
-
@silverpill no mention of feditest.org?
@j12t I know about FediTest, it's a cool project, but I can't include everything here. Sometimes it appears in @weekinfediverse newsletter
-
The sentence "URL handlers. No significant progress." feels incredible polite. I would have written "The browser syndicate continues their ignorance."
Made a demo about the broken registerProtocolHandlers a very long time ago https://www.youtube.com/live/W70wd56i0Bg?si=tnYZ0JiCaW136GJg&t=2057
:) -
Fediverse tech roadmap 2025
One year ago I published Fediverse tech roadmap for year 2024. How did we do?
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just
did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra.
- End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix.
- Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious.
- Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial).
- Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments.
- Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune.
- Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform.
- Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024.
- Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing.
- URL handlers. No significant progress.
- Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations.
- Markets. No significant progress.
- Quoting. FEP-e232 is now supported by 8 platforms.
- Forge federation. Forgejo implemented federated stars, and the development of other features has started.I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial.
- Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61).
- ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar.
- End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop.
- Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.@silverpill surprised that there is no mention of Fediscovery here? https://fediscovery.org (note that @dave will be talking about this at #FOSDEM)
-
@silverpill surprised that there is no mention of Fediscovery here? https://fediscovery.org (note that @dave will be talking about this at #FOSDEM)
@silverpill in addition, I would have that LOLA (SWICG data portability work) could warrant a mention for progress in 2024
-
@silverpill surprised that there is no mention of Fediscovery here? https://fediscovery.org (note that @dave will be talking about this at #FOSDEM)
@andypiper @dave I haven't seen an implementation of this and the specs look incomplete.
Also, replacing ActivityPub with bespoke API is a bad idea.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@benpate @maikel IMO, the "shipping stuff is hard", while true, isn't the issue. If you had created Emissary 8 years ago and stopped updating it after the first release (even with massive user feedback about UX and technical issues), your project would either be dead or massively forked (if there was enough interest). Even if you had a small release to fix a few serious bugs after eight years, that wouldn't be sufficient. If it weren't for Mastodon, AP would effectively be a dead protocol.
-
@maikel@vmst.io not surprising in the slightest considering ChatGPT is trained on public discourse, and most AP development discussions involve how much Mastodon fails at x y and z. Being the big fish means everybody takes pot shots at you.
So it's just a reflection of the training data. Us.
@benpate@mastodon.social you're just feeding the AI machine! 😱
-
@mat talk of purity can only make all other platforms connect better among themselves. Yet every time someone implements Activity Pub the first burden they find is "ooops, this gives an error from Mastodon side".
Standards exist for this very reason.
I agree with you with meeting in the middle, but Msatodon has been up since 2016, Activity Pub since 2018, we're on 2026. Mastodon migrated in late 2017 early 2018 before the spec was even fully ratified. It's been more than 8 years.
If at-the-very-least it didn't have the "huge undocumented behaviours", it wouldn't be stalling all other AP implementers.
-
@benpate @maikel That doesn't sound right. Mastodon came first, ActivityPub came later. Surely that's enough of an explanation? AP was a retro-fit to an existing social media site. Of course it was a bodge job.
To me, that's the true purpose of AP. It works best for connecting existing communities. We should reject the idea of tearing apart and rebuilding what exists today. Instead we should grow the network by meeting people where they are. Talk of "purity" can only be destructive.
-
@maikel I also wish Mastodon followed the specs closer.
At the risk of sounding like an apologist, real-world constraints and deadlines were probably a factor. Shipping stuff is *hard* and there are always difficult tradeoffs to be made.
C2S API is a good example. They NEEDED a mobile client, but the standard wasn’t enough.
However we got here, it’s on the standards community to build a spec that will work in the real world, then make incentives for the market leader to follow.
-
JESUS when even the stochastic parrot throws shade at Msatodon implementation of Activity Pub.
I'm honestly starting to wonder what is the point of people putting years in creating a standard if the main platform using such standard is spitting on it.
-
Tor: here is a list https://fedilist.com/instance?q=&ip=&software=®istrations=&onion=only
I2P: http://mastodon.i2p is currently online
Yggdrasil: there was a few, but I can't find them now
-
Are there #activitypub networks inside non-clearnet networks
