In a comment in July last year in a thread on fediverse history, which I didn’t want to pollute with my hot takes …
That’s partly because of ActivityPub soaking up all the oxygen in the social web space, leading to people neglecting XMPP and Matrix, either of which has almost everything you need to build a FarceBook replacement, which much as I love ActivityPub, it does not (although with enough FEP process, maybe one day it could).
The best of the XMPP and Matrix apps are already a functioning replacement for FarceBook Messenger and WhatSapp. I suspect Matrix apps will be an even better replacement after the current wave of deep refactoring work on the protocol and apps is completed. Things like Sliding-Sync, MLS replacing MegOlm for group encryption, and so on. Conversations, Snikket and other newer XMPP projects are doing a great job of bringing the Jabber-era UI of older XMPP apps into the 21st century.
But what’s really lacking across the whole federated social web, as many people have commented on at length, is a fully portable identity system that can be used across the social web, regardless of server-to-server protocols used. One that would allow people to use one set of credentials to log in to different social servers, for different purposes. For example, for publishing activities they could log into different servers for microposting (eg Mastodon, BlueSky), blogging (eg WriteFreely, Ghost), podcasting (eg PeerTube CastoPod), livestreaming (OwnCast), and so on. For private one-to-one or group conversations, they could log in to an XMPP or Matrix server. For public group conversations, like could log in either servers using AP, XMPP, Matrix or even IRC.
Bottom line: non-geeks don’t care about protocols (and even a lot of geeks don’t in our role as “users”). If the technology is really working, it should be invisible, and that includes federation protocols.
I’m keen to keep this thread focused on the topic at hand. So I’ll respond to your Matrix question in a separate thread.
This is exciting news. Is there work underway on an FEP laying out how to use it in an AP app? What else might help us get to a place where we can use it for strapping together multiple services, to create a FB killer?
If you’re interested in ActivityPub portable identity there is FEP-ef61.
FEP-ef61 identities are not attached to servers and can be used across different ActivityPub services.
This (and some others) are based on @macgirvin 's pioneering work with the Zot protocol, yes? Again, very exciting stuff. Is there any relationship between this and what @erlend_sh and co are doing with Weird.one? Could there be?
Yes, it is based on his work and other protocols that offer key-based identity. Mike recently implemented this FEP in Streams, although it is not clear what will happen next, because Streams is now superseded by Forte: Jupiter Rowland - jupiter_rowland@hub.netzgemeinde.eu
As far as I know, weird.one uses a different data format (not ActivityStreams), so our protocols are not compatible.
I saw that, and started a fedi post about it, which became blog length, then I got distracted.
What usually happens when Mike forks a project is that he carries on exactly what he was doing on the old project, by himself, with last clutch of contributors taking over the last project. Reading the tea leaves, I’m guessing the main reason for this fork is that now he’s integrated the missing Zot features into AP via those FEPs, he can draw a line under the Zot years, and commit Forte to being an AP app; “An open source ActivityPub/fediverse server.”
I’m commenting above my paygrade here (I hope @erlend_sh or @macgirvin can clarify), but that doesn’t make sense to me. ActivityStreams is a data format for social network protocols (first the Pump API, then ActivityPub). Weird.one is some sort of identity/ authentication/ SSO standard, not a social network protocol, so it seems logical it would use a different data format. But that doesn’t necessarily make it incompatible, does it?
Another example; ForgeFed uses FFF as a data format, but that doesn’t make it incompatible with AP networks.