Fediverse tech roadmap 2025
-
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 @silverpill Wonderful list... the E2E space has progress as well.
Soatok Dreamseeker (@soatok@furry.engineer)
# Fedi-E2EE Public Key Directory Specification v0.1.0 released This is not a production-ready specification. It is the basis I will use for developing the reference implementation. https://github.com/fedi-e2ee/public-key-directory-specification/releases/tag/v0.1.0
Furry.Engineer - Duct tape, hotfixes, and poor soldering! (furry.engineer)
-
@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.
