Fediverse tech roadmap
This is how I want our network to evolve in 2024. Some of the things listed here may have been implemented already by a small number of projects, but more work is required on standards and interoperability.
- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.
- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.
- Connectivity. Improving connectivity means fighting indiscriminate instance-level blocks, expanding to overlay networks (Tor, I2P and others), maybe also developing standards for bridges. In many ways, these tasks are linked to data portability.
- Moderation / spam resistance. Anything other than "list of instances I don't like" would be a huge improvement. Fediseer is an interesting development, but still leaves a lot to be desired. Additionally, standardization of reply controls is needed. FEP-5624 exists, but the mechanism described there has many flaws.
- Scalability. How to publish to 1M followers from a single-user instance running on cheap hardware? FEP-8b32 should make various optimizations possible (inbox forwarding, efficient reposts, etc).
- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
- Discovery. Content discovery on small instances: relays, decentralized search.
- Developer experience. Documentation of de-facto standards (HTTP signatures, WebFinger). Simplified ActivityPub spec. Error reporting.
- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.
- URL handlers. Again, competing standards: FediLinks, FEP-07d7 and several other proposals.
- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.
- Synchronization of replies. Various approaches are being considered, but there's no clear winner.
- Markets. So far there's only one server implementation capable of processing payments. FEP-0837 (a protocol for federated marketplace) was designed, but lacking adoption.
- Forge federation. ForgeFed is being implemented in Forgejo, although the work is progressing very slowly.
silverpill /
npub1df…27gmw
2024-01-02 21:02:46
Author Public Key
npub1df0nthpgzfmvxrzj0cfypmmt45l0y770j260auqhm3l45hp3uhkqx27gmwPublished at
2024-01-02 21:02:46Event JSON
{
"id": "cab922feba357df64bfe82d6c8bb3bb29978d093a87b65e50e4ff094a6cbe46d",
"pubkey": "6a5f35dc281276c30c527e1240ef6bad3ef27bcf92b4fef017dc7f5a5c31e5ec",
"created_at": 1704229366,
"kind": 1,
"tags": [
[
"proxy",
"https://mitra.social/objects/018ccbfc-6b7e-1490-086c-d41bff6efb71",
"activitypub"
]
],
"content": "Fediverse tech roadmap\n\nThis is how I want our network to evolve in 2024. Some of the things listed here may have been implemented already by a small number of projects, but more work is required on standards and interoperability.\n\n- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.\n- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.\n- Connectivity. Improving connectivity means fighting indiscriminate instance-level blocks, expanding to overlay networks (Tor, I2P and others), maybe also developing standards for bridges. In many ways, these tasks are linked to data portability.\n- Moderation / spam resistance. Anything other than \"list of instances I don't like\" would be a huge improvement. Fediseer is an interesting development, but still leaves a lot to be desired. Additionally, standardization of reply controls is needed. FEP-5624 exists, but the mechanism described there has many flaws.\n- Scalability. How to publish to 1M followers from a single-user instance running on cheap hardware? FEP-8b32 should make various optimizations possible (inbox forwarding, efficient reposts, etc).\n- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.\n- Discovery. Content discovery on small instances: relays, decentralized search.\n- Developer experience. Documentation of de-facto standards (HTTP signatures, WebFinger). Simplified ActivityPub spec. Error reporting.\n- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.\n- URL handlers. Again, competing standards: FediLinks, FEP-07d7 and several other proposals.\n- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.\n- Synchronization of replies. Various approaches are being considered, but there's no clear winner.\n- Markets. So far there's only one server implementation capable of processing payments. FEP-0837 (a protocol for federated marketplace) was designed, but lacking adoption.\n- Forge federation. ForgeFed is being implemented in Forgejo, although the work is progressing very slowly.",
"sig": "c2ee385260908301f534693ca44a43e462c1f4ed80d1bd674eb57502119075d424f204d06c45580b697272b1b4f3dab69aaf2eeae5a8111579318fcdff606294"
}