silverpillHow Nomadic ActivityPub (FEP-ef61) compares to other protocols?
I made a table:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#protocol-comparison
Jupiter Rowland@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity
Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
I'll think about it. As far as I know, Zot identities are keys, all data is portable and private content is possible. I guess the main difference between Zot and FEP-ef61 would be in ActivityPub interop?
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub.
No, from FEP-ef61 point of view, there's still a gateway, because Forte doesn't use canonical IDs. We can say that Forte is a client and a gateway combined in a single piece of software.
jandi@silverpill (added @jupiter_rowland)
Very interesting, thanks for the link!
I've recently started testing Holos, do you know about it? It seems to me (not a dev) that there are similarities, I hope you don't mind me tagging @HolosSocial to ask if there's something common to any of the listed projects and FEPs with Holos.
https://holos.social/how-it-works
Perhaps it merits a mention in the comparison table?
Thanks to all involved, nomadic/portable fediverse identities is a very exciting prospect.
@jandi @HolosSocial @jupiter_rowland
The similarities are superficial.
Holos is a regular ActivityPub application, where user's identity is bound to a domain name. Having a Holos account is equivalent to running a single user instance and doing continuous database backups. The difference is in the software architecture, not in the protocol: the database is located on user's phone instead of the machine where the server is running.
The how-it-works page also talks about cryptographic keys "never leaving your device". This is just misleading marketing. The location of the keys is irrelevant, because keys in ActivityPub are identified by URIs, and what an URI resolves to is controlled by a person who controls the server frontend and the domain name.
Holos Social@silverpill
The relay provides a stable identity and makes the device reachable through a tunnel.
The location of keys is not irrelevant. With custom domains, the user controls the domain and the identity. Relays become interchangeable, no Move activity needed. This is an architecture choice, not marketing.
@jandi @jupiter_rowland
The relay provides a stable identity and makes the device reachable through a tunnel.
The location of keys is not irrelevant. With custom domains, the user controls the domain and the identity. Relays become interchangeable, no Move activity needed. This is an architecture choice, not marketing.
@jandi @jupiter_rowland
@HolosSocial @silverpill @jupiter_rowland Thanks for answering. As a non-programmer, many details go over my head, but are interesting anyway... It's like reading Science-Nonfiction or something. A lot of interesting stuff is happening, there's great characters and a million wildly complicated backstories (where oneself is, somehow, involved!), but it's all true, and the "interesting stuff" can many times be fact checked and subject to proof, unlike in Sci-Fi.
@HolosSocial @silverpill @jupiter_rowland
I'll keep on reading about it, and trying new things. I wouldn't say that I (personally) have been misled with the Holos messaging, but I'd lie if I said that I understand everything implied here...
So again, thanks for your work, for answering my questions, and for looking and going in interesting directions.
@jandi @HolosSocial @jupiter_rowland In simple terms: if you don't attach your own domain name to an account, there is no portability, and that's not different from mastodon.social.
If you use your own domain, you are more independent, but you'd probably be better off hosting a full fediverse instance yourself, instead of relying on a middleman to transfer messages. There are many lightweight alternatives to Mastodon.
If you use your own domain, you are more independent, but you'd probably be better off hosting a full fediverse instance yourself, instead of relying on a middleman to transfer messages. There are many lightweight alternatives to Mastodon.
@silverpill
The relay is a tunnel, not a middleman. It cannot read or alter the content. And with E2EE DMs, even direct messages are only readable on the device.
@jandi @jupiter_rowland
The relay is a tunnel, not a middleman. It cannot read or alter the content. And with E2EE DMs, even direct messages are only readable on the device.
@jandi @jupiter_rowland
@silverpill
To sum up, Holos is not waiting for the ecosystem to agree on new standards. It exploits what is already possible within ActivityPub today.
@jandi @jupiter_rowland
To sum up, Holos is not waiting for the ecosystem to agree on new standards. It exploits what is already possible within ActivityPub today.
@jandi @jupiter_rowland
@HolosSocial It is a middleman, otherwise you wouldn't be posting about the server downtime.
It can read and alter content, impersonate users and do everything else a regular ActivityPub server can do, for reasons stated earlier (even if it currently doesn't do that).
@silverpill
Any ActivityPub server holds user identities and can technically do harmful things, including yours. With custom domains, the user owns the identity. With E2EE, DMs are unreadable by the relay. With zero-knowledge sync, the relay does not know what the device already has. With encrypted backups, data is recoverable without it. I am not inventing new protocols, I am using every possibility that already exists. What's wrong with that?
@jandi @jupiter_rowland
Any ActivityPub server holds user identities and can technically do harmful things, including yours. With custom domains, the user owns the identity. With E2EE, DMs are unreadable by the relay. With zero-knowledge sync, the relay does not know what the device already has. With encrypted backups, data is recoverable without it. I am not inventing new protocols, I am using every possibility that already exists. What's wrong with that?
@jandi @jupiter_rowland
@HolosSocial Please don't fight or I'll feel guilty for asking!
I think @silverpill comment of "just misleading marketing" might've been facilitated by me entering a protocol thread with a question that wasn't exactly precise.
Apart from that, I love that you have taken the time to try and explain stuff to me.
You all seems to be pursuing gains in independence from big orgs and healthy federation, a better web overall.
Extra apologies to @jupiter_rowland (Hubzilla seems fascinating btw!)
@jandi
No fight from my side, I think it mostly comes from a misunderstanding. I never claimed Holos brings new things like FEPs to the Fediverse. I leave that to the experts and have no pretension about it. But some messages were quite reductive about what Holos actually offers, so I just wanted to set the record straight.
@silverpill @jupiter_rowland
No fight from my side, I think it mostly comes from a misunderstanding. I never claimed Holos brings new things like FEPs to the Fediverse. I leave that to the experts and have no pretension about it. But some messages were quite reductive about what Holos actually offers, so I just wanted to set the record straight.
@silverpill @jupiter_rowland
@jandi (Hubzilla seems fascinating btw!)
It's a monster that can be a challenge to tackle if you expect something that works like Mastodon. But on the plus side, it may have the best built-in documentation of all Fediverse server applications, and it has got its own support forum.
Oh, and nomadic identity works as advertised.
CC: @silverpill @Holos Social
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #NomadicIdentity
It's a monster that can be a challenge to tackle if you expect something that works like Mastodon. But on the plus side, it may have the best built-in documentation of all Fediverse server applications, and it has got its own support forum.
Oh, and nomadic identity works as advertised.
CC: @silverpill @Holos Social
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #NomadicIdentity
ValorZard@silverpill im really excited for this to finally get standarized!
one question though -> do you know if mastodon as an organization would be willing to implement this once its more stabilized? My stuff is on mastodon and I'm not super willing to move everything over to somewhere else.
one question though -> do you know if mastodon as an organization would be willing to implement this once its more stabilized? My stuff is on mastodon and I'm not super willing to move everything over to somewhere else.
@valorzard As far as I know, they are not interested.
However, @jonny wants to implement FEP-1580: https://github.com/mastodon/mastodon/issues/12423#issuecomment-4247163209
FEP-1580 doesn't introduce decentralized identities, but it enables data migrations and is easier to implement. It might pave the way for FEP-ef61 in the future.
@ValorZard No dice.
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity
@jupiter_rowland @silverpill …. Well I guess that sucks for mastodon users I guess, if this story is true
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon
I think they can do the same thing I did - rebuild server as a client. It would be a pain to package though, given that Mastodon is written in Ruby.