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 and related standards, decentralized search.
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.
tl;dr: Hubzilla has had at least some of this for over a decade now. And it won't replace any of it with a new standard tailor-made for Mastodon.
@silverpill If you look past projects based on ActivityPub and at projects that have ActivityPub as an additional protocol, some of this already exists.
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.
Exists in the shape of nomadic identity. Invented by @Mike Macgirvin 🖥️ in 2011 with his Zot protocol and first deplayed in 2012 with the Red Matrix, nowadays known as Hubzilla. Also available on (streams), Mike's current project at the end of a string of forks from Hubzilla, now based on the Nomad protocol.
Mike would like to see nomadic identity and other special features of the Zot and Nomad protocols included in the ActivityPub protocol. He has actually submitted a number of proposals for this. They were all rejected. Even though he is a protocol developer first and foremost, and he has both created and worked on more Fediverse protocols than anyone else, so he should be considered competent.
Nomadic identity with ActivityPub won't come unless either Evan Prodromou and the W3C commission cave in and allow Mike's suggestions, or someone re-invents the wheel from scratch in a way that's utterly incompatible to Hubzilla and (streams). And it won't come to Mastodon unless Eugen Rochko can imply that Mastodon has had it first.
And there will never be a nomadic identity standard that meets Mike's requirements as well as Eugen's wishes.
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.
AFAIK, all three of Mike's still existing projects, Friendica from 2010, Hubzilla from 2012/2015 and (streams) from 2021, have it. Optionally, but still. I think Friendica actually advertises military-grade encryption.
Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
Friendica, Hubzilla and (streams) have had support for add-ons, including third-party add-ons, plus a number of official add-ons since their respective inceptions. If you want a cross-platform add-on standard, I hope you don't expect these three to throw their own standards over board in favour of the new standard. Otherwise, good luck developing a replacement for Pubcrawl that makes Zot-based Hubzilla compatible with ActivityPub while working on ActivityPub-based Mastodon just the same. Friendica, Hubzilla and (streams) rely on add-ons for all federation beyond their respective base protocols (DFRN, Zot, Nomad).
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.
Friendica, Hubzilla and (streams) have had support for discussion groups/forums since their respective inception. On Friendica, a group is a user account with special settings; on Hubzilla and (streams), it's a channel with special settings. In addition, especially Hubzilla and (streams) have access permission control on a level that most people for whom the Fediverse is only ActivityPub couldn't imagine in their wildest dreams. All three can be used by users from all over the Fediverse already now.
Good luck forcing Friendica to give up its 13-year-old standard that's used by Fediverse News, just to name one, and Hubzilla to give up its 11-year-old standard that blows everything else but what (streams) does out of the water. Good luck forcing them to adopt something inferior.
On the other hand, good luck forcing Lemmy and /kbin to switch to a wholly different standard. Don't forget that these two exist as well. And good luck having the Fediverse outside of Hubzilla and (streams) adopt both server-side and client-side OpenWebAuth.
And I'm not even talking about how different Fediverse projects handle threads differently. Mastodon has a Twitter-like thread structure: many posts, tied together with mentiones. Just about everything that's built on ActivityPub has taken this over. Friendica, Hubzilla and (streams) have a Facebook/blog/Tumblr-like thread structure: one post, the start post, and many comments which aren't posts. It's similar on Lemmy and /kbin which are Reddit clones, only that they don't allow thread starters to moderate their own threads.
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.
This is something that almost the whole Fediverse has implemented, save for Mastodon.
And again, Friendica has had quotes since its inception in 2010, almost six years before Mastodon was launched (which, by the way, federated with Friendica and Hubzilla on the spot). Hubzilla has had quotes since 2012, inherited from Friendica. Their way of quoting is dead-simple: BBcode. [quote][/quote] (streams) supports Markdown and HTML in addition to BBcode, but otherwise it's the same.
Oh, and by the way: Friendica, Hubzilla and (streams) have also supported quote-posts a.k.a. quote-tweets a.k.a. quote-toots a.k.a. quote-boosts from their very beginnings.
Markets. So far there's only one server implementation capable of processing payments.
At least two. Hubzilla has a payment add-on, too. It isn't installed on all hubs, but it's there.
Reply management. Starting with the replies collection and working outward from there is probably the best way to go. I love a's idea of using Add and Remove activities (or Approve and Reject with a target) to share state with addressees. I think the conversation tree could be managed about the same way.
In general, I think you've got a lot of good ideas here. The ActivityPub fork idea is terrible, though.
Groups. A good one! Join, Leave, Invite, Accept, Reject activities all help. We need to revive the members collection, which I think helps a lot towards getting private groups.
One you didn't mention was addressable contact lists -- like Circles from Google+ or Aspects from Diaspora*. A really helpful way to segment your followers and share some things with family, others with colleagues from work, and others with your friends who like trains.
>End-to-end encryption. It's time to get on this; I don't think building on top of an incompatible stack is the way to go, though
I'm interested in MLS because it promises private group messaging. Your proposal is much simpler, and doesn't require any fancy cryptography, but since we have a blank slate (no legacy implementations), I think MLS is worth considering. That being said, I don't understand how it works yet, and it is possible that MLS will be too complicated for our purposes.
>Quote Announce. This comes down to recommending content in the Announce activity.
Yes, this representation is possible too, but non-supporting servers will process it as a boost, and I think it can't be used in replies. Today almost all projects that support "quote" feature use quoteUrl (and some adopted FEP-e232) because links doesn't have these downsides.
>In general, I think you've got a lot of good ideas here. The ActivityPub fork idea is terrible, though.
No, I'm not advocating for a fork. If you are talking about https://github.com/steve-bate/activitypub-mincore - I see it as a profile, and I think it could be useful for new implementers who may not know where to start, or frustrated when their implementation doesn't federate with Mastodon.
@silverpill As for quotes, I'll write up a FEP for the way it was intended to work. Activities don't have a content property by mistake; this is exactly why it's there.
Also, I agree with @helge that we need a better definition for responses on the inbox endpoint, including error responses. But I think the error content should be in the response body, not in a header.
@silverpill I'll look closer. I'd be happy to be wrong. I think @steve is doing great work on AP and I'd be bummed if we lost his effort to an incompatible fork.
@evan Like @silverpill said, the AP MinCore "Profile" is not a fork. It is/was a thought experiment in the context of domain-specific interop profiles with a common AP foundation. You and I have discussed how conformance is not binary, but more of a continuum. The question explored in the MinCore is "what's the minimal set of features a server could implement and still be AP-conformant?". Other protocols, like Mastodon AP interop, would be a layer on top of that.
@Zerglingman In addition to actors announcing local posts, I'd like to see actors announcing tagged posts, similar to what https://relay.fedi.buzz/ provides, but implemented natively
Add comment