Fediverse tech roadmap 2025
General Discussion
7
Posts
4
Posters
14
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
-
@silverpill lol, based on the "claims" at the begining, why do I feel like the "thanks" at the end should be in quotations?
Also I take umbrage with calling what I've been doing for the past 8 years as "being not difficult to build nor an interesting concept". I feel like you, and other developers having the benefit of dynamically typed programming languages, underestimate how that can be worked into robust APIs when you're limited by less versatile stacks.
-
Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.
I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:
FEP-fc48: Generic ActivityPub server
This kind of server:
- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.
-
-
Backlinks to quote posts.
-
@mapache I’ll take it for a spin.
-
Hiya, yes, I would like to test this. I currently use @linkstack for this, so it'll be great to see how your system works. I will need to self-host though - will that be possible?
-
-
@mapache im in where do I join?
