#nomadicidentity — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #nomadicidentity, aggregated by home.social.
-
@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 -
@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 -
@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 -
@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 -
@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 -
@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 -
Announcing Mitra Mini v0.1.0
Mitra Mini is an ActivityPub client that implements nomadic identity. It has become stable enough that I decided to cut the first release.
The basic features have been implemented: posts, reposts, likes. For more information, check the project's readme:
https://codeberg.org/silverpill/minimitra
It all started nearly four years ago with a vague idea that linking cryptographic keys to #ActivityPub actors could unlock decentralized identity in Fediverse. Eventually, the solution was discovered, and implemented by several projects, but these implementations were servers, not clients. Now there is finally a client, and the design has been proven to work well.
-
@HarkMahlberg That's because Hubzilla has a feature called nomadic identity (https://joinfediverse.wiki/Nomadic_identity).
The channel that I'm replying from, here on hub.netzgemeinde.eu, has a clone on hub.hubzilla.de. A full, live, hot, bidirectional, near-real-time backup that I can use just like the original. This is a feature that some are trying to invent right now, but that "proto-Hubzilla" has had since 2012.
Within Hubzilla, both instances of my channel count has having the exact same identity, [email protected], and as being one thing, only that this thing exists in two places simultaneously.
However, the non-nomadic Fediverse neither knows nor understands nomadic identity. It sees the two instances of my channel as two fully separate identities. Thus, I guess lots of Mastodon users must have blocked me for having an unlabelled bot.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #NomadicIdentity -
@洪 民憙 (Hong Minhee) :nonbinary: Two people you may consider consulting in this case:
- @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
His streams repository, a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, is the place where he laid the foundations of FEP-ef61 out of necessity because he was working on nomadic identity via ActivityPub (Hubzilla and (streams) use their own protocols for that), and it was the first nomadic server software that had it implemented.
Also, his Forte, itself a fork of the streams repository, is the only Fediverse server software that uses nothing but ActivityPub to establish nomadic identity and relies on FEP-ef61 to do that. Basically, it's (streams) with no Nomad and Zot6 support, and syncing between clones is triggered by a cronjob because, unlike Zot6 and Nomad, ActivityPub doesn't provide any ways to trigger immediate, near-real-time syncs.
Mike hasn't been caught online for quite a while, though, although he's still working on both (streams) and Forte. - @silverpill is gradually turning Mitra from a typical non-nomadic, account/login-equals-identity, one-identity-per-account Fediverse software into something that's every bit as nomadic as Hubzilla, (streams) and Forte while casting everything necessary for this process into FEPs.
I'm not sure whether this will include containerising identities like the channels on Hubzilla, (streams) and Forte and allowing multiple fully independent identities on the same account, just like the same identity (channel) would be able to exist on independent accounts on different servers.
That said, is your goal only to use FEP-ef61 for identities that are tied to their accounts and their servers? Or is your goal fully-fledged nomadic identity on the same level as on Forte?
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #Mitra #NomadicIdentity #FEP_ef61 - @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
-
CW: Many innovations that are being "brought to the Fediverse" have been in the Fediverse for a decade or longer; CW: long (over 2,500 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
Whenever someone announces to "bring" something "to the Fediverse", chances are that Friendica has actually had it since 2010, for five and a half years longer than Mastodon has been around.
For example, just about everyone on Mastodon is fully convinced that Eugen Rochko has brought quote-posts to the Fediverse this year. That's because next to nobody on Mastodon knows that Friendica has been able to quote-post practically everything in the Fediverse, including Mastodon toots, for 15 years now.
And if Friendica doesn't have it, chances are still that Hubzilla has it, and that Hubzilla has probably had it for longer than Mastodon has been around, too.
For example, private messages that are actually private. Mastodon doesn't have them because the "privacy" of Mastodon DMs is only "guaranteed" by limiting whom a DM is sent to. Hubzilla does have them and has had them since 2012, since it was still named Red. How? Because Hubzilla also limits who is permitted to see a DM.
Oh, and Hubzilla even offers optional encryption on top of that.
Or how about server-independent identity? Everyone still waiting for Bluesky to finally be the pioneer who invents this and implements it for the first time? LOL! Once again, Hubzilla has had this since 2012. Not a vague concept, not an unstable proof-of-concept, but daily-driven by production-grade channels on production-grade servers. (streams) has it, too, inherited from Hubzilla through a whole number of forks. Forte has it, too, and Forte is the first and, so far, only Fediverse server software that uses ActivityPub for nomadic identity.
Now I'm waiting for someone to announce that something will "bring" actual groups "to the Fediverse". A feature that was actually introduced to the Fediverse by StatusNet in 2008, and that's also available on Friendica, Hubzilla, (streams) and Forte. Not to mention that the very principle of the Threadiverse (Lemmy, the remains of /kbin, Mbin, PieFed) is based on groups.
This is what happens when you think that the feature set of the whole Fediverse is the feature set of Mastodon and maybe Pixelfed because that's all you know.
Speaking of Mastodon: Just because it's being "brought to the Fediverse", doesn't mean it'll be adopted by Mastodon.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentrism #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #StatusNet #Threadiverse #Lemmy #/kbin #Mbin #PieFed #Groups #FediGroups #FediverseGroups -
CW: Many innovations that are being "brought to the Fediverse" have been in the Fediverse for a decade or longer; CW: long (over 2,500 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
Whenever someone announces to "bring" something "to the Fediverse", chances are that Friendica has actually had it since 2010, for five and a half years longer than Mastodon has been around.
For example, just about everyone on Mastodon is fully convinced that Eugen Rochko has brought quote-posts to the Fediverse this year. That's because next to nobody on Mastodon knows that Friendica has been able to quote-post practically everything in the Fediverse, including Mastodon toots, for 15 years now.
And if Friendica doesn't have it, chances are still that Hubzilla has it, and that Hubzilla has probably had it for longer than Mastodon has been around, too.
For example, private messages that are actually private. Mastodon doesn't have them because the "privacy" of Mastodon DMs is only "guaranteed" by limiting whom a DM is sent to. Hubzilla does have them and has had them since 2012, since it was still named Red. How? Because Hubzilla also limits who is permitted to see a DM.
Oh, and Hubzilla even offers optional encryption on top of that.
Or how about server-independent identity? Everyone still waiting for Bluesky to finally be the pioneer who invents this and implements it for the first time? LOL! Once again, Hubzilla has had this since 2012. Not a vague concept, not an unstable proof-of-concept, but daily-driven by production-grade channels on production-grade servers. (streams) has it, too, inherited from Hubzilla through a whole number of forks. Forte has it, too, and Forte is the first and, so far, only Fediverse server software that uses ActivityPub for nomadic identity.
Now I'm waiting for someone to announce that something will "bring" actual groups "to the Fediverse". A feature that was actually introduced to the Fediverse by StatusNet in 2008, and that's also available on Friendica, Hubzilla, (streams) and Forte. Not to mention that the very principle of the Threadiverse (Lemmy, the remains of /kbin, Mbin, PieFed) is based on groups.
This is what happens when you think that the feature set of the whole Fediverse is the feature set of Mastodon and maybe Pixelfed because that's all you know.
Speaking of Mastodon: Just because it's being "brought to the Fediverse", doesn't mean it'll be adopted by Mastodon.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentrism #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #StatusNet #Threadiverse #Lemmy #/kbin #Mbin #PieFed #Groups #FediGroups #FediverseGroups -
CW: Many innovations that are being "brought to the Fediverse" have been in the Fediverse for a decade or longer; CW: long (over 2,500 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
Whenever someone announces to "bring" something "to the Fediverse", chances are that Friendica has actually had it since 2010, for five and a half years longer than Mastodon has been around.
For example, just about everyone on Mastodon is fully convinced that Eugen Rochko has brought quote-posts to the Fediverse this year. That's because next to nobody on Mastodon knows that Friendica has been able to quote-post practically everything in the Fediverse, including Mastodon toots, for 15 years now.
And if Friendica doesn't have it, chances are still that Hubzilla has it, and that Hubzilla has probably had it for longer than Mastodon has been around, too.
For example, private messages that are actually private. Mastodon doesn't have them because the "privacy" of Mastodon DMs is only "guaranteed" by limiting whom a DM is sent to. Hubzilla does have them and has had them since 2012, since it was still named Red. How? Because Hubzilla also limits who is permitted to see a DM.
Oh, and Hubzilla even offers optional encryption on top of that.
Or how about server-independent identity? Everyone still waiting for Bluesky to finally be the pioneer who invents this and implements it for the first time? LOL! Once again, Hubzilla has had this since 2012. Not a vague concept, not an unstable proof-of-concept, but daily-driven by production-grade channels on production-grade servers. (streams) has it, too, inherited from Hubzilla through a whole number of forks. Forte has it, too, and Forte is the first and, so far, only Fediverse server software that uses ActivityPub for nomadic identity.
Now I'm waiting for someone to announce that something will "bring" actual groups "to the Fediverse". A feature that was actually introduced to the Fediverse by StatusNet in 2008, and that's also available on Friendica, Hubzilla, (streams) and Forte. Not to mention that the very principle of the Threadiverse (Lemmy, the remains of /kbin, Mbin, PieFed) is based on groups.
This is what happens when you think that the feature set of the whole Fediverse is the feature set of Mastodon and maybe Pixelfed because that's all you know.
Speaking of Mastodon: Just because it's being "brought to the Fediverse", doesn't mean it'll be adopted by Mastodon.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentrism #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #StatusNet #Threadiverse #Lemmy #/kbin #Mbin #PieFed #Groups #FediGroups #FediverseGroups -
CW: Many innovations that are being "brought to the Fediverse" have been in the Fediverse for a decade or longer; CW: long (over 2,500 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
Whenever someone announces to "bring" something "to the Fediverse", chances are that Friendica has actually had it since 2010, for five and a half years longer than Mastodon has been around.
For example, just about everyone on Mastodon is fully convinced that Eugen Rochko has brought quote-posts to the Fediverse this year. That's because next to nobody on Mastodon knows that Friendica has been able to quote-post practically everything in the Fediverse, including Mastodon toots, for 15 years now.
And if Friendica doesn't have it, chances are still that Hubzilla has it, and that Hubzilla has probably had it for longer than Mastodon has been around, too.
For example, private messages that are actually private. Mastodon doesn't have them because the "privacy" of Mastodon DMs is only "guaranteed" by limiting whom a DM is sent to. Hubzilla does have them and has had them since 2012, since it was still named Red. How? Because Hubzilla also limits who is permitted to see a DM.
Oh, and Hubzilla even offers optional encryption on top of that.
Or how about server-independent identity? Everyone still waiting for Bluesky to finally be the pioneer who invents this and implements it for the first time? LOL! Once again, Hubzilla has had this since 2012. Not a vague concept, not an unstable proof-of-concept, but daily-driven by production-grade channels on production-grade servers. (streams) has it, too, inherited from Hubzilla through a whole number of forks. Forte has it, too, and Forte is the first and, so far, only Fediverse server software that uses ActivityPub for nomadic identity.
Now I'm waiting for someone to announce that something will "bring" actual groups "to the Fediverse". A feature that was actually introduced to the Fediverse by StatusNet in 2008, and that's also available on Friendica, Hubzilla, (streams) and Forte. Not to mention that the very principle of the Threadiverse (Lemmy, the remains of /kbin, Mbin, PieFed) is based on groups.
This is what happens when you think that the feature set of the whole Fediverse is the feature set of Mastodon and maybe Pixelfed because that's all you know.
Speaking of Mastodon: Just because it's being "brought to the Fediverse", doesn't mean it'll be adopted by Mastodon.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentrism #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #StatusNet #Threadiverse #Lemmy #/kbin #Mbin #PieFed #Groups #FediGroups #FediverseGroups -
CW: Many innovations that are being "brought to the Fediverse" have been in the Fediverse for a decade or longer; CW: long (over 2,500 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
Whenever someone announces to "bring" something "to the Fediverse", chances are that Friendica has actually had it since 2010, for five and a half years longer than Mastodon has been around.
For example, just about everyone on Mastodon is fully convinced that Eugen Rochko has brought quote-posts to the Fediverse this year. That's because next to nobody on Mastodon knows that Friendica has been able to quote-post practically everything in the Fediverse, including Mastodon toots, for 15 years now.
And if Friendica doesn't have it, chances are still that Hubzilla has it, and that Hubzilla has probably had it for longer than Mastodon has been around, too.
For example, private messages that are actually private. Mastodon doesn't have them because the "privacy" of Mastodon DMs is only "guaranteed" by limiting whom a DM is sent to. Hubzilla does have them and has had them since 2012, since it was still named Red. How? Because Hubzilla also limits who is permitted to see a DM.
Oh, and Hubzilla even offers optional encryption on top of that.
Or how about server-independent identity? Everyone still waiting for Bluesky to finally be the pioneer who invents this and implements it for the first time? LOL! Once again, Hubzilla has had this since 2012. Not a vague concept, not an unstable proof-of-concept, but daily-driven by production-grade channels on production-grade servers. (streams) has it, too, inherited from Hubzilla through a whole number of forks. Forte has it, too, and Forte is the first and, so far, only Fediverse server software that uses ActivityPub for nomadic identity.
Now I'm waiting for someone to announce that something will "bring" actual groups "to the Fediverse". A feature that was actually introduced to the Fediverse by StatusNet in 2008, and that's also available on Friendica, Hubzilla, (streams) and Forte. Not to mention that the very principle of the Threadiverse (Lemmy, the remains of /kbin, Mbin, PieFed) is based on groups.
This is what happens when you think that the feature set of the whole Fediverse is the feature set of Mastodon and maybe Pixelfed because that's all you know.
Speaking of Mastodon: Just because it's being "brought to the Fediverse", doesn't mean it'll be adopted by Mastodon.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentrism #MastodonNormativity #Friendica #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #StatusNet #Threadiverse #Lemmy #/kbin #Mbin #PieFed #Groups #FediGroups #FediverseGroups -
@Strypey
That's a pretty major UX fail right there.
Any progress on finalising an FEP for using nomadic identity with AP?
I think it'll take more than that one FEP (FEP-ef61 Portable Objects) to do that. I expect @silverpill to whip up more FEPs in the on-going process of turning Mitra from something like most Fediverse software (non-nomadic, account equals identity) into something that's every bit as nomadic as Forte.
Thing is, Mitra still has a long way to go, also because it aims to have an implementation of nomadic identity that's entirely covered by FEPs. Forte has nomadic identity via ActivityPub, but that's technology adopted from Zot/Nomad that needed to be made to work first and foremost with no regards for FEPs.
Besides, the existence of FEPs doesn't matter as long as Mastodon refuses to adopt them. And Mastodon has already silently rejected client-side support for OpenWebAuth magic sign-on by refusing to merge an existing, ready-to-merge pull request that would have implemented it immediately.
This means we'll probably never even see Mastodon become capable of recognising nomadic channels. And I'm not talking about Mastodon going nomadic itself (which, by the way, would also give Mastodon the easy account moving that its users have been craving for for so long).
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Mitra #Forte #NomadicIdentity #FEP_ef61 -
@Strypey
Groups are tied permanently to the originating server.
Not true for Hubzilla forums as well as (streams) and Forte groups.
I could set up a Hubzilla forum channel that simultaneously resides on half a dozen or more fully independent servers. All instances of the channel will incrementally back themselves up to all other instances of the channel in near-real-time, bidirectionally.
One server goes down, I still have 100% identical living copies on all the other servers.
The miracle of nomadic identity. Established in 2012, daily-driven on production channels for longer than Mastodon itself.
Literally the only disadvantage is that the non-nomadic parts of the Fediverse, including Mastodon, will perceive each clone as its own separate Fediverse account.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@The Nexus of Privacy Unfortunately, I can't join that discussion for some reason.
Just so much, @Emelia 👸🏻: Most of my Fediverse data and identities are anything but locked to any instance. All my Hubzilla and (streams) channels are nomadic and cloned across two fully independent servers each. I could make more clones, I could declare any clone the new main instance, and no matter which server goes offline, my channels will carry on.
Each of these servers corresponds not to an ATmosphere PDS and not to a full ATmosphere PDS/relay/AppView stack either, but to a Mastodon server, only that these servers use something else than ActivityPub as their primary protocol and ActivityPub only as an optional extra protocol. However, with the creation of Forte in August, 2024, this technology was first implemented entirely with ActivityPub.
This technology is neither new nor experimental; in fact, it has been around for longer than Mastodon, much less Bluesky: It was conceived in 2011 and first implemented on a precursor of Hubzilla in mid-2012.
CC: @Martin Holland @Rob Ricci
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #PortableIdentity #NomadicIdentity -
@Ben Pate 🤘🏻 Well, I'm used to having not only full native data portability, but even live, hot, bidirectional, real-time updates of entire Fediverse identities that contain stuff which 99% of the Fediverse doesn't support. Natively without an external application. Available for longer than Mastodon itself. Between any number of independent servers. So I'm not easily impressed.
I would be kind of impressed if LOLA managed to move a Mastodon account into a brand-new, virgin Hubzilla channel- automatically activating all necessary apps from PubCrawl to Privacy Groups to Superblock to NSFW if the Mastodon account has at least one hiding filter
- activating all features that are either hard-coded or switched on on the Mastodon source account, but off by default on new Hubzilla channels
- (optionally) setting the channel role to Custom and configuring it in such a way that Hubzilla behaves as closely to Mastodon as possible, permissions-wise
- translating all followers and followed into Hubzilla's system of Facebook-style mutual-by-default contacts
- reconnecting all followers and followed on their end
- translating each Mastodon list into a Hubzilla privacy group, all members included while keeping the default "Friends" privacy group and adding all contacts to it
- converting followed hashtags into FediBuzz contacts (Hubzilla cannot follow hashtags, but we want the Hubzilla destination channel to be as close to the Mastodon source account as possible)
- translating not only the entire timeline of the Mastodon source account into a Hubzilla stream, but also importing entire threads behind and around each post in the timeline (this is absolutely necessary for the Mastodon user to keep their replies to other people's posts because a Hubzilla comment cannot exist without the start post and the entire branch of the conversation that led to it; also, it's a Hubzilla killer feature over Mastodon that you always see entire conversations instead of single-message piecemeal)
- transferring all posts, replies and DMs with all media in them
- converting Mastodon's loosely-tied threads, no matter who has started them, into Hubzilla-style enclosed conversations as per FEP-171b Conversation Containers with unified permissions for all messages within a conversation
- translating mentions and links into Hubzilla-specific markup
- translating faves into thumbs up
- translating Mastodon 4.6-style quotes into Hubzilla-style shares, automatically recognising which Hubzilla version the destination channel is running on and deciding which Hubzilla share format to use
- translating CWs in comments into
[summary][/summary]tags (this would require Hubzilla to actually fully support summaries in comments which it currently doesn't because that doesn't make sense from a Facebook/blogging POV) - translating Mastodon's post visibility settings into Hubzilla's permission system as far as that's possible (only for start posts, that is, because comments always inherit their permissions from the start post; also, this will have to be done after taking care of all contacts because "followers only" Mastodon toots will have to be converted into non-public posts which grant permission to see them only to the "Friends" privacy group, and likewise, DMs will have to have the contact(s) to whom they were originally sent assigned as those who are permitted to see them)
- importing all images, videos and other attached files into the Hubzilla channel's file space, including appropriate permission settings and, ideally, sorting them into Hubzilla-style "year-month" folders
- converting all media attachments into embedded links to the locations of the respective media files in the file space, including adding alt-texts to the embedding code
- importing the block list on the Mastodon source account into Superblock (that is, Hubzilla cannot block entire servers, but maybe this could automatically be translated into filter lines)
- converting blocking filters into channel-wide filter lines, converting bare keywords into regular expressions if the whole word option is set for these keywords on Mastodon
- adding the keywords of hiding filters to NSFW, converting bare keywords into regular expressions if the whole word option is set for these keywords on Mastodon
- translating the selected languages on the Mastodon source account into channel-wide filters on Hubzilla (even though this probably won't work exactly identical because Hubzilla neither sets nor knows per-message language settings)
- recognising the contents of Mastodon's free-text profile fields and moving them into the appropriate ones of Hubzilla's several dozen purpose-bound profile fields
- populating Hubzilla's keyword field with all hashtags found in the profile text of the Mastodon source account
- setting your channel language according to the language that most of your posts are in
- bonus points for entering Mastodon's colours into the Redbasic colour settings and changing the PDL layout settings so that the look of the Hubzilla destination channel is closer to that of the Mastodon source account than by default
Even that wouldn't give you a 100% identical copy of your Mastodon account. Hubzilla doesn't support quote-post control; the only way to make your posts non-quote-postable is by making them non-public (something that Mastodon can only understand as a DM), and you have no control whatsoever over the permissions of your comments on other people's posts anyway. Also, as I've already mentioned, Hubzilla currently doesn't support summaries (= Mastodon CWs) in comments.
However, vice versa, it'd be even harder to shoehorn Hubzilla's wealth of features into a new Mastodon account.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #NomadicIdentity #LOLA -
FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/717
- Added a section explaining how to compare 'ap' URIs.
- Origin tuples are replaced with "cryptographic origins". The result is the same, but now we don't have to use port 0.
- Outboxes and FEP-ae97 are not required anymore. This means implementers can use a different activity synchronization mechanism. -
@Der Pepe (Hubzilla) ⁂ Was ist faktisch passiert? Amerikanische Bundesbehörden haben sich unter merkwürdigen Namen bei Bluesky angemeldet und Statements gebracht wie "nah Bluesky, wir haben gehört das ist ein schöner Platz". Es hanelt sich also offenbar um ein politisch gezieltes Trolling einer linksliberalen Plattform, die aufgrund ihrer Struktur technisch keine Möglichkeit bietet, von autoritären Strukturen oder Einzelpersonen übernommen zu werden.
Ich empfehle die ersten Minuten vom Podcast #hakendran. @Gavin Karlmeier spricht hier, wenn ich es richtig in Erinnerung habe, von "kollaborierten Trolling". Es ist also eher ein Aktion, die Bluesky torpedieren soll, weil es eben ein Dorn im Auge ist. Dass damit die ganzen Leute, die jetzt an dem Aufschrei beteiligt sind, eigentlich im Sinne der amerikanischen Regierung agieren und freiwillige Helfershelfer, "nützliche Idioten", sind, merken sie gar nicht.
#^
Trollenspiel und Gesichtsverlust (mit Dennis Horn)
by Haken dran – das Social-Media-Update der c't on YouTube
An dem ganzen Aufschrei beweist sich aber vor allem eines: Gar nicht mal so sehr, dass das Mastodon Umfeld eben doch mehr Twitter/X ist als es immer selbst zu glauben scheint, weil es sich nämlich einfach aufscheuchen lässt, sondern es zeigt, dass die allgemeine Vorstellung von Nerds auf Mastodon völlig verkehrt ist. Anhand der Bluesky Diskussion würde ich sagen, basiert das technische Verständnisse auf der Ebene, das auch mein Hund hat. Paradoxerweise erwartet diese Bubble, die sich jetzt empört, ein zentralistisches Eingreifen, dabei haben sich objektiv gesehen einfach nur Regierungsbehörden angemeldet, die als Regierungsbehörden mit einem Haken verifiziert wurden.
Technisch zu Bluesky. Die Mastodon Bubble beweist ihr technisches Unverständnis, und es schwappt auch zu anderen Bubbles im Fediverse rüber, ich lese auch von Leuten, die bei Sharkey sind, einfach nur Dinge, wo ich den Kopf schütteln muss. Was ist denn überhaupt Bluesky? Bluesky ist der Name der Firma, die das AT Protokoll entwickelt und die erste Applikation geschrieben hat. Das AT Protokoll, das sie entwickeln, ist aber unabhängig von der Firma. Dieses Protokoll war die Antwort auf ActivityPub, bei dem klassisch wie bei X/Twitter und anderen alten Socialmedia Systemen der Nutzer seine Beiträge, Follower, Likes etc, bei einer konkreten Firma bzw. der angebotenen Socialmedia Plattform speichert. Geht jemand von X weg, sind seine Beiträge verloren. Alles, was er geschrieben hat, ist verloren. Bei Mastodon ist es sehr ähnlich. Die Nutzer melden sich bei einer Instanz an und überlassen dann ihre Beiträge und die Moderation vollständig dem Instanzinhaber. Mittlerweile wurde das Problem erkannt:
#^http://tiny.cc/392u001
Beim AT Proto ist das gänzlich anders. Die persönlichen Daten, also alles, was Du schreibst, gehört Dir, nicht Bluesky. Man ist auch nicht "auf Bluesky", sondern die eigenen Daten sind getrennt von Anbieter, Firma und deren Strukturen. Man spricht hier von "personal data server" (PDS). Diesen PDS kann ich natürlich von Bluesky verwalten lassen, aber auch von Alternativen wie Blacksky, und derzeit in Arbeit Northsky oder Eurosky. Ich kann diesen PDS aber auch zu Hause auf einem Server liegen haben oder mir irgendwo einen Server anmieten, wo ich meine Daten lagere. Mein PDS liegt auf dem gleichen Server wie meine Hubzilla Instanz. Wenn Bluesky ausfällt oder mir eben die Moderation nicht gefällt, kann ich über Blacksky ins AT Proto Netzwerk gehen, oder eine andere Alternative. Ich kann beim Ausfall aller derzeitigen Zugänge für "Bluesky" auch einfach meinen PDS liegen lassen und irgendwann wieder ins AT Proto gehen und bin eben Herr meiner Daten, was Mastodon Nutzerinnen eben so nicht kennen.
Deswegen entstehen allerdings auch Besonderheiten in der Moderation, Paul Frazee hat dazu geschrieben.
#^Update on Protocol Moderation - Paul's LeafletsWhere account takedowns happen is important
Die Moderation verläuft im ATProto nach einem Labelsystem. Beiträge werden gelabelt und die Nutzerin kann entscheiden, welche Beiträge sie mit einer Verwarnung versehen lassen oder ganz ausblenden möchte. Die Moderationsservices sind zudem unabhängig von Bluesky, ich kann z.b. einen Moderationsservice der schwarzen Community abonnieren, weil ich den begründeten Verdacht habe, dass die Member dieses Teams ein besseres Verständnis von Diskriminierung haben als das wohl mehrheitlich weiße Bluesky Team. Ich kann auch den Moderationsservice von medizinischen Teams abonnieren, die medizinische Falschinformationen als solche labeln. Kurzum, bei "Bluesky" ist also nicht nur der eigenen Datenserver völlig unabhängig von Bluesky, auch die Moderation ist unabhängig.
Mastodon Nutzerinnen, die von "Bluesky" zu Mastodon wechseln, machen also etwas kurioses: sie geben ihren "personal data server" und die Möglichkeit kompetenter Moderation auf und wechseln zu einem System, wo sie dem Instanzinhaber nicht nur ihre Daten zuschreiben, sondern auch die Moderationskompetenz in allen Bereichen zutrauen. Es ist eben ein viel stärkerer Rückfall in Twitter/X Strukturen. Wären sie wenigstens zu Hubzilla oder (streams) gegangen, wo man mit der nomadischen Identität die Kontrolle behält, oder hätte eine eigene Fedinstanz aufgesetzt, um Herr ihrer Daten zu bleiben, aber diejenigen, die jetzt einfach zu einer Mastodon Instanz wechseln und auf Bluesky schimpfen, haben offensichtlich gar nicht das AT Proto System verstanden und Twitter/X steckt tatsächlich noch mehr in ihnen drin als ihnen lieb ist.
Dabei könnte man auch einfach sagen: Mir gefällt das Fediverse besser, deshalb bin ich da. Aber das wäre natürlich zu einfach.
#ATProto #Bluesky #Socialmedia #NomadicIdentity -
@Decenta Lyzed @your purple friend AFAIK, Mitra has not rolled out full-blown nomadic identity yet (as in, no, you can't clone your Mitra identity between two Mitra servers). Even the development branch is only in a state in which it understands nomadic identity.
As for what nomadic identity is: https://joinfediverse.wiki/Nomadic.identity
There are three Fediverse server applications where you're guaranteed to have solid, proven-to-work nomadic identity:- Hubzilla
Fork of fork of (non-nomadic) Friendica by Friendica's creator
2012/2015
https://hubzilla.org
https://en.wikipedia.org/Hubzilla
https://joinfediverse.wiki/Hubzilla
Server lists:
https://hubzilla.fediverse.observer/list
https://fedidb.com/software/hubzilla?version=latest®istration=open
No iOS apps
No Android apps
Can be installed as a Progressive Web App - (streams)
Fork of fork of three forks of fork (of fork?) of Hubzilla by the same creator
2021
Intentionally and officially no name, no brand, hence the parentheses around the unofficial name ("(streams)")
No official website
https://codeberg.org/streams/streams
Open-registration server in North America (USA):
https://rumbly.net/register
Open-registration server in Europe (Hungary, German admin, speaks German and English):
https://nomad.fedi-verse.hu/register
No iOS apps
No Android apps
Can be installed as a Progressive Web App - Forte
Fork of (streams) by the same creator
2024
No official website
https://codeberg.org/fortified/forte
No open-registration servers
No iOS apps
No Android apps
Can be installed as a Progressive Web App
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity - Hubzilla
-
Notes on the implementation of Data Portability in #tootik
https://github.com/dimkr/tootik/blob/v0.19.0/FEDERATION.md#data-portability
-
@Kris I migrated from #Diaspora in 2018/2019, mainly because of it's restricted federation but it was first now, when my hub was offline for a few days, that it came to my mind that I should make use of the #nomadic identity feature. Being not the most technical person whith computer stuff, it was just for me to login to another hub that I had used for some federation tests a while back and click on clone channel. -
Cloning a channel means having your complete data living on two (or more) different servers. That's how your #Fediverse identity becomes independent from the servers. It becomes "nomadic".
#nomadicidentity
Frank Aerror wrote the following post Wed, 27 Aug 2025 01:21:44 +0200 I am pretty impressed over how well and smooth the cloning of my #hubzilla channel worked. -
#tootik implemented FEP-ef61
We have 3 independent implementations now:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#status
@dimkr #fep_ef61 #NomadicIdentity
RE: https://hd.206267.xyz/post/0198d701-8bdd-71f2-bd56-9f381e18f15f
-
I've made several changes to FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/pulls/668
Section "Authentication and authorization" explains the differences between portable objects and non-portable objects (FEP-fe34):
- Cryptographic origins are used instead of RFC-6454 web origins.
- Portable objects can't be fetched from their origins.Activities delivered to an inbox MUST NOT be forwarded more than once (to avoid infinite loop). Requirements related to outbox implementation has been clarified.
Gateways SHOULD implement FEP-ae97 actor registration process (previously it was MAY).
-
@Ben Pate 🤘🏻
What if moving a server looked like this:
1. sign up for new account
2. authenticate old account (OAuth, whatever)
3. click "migrate"
4. click "yes really"
5. celebrate
If this were possible, then a whole lot of people could become "server admins" without being IT nerds.
Reality on Hubzilla for longer than Mastodon, as well as on (streams) and Forte:- Register a new account.
- Optionally: Wait for it to be manually activated by the admin.
- Be asked to create a channel (= the actual identity with posts and contacts and files and stuff; your account is not your identity).
- Choose the option to move an existing channel.
- Enter the URL of the existing channel.
- Enter the password of the account on which the existing channel is located.
- Confirm
- A clone of the channel is created on the new server.
- The data of the existing channel is mirrored to the clone.
- The clone is promoted to main instance of the channel; the already existing instance of the channel is demoted to clone.
- The ID of your channel is changed accordingly.
- All nomadic contacts (= on Hubzilla, (streams) or Forte) are automatically changed to the new ID.
- (streams) and Forte only: All non-nomadic contacts receive a new connection request.
- The former-main-instance-and-now-clone is deleted because you chose to move rather than clone.
- If there are no other channels on the account on the old server, the whole account is deleted because accounts cannot exist with no channels on them.
The only two differences between cloning and moving are that cloning leaves your main instance intact instead of deleting it, and it leaves it as your main instance by default rather than making the new clone your main instance.It works for Discord, why not the Fediverse?
It's a common misconception, probably even by FLOSS devs, that "server" on Discord that a handful of clicks on the Web interface inserts a new 19" rack iron into a rack inside some data centre with a LAMP stack and an installation of the Discord server backend on it and makes you the tech admin. Or something like that.
This is far from the truth. Discord has integrated the word "server" into its newspeak. On Discord, "server" means "chat room". A chat room on the same centralised, corporate-owned, commercially-operated server farm as all the other "servers".
At the same time, Generation Z and newer think that this is what "server" always means because they've never come into contact with TeamSpeak and never experienced LAN parties.
Administrating a Fediverse server, on the other hand, does equal administrating a LAMP stack on the command line, full stop.
I sincerely hope that the day won't come when someone does with e.g. Mastodon what the Outworldz DreamGrid did with OpenSimulator: turn a full server stack into an "easy-peasy", fully-preconfigured, Windows-only point-and-click application that anyone can install on their Windows machines with absolutely zero prior knowledge about servers or networks, that even automatically connects to a dynamic DNS service that was created specifically for this application so you don't even need to know anything about domains, and that can only be handled through the built-in Windows GUI. (Mind you, there are people who are actually asking for exactly this, only not for Windows, but for their iPhones. Food for thought.)
CC: @silverpill @Contraquestão
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Forte #MovingInstances #NomadicIdentity #Discord #OpenSim #OpenSimulator #DreamGrid -
@Ben Pate 🤘🏻
I've looked through FEP-ef61 in the past, and will give it another go. I think I struggled to see how this would be compatible with Mastodon, or other servers without them requiring a pretty big rewrite to support portable objects.
It won't. Especially not with Mastodon.
At the very least, they would have to start to understand portable objects and the concept of nomadic identity, e.g. that[email protected]and[email protected]may be on two different accounts, but the exact same channel with the exact same identity, the exact same connections, the exact same content etc.
Mastodon has been flipping the bird both at the ActivityPub standard and at FEPs and at the whole rest of the Fediverse since it was made. Eugen Rochko has been trying to EEE the Fediverse since he created Mastodon, the very same thing that people on Mastodon feared that Threads would do. The only time he ever makes compromises is when he is put under pressure by even more powerful players like Automattic or Flipboard, and even then he only throws them tiny bones.
As @Mike Macgirvin ?️ gradually built his nomadic and ActivityPub-based Forte from his own nomadic and Nomad-based streams repository (itself a Hubzilla descendant), and as @silverpill started making his non-nomadic and ActivityPub-based Mitra nomadic, their goal was to expand ActivityPub into something that supports nomadic identity via FEPs and, at the same time, make their own software compatible to these FEPs.
Their goal was not to make their software and these FEPs fully compatible with the Fediverse as it was in 2023/2024 and especially not to build them against Mastodon as it was in 2023/2024 or as it is now.
Especially Mike would never build anything explicitly against Mastodon. Rather, he'd make it possible to block Mastodon from an entire (streams) or Forte server, and he did. To Mike, Mastodon is not the heart and the core and the centre of the Fediverse around everything else orbits and justifiedly so. He rather sees it as a nuisance.
Seriously, nothing that Mike has created will ever be fully compatible with Mastodon, not as long as Mastodon's politics don't change greatly. I mean, client-side support for Mike's own OpenWebAuth magic sign-on was proposed for Mastodon. It went as far as an actual merge request in 2023. They core devs never even looked at that merge request, much less merged it. They silently rejected it.
@Contraquestão
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #NomadicIdentity #FEP_ef61 -
Added Nomadic ActivityPub page to the ap-next repository:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
This is a brief summary of the work we've done. Feedback is welcome!
-
@Strypey Locally writing content to the database of an ActivityPub-based server will inevitably require a local user account on that very server.
I mean, we already have OpenWebAuth magic sign-on which was invented by @Mike Macgirvin ?️ for Hubzilla in 2017, and which also has full implementations in his later server applications (streams) and Forte and a client-side implementation on Mike's first project, Friendica. But without an actual account on another server, OpenWebAuth can only authenticate you on that other server as a guest and grant you certain guest permissions. It does not give you all the powers of a local user, at least not without a local account.
Also, if you want to actually log in on another server, you will inevitably need local login credentials on that server. Which means that a user account with these login credentials must be created prior to you logging in on that server so that that server knows your login name and your password. Even if you want to use something like OAuth, that server will still require to know your credentials. They will have to be in that server's database before you can successfully log in.
A server cannot and will not authenticate you against credentials in a wholly different remote server's database. What you and many other Fediverse users dream of can only be solved in two ways and both only theoretically because, in practice, they are just as impossible or at least very unfeasible.
Either if you register an account on one Fediverse server, that account with the exact same credentials is simultaneously created on literally all other Fediverse servers, and on Hubzilla, (streams) and Forte, you also automatically get a channel along with that account. This also means that each Fediverse server that's installed and spun up for the first time will immediately have to create tens of millions of accounts so that everyone all over the Fediverse automatically has login credentials on that server. I guess it should be clear that this is impossible, also because this requires a) a centralised list of absolutely all Fediverse accounts and identities and b) a centralised list of all Fediverse servers to be hard-coded into every last instance of every last Fediverse server out there.
Now, I keep reading stuff like, "But I don't want to use all Fediverse servers!" No, but you want to be able to use any Fediverse server. And then you will have to have an account there. How is the Fediverse supposed to know in advance which servers you will visit this year, the next two years, five years, ten years so that accounts can be automatically created for you exactly there and nowhere else?
See? And that's why, if you want to be able to use any server like with a local account, every server must be prepared for it before you arrive.
Or drive-by registration: You visit a Fediverse server for the first time, your active login is recognised by that Fediverse server, and an account is created for you on the fly with the exact same login credentials as where you're already logged in. That's its own can of worms.
Also, it requires remote authentication. OpenWebAuth. As I've already said: This is technology that's eight years old, and that's being daily-driven right now. But: You will never have this on Mastodon. There actually is a pull request for Mastodon from two years ago that would have implemented client-side OpenWebAuth support. It was never merged. It was silently rejected by the Mastodon developers. The PR was closed in November, 2024.
Some people go even further: They don't just want their login credentials wherever they go, they want their whole identity cloned to everywhere. They want all their stuff, all their posts and comments and DMs, all their followers and followed, all their settings, all their filters etc. etc. pp., they want it everywhere all the same. Like a nomadic identity (an invention by Mike from 2011, first implemented in 2012) across up to 30,000 servers.
Now, you and many others on Mastodon are probably going to cry out, "YES, YES, PLEASE MAKE THIS REALITY!"
But seriously: I myself have actually cloned enough Hubzilla and (streams) channels of mine in my time. None of them even had nearly as much content on them as your Mastodon account. And I can tell from a lot of personal experience that this cannot be done within a blink of an eye.
Nomadic identity won't come to Mastodon anyway. Nomadic identity via ActivityPub is probably being daily-driven already. Forte has it, and it relies on it. But Mastodon will never implement it. In particular, Mastodon would rather re-invent the "nomadic identity" wheel in a way that's incompatible with what we already have than implement something made by Mike Macgirvin. Not after all the head-butting that has happened between Mike and Gargron over the years.
And OpenWebAuth won't come to Mastodon either. Probably also for the same reason.
CC: @Tim Chambers @rakoo @Ben Pate 🤘🏻
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity -
@Osma A 🇫🇮🇺🇦 Once silverpill is done converting Mitra, we'll have both a hopefully full set of necessary FEPs and ideally a guide on how to make something non-nomadic nomadic. At least it will have been done once.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NomadicIdentity #Mitra -
@Osma A 🇫🇮🇺🇦
I would argue that had we a good account portability model that solved also post history, there would be no need for a centralized onboarding. Don't like your local community or service provider? Migrate somewhere else. Bluesky does have this slightly better thought out, if not yet practically proven.
What Bluesky has as a vague concept that's far from being implemented can't hold a candle to what Hubzilla has had for 13 years now. 12 years of stable releases. What it has passed on to a whole number of forks and forks of forks, all by the same creator, of which the streams repository of 2021 and Forte of 2024 still exist. As of Forte, it works entirely via ActivityPub without requiring its own protocol, and it should theoretically even work between servers of different types (if there was anything else with an ActivityPub nomadic identity implementation to clone and move from and to).
We have an account portability model (only not for accounts as in logins; see below). We have it in spades. We have it beyond everyone's wildest imagination. And it has been daily-driven by Fediverse users for much longer than most of you have been on Mastodon.
The real issues are: It relies on separating your identity (posts, comments, DMs, settings, connections, files, filters etc. etc.) from your login/account, but just about everywhere that isn't Hubzilla, (streams) or Forte, they're firmly welded together, and separating them is next to unthinkable. And even if that wasn't an issue, Mastodon would still never adopt it, and be it because Eugen Rochko refuses to accept anything that's Mike Macgirvin's brain-child.
CC: @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@craignicol Redundancy. Resilience against losing the server that you're on by being on another server simultaneously.
Also, just because you can spread your identity across multiple servers and even server types, doesn't mean you can only have one identity.
Look at me, for example:- I have @Jupiter Rowland on the Hubzilla hubs hub.netzgemeinde.eu and hub.hubzilla.de.
- I have my "in-world sister's" channel @Juno Rowland on the same two Hubzilla hubs. It's still a separate and fully independent identity, and I could clone either of them to other Hubzilla hubs independently from one another. Like, I could clone @Jupiter Rowland to hub.hubzilla.hu and @Juno Rowland to klacker.org or whatever.
- I have my in-world image-posting channel @Jupiter Rowland's (streams) outlet on the (streams) servers streams.elsmussols.net and nomad.fedi-verse.hu.
- I have my Fediverse meme channel @Jupiter's Fedi-Memes on (streams) on the (streams) server streams.elsmussols.net; I haven't cloned it yet.
- In addition, I also have my non-nomadic WriteFreely blog @Aus Hypergrid und Umgebung and my non-nomadic Lemmy account @Jupiter Rowland.
That's six fully separate, fully independent Fediverse identities, even though Mastodon and most of the rest of the Fediverse (anything that doesn't understand nomadic identity) perceive them as nine identities. And as you can see, what you may have taken for utter science-fiction two minutes ago is being daily driven in the Fediverse right now. And it has been for well over a decade, for longer than Mastodon has been around.
Why have I cloned my identities? For the very reason that nomadic identity was invented in the first place: redundancy. Safety. Always having a live backup. Resilience against servers shutting down or malfunctioning. It was invented because its inventor, the creator and then-still-maintainer of Friendica, kept seeing Friendica users lose everything whenever a Friendica node disappeared. And he understood that the only way to really make an identity resilient against server shutdown is for it to reside on at least two servers simultaneously.
If glasgow.social goes belly-up unexpectedly, you lose everything. Potentially forever. Good luck starting over from scratch.
If hub.netzgemeinde.eu goes belly-up, I lose nothing because I still have the identical clones, live, hot, bidirectional backups, on hub.hubzilla.de.
Tell you what: A while ago, hub.netzgemeinde.eu did go belly-up. The queue worker was so overloaded that the hub was bogged down. Nothing went in, nothing went out. Without a clone, I would have been fscked.
Luckily, I had my clone. I logged into hub.hubzilla.de and used my clone to a) do what I'd normally do on hub.netzgemeinde.eu and, especially, b) alert the admin who was on vacation. He and the Hubzilla lead developer ssh'd onto the server and fixed the issue. This might never have happened, hadn't I had that clone on another server.
So you could:- make a Crohn-related identity and clone it or not
- make a Doctor Who fandom identity and clone it or not
- make an activist identity and clone it or not
- make a Web development-related identity and clone it or not
Oh, by the way: The aforementioned six identites may or may not be all of my Fediverse identities. I may or may not have more than these. You wouldn't be able to tell unless I told you.
CC: @Johannes Ernst @Tim Chambers @Ben Pate 🤘🏻
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #NomadicIdentity -
@Marcus Rohrmoser 🌻 Not to my knowledge.
First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.
See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.
As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.
Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.
Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.
Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.
There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.
In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.
So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until- the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
- silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised
Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.
Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.
The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.
Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.
Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:- Situation:
- You have an account on digitalcourage.social with one channel,
[email protected]. - You want to move to troet.cafe.
- You have an account on digitalcourage.social with one channel,
- Step 1: You create an account on troet.cafe.
- Step 2: There can't be accounts with no channels. You have to add a channel.
So you choose to move your channel[email protected]from digitalcourage.social to troet.cafe. - Step 3: Your channel
[email protected]is cloned over to troet.cafe. - Situation now:
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
[email protected]. - You have an account on troet.cafe with a clone of your channel; its identity is still
[email protected].
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
- Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
- Now the main instance and the clone are identical.
Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving. - Step 5:
- The clone on troet.cafe is promoted to main instance.
- As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
- Situation now:
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
[email protected]. - You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is
[email protected].
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
- Step 6: All your connections on servers of nomadic software are changed from
[email protected]to[email protected], both locally on the servers that you are on and locally on the servers that they are on. - Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from
[email protected]which, to them, is an all-new, independent identity. - The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
- Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
- Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
-
@Marcus Rohrmoser 🌻 Not to my knowledge.
First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.
See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.
As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.
Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.
Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.
Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.
There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.
In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.
So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until- the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
- silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised
Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.
Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.
The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.
Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.
Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:- Situation:
- You have an account on digitalcourage.social with one channel,
[email protected]. - You want to move to troet.cafe.
- You have an account on digitalcourage.social with one channel,
- Step 1: You create an account on troet.cafe.
- Step 2: There can't be accounts with no channels. You have to add a channel.
So you choose to move your channel[email protected]from digitalcourage.social to troet.cafe. - Step 3: Your channel
[email protected]is cloned over to troet.cafe. - Situation now:
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
[email protected]. - You have an account on troet.cafe with a clone of your channel; its identity is still
[email protected].
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
- Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
- Now the main instance and the clone are identical.
Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving. - Step 5:
- The clone on troet.cafe is promoted to main instance.
- As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
- Situation now:
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
[email protected]. - You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is
[email protected].
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
- Step 6: All your connections on servers of nomadic software are changed from
[email protected]to[email protected], both locally on the servers that you are on and locally on the servers that they are on. - Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from
[email protected]which, to them, is an all-new, independent identity. - The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
- Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
- Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
-
@Marcus Rohrmoser 🌻 Not to my knowledge.
First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.
See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.
As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.
Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.
Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.
Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.
There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.
In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.
So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until- the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
- silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised
Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.
Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.
The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.
Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.
Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:- Situation:
- You have an account on digitalcourage.social with one channel,
[email protected]. - You want to move to troet.cafe.
- You have an account on digitalcourage.social with one channel,
- Step 1: You create an account on troet.cafe.
- Step 2: There can't be accounts with no channels. You have to add a channel.
So you choose to move your channel[email protected]from digitalcourage.social to troet.cafe. - Step 3: Your channel
[email protected]is cloned over to troet.cafe. - Situation now:
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
[email protected]. - You have an account on troet.cafe with a clone of your channel; its identity is still
[email protected].
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
- Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
- Now the main instance and the clone are identical.
Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving. - Step 5:
- The clone on troet.cafe is promoted to main instance.
- As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
- Situation now:
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
[email protected]. - You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is
[email protected].
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
- Step 6: All your connections on servers of nomadic software are changed from
[email protected]to[email protected], both locally on the servers that you are on and locally on the servers that they are on. - Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from
[email protected]which, to them, is an all-new, independent identity. - The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
- Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
- Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
-
@Marcus Rohrmoser 🌻 Not to my knowledge.
First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.
See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.
As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.
Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.
Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.
Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.
There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.
In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.
So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until- the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
- silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised
Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.
Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.
The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.
Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.
Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:- Situation:
- You have an account on digitalcourage.social with one channel,
[email protected]. - You want to move to troet.cafe.
- You have an account on digitalcourage.social with one channel,
- Step 1: You create an account on troet.cafe.
- Step 2: There can't be accounts with no channels. You have to add a channel.
So you choose to move your channel[email protected]from digitalcourage.social to troet.cafe. - Step 3: Your channel
[email protected]is cloned over to troet.cafe. - Situation now:
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
[email protected]. - You have an account on troet.cafe with a clone of your channel; its identity is still
[email protected].
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
- Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
- Now the main instance and the clone are identical.
Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving. - Step 5:
- The clone on troet.cafe is promoted to main instance.
- As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
- Situation now:
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
[email protected]. - You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is
[email protected].
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
- Step 6: All your connections on servers of nomadic software are changed from
[email protected]to[email protected], both locally on the servers that you are on and locally on the servers that they are on. - Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from
[email protected]which, to them, is an all-new, independent identity. - The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
- Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
- Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
-
@Marcus Rohrmoser 🌻 Not to my knowledge.
First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.
See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.
As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.
Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.
Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.
Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.
There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.
In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.
So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until- the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
- silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised
Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.
Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.
The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.
Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.
Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:- Situation:
- You have an account on digitalcourage.social with one channel,
[email protected]. - You want to move to troet.cafe.
- You have an account on digitalcourage.social with one channel,
- Step 1: You create an account on troet.cafe.
- Step 2: There can't be accounts with no channels. You have to add a channel.
So you choose to move your channel[email protected]from digitalcourage.social to troet.cafe. - Step 3: Your channel
[email protected]is cloned over to troet.cafe. - Situation now:
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
[email protected]. - You have an account on troet.cafe with a clone of your channel; its identity is still
[email protected].
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
- Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
- Now the main instance and the clone are identical.
Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving. - Step 5:
- The clone on troet.cafe is promoted to main instance.
- As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
- Situation now:
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
[email protected]. - You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is
[email protected].
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
- Step 6: All your connections on servers of nomadic software are changed from
[email protected]to[email protected], both locally on the servers that you are on and locally on the servers that they are on. - Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from
[email protected]which, to them, is an all-new, independent identity. - The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
- Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
- Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
-
@Ben Pate 🤘🏻 Let's just say the only devs who need full identity portability are silverpill and you, and silverpill is actively working on it.
Then there are Mike, Mario Vavti and Harald Eilertsen who have full identity portability.
All the other devs don't seem to care.
As for the users, however... I guess if Mastodon 4.5 went fully nomadic on Forte's scale, people would kiss Gargron's feet because he'd deliver what they've been craving for for so long. For not exactly few of them, this would be what they've been wishing for for years plus cream and a cherry on top.
And if all the various *keys (at least those that are still maintained) went nomadic on a cross-server-type scale, that'd solve the problem with entire Forkeys going belly-up and leaving its users standing in the rain with unmaintained server software. I mean, I guess we all know how volatile Forkeys tend to be. Not only could people move around from server to server with ease and take everything with them, but they could also try out new Forkeys (this explicitly includes Iceshrimp.NET) and still have clones on longer-lived applications like Sharkey, CherryPick or good old Misskey itself as fallbacks.
In fact, I think one reason for Sharkey's popularity is its import/export capability.
CC: @Marcus Rohrmoser 🌻 @Johannes Ernst @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick #Sharkey #Iceshrimp #Iceshrimp.NET #NomadicIdentity -
@Ben Pate 🤘🏻 Let's just say the only devs who need full identity portability are silverpill and you, and silverpill is actively working on it.
Then there are Mike, Mario Vavti and Harald Eilertsen who have full identity portability.
All the other devs don't seem to care.
As for the users, however... I guess if Mastodon 4.5 went fully nomadic on Forte's scale, people would kiss Gargron's feet because he'd deliver what they've been craving for for so long. For not exactly few of them, this would be what they've been wishing for for years plus cream and a cherry on top.
And if all the various *keys (at least those that are still maintained) went nomadic on a cross-server-type scale, that'd solve the problem with entire Forkeys going belly-up and leaving its users standing in the rain with unmaintained server software. I mean, I guess we all know how volatile Forkeys tend to be. Not only could people move around from server to server with ease and take everything with them, but they could also try out new Forkeys (this explicitly includes Iceshrimp.NET) and still have clones on longer-lived applications like Sharkey, CherryPick or good old Misskey itself as fallbacks.
In fact, I think one reason for Sharkey's popularity is its import/export capability.
CC: @Marcus Rohrmoser 🌻 @Johannes Ernst @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick #Sharkey #Iceshrimp #Iceshrimp.NET #NomadicIdentity -
@Ben Pate 🤘🏻 Let's just say the only devs who need full identity portability are silverpill and you, and silverpill is actively working on it.
Then there are Mike, Mario Vavti and Harald Eilertsen who have full identity portability.
All the other devs don't seem to care.
As for the users, however... I guess if Mastodon 4.5 went fully nomadic on Forte's scale, people would kiss Gargron's feet because he'd deliver what they've been craving for for so long. For not exactly few of them, this would be what they've been wishing for for years plus cream and a cherry on top.
And if all the various *keys (at least those that are still maintained) went nomadic on a cross-server-type scale, that'd solve the problem with entire Forkeys going belly-up and leaving its users standing in the rain with unmaintained server software. I mean, I guess we all know how volatile Forkeys tend to be. Not only could people move around from server to server with ease and take everything with them, but they could also try out new Forkeys (this explicitly includes Iceshrimp.NET) and still have clones on longer-lived applications like Sharkey, CherryPick or good old Misskey itself as fallbacks.
In fact, I think one reason for Sharkey's popularity is its import/export capability.
CC: @Marcus Rohrmoser 🌻 @Johannes Ernst @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick #Sharkey #Iceshrimp #Iceshrimp.NET #NomadicIdentity -
@Ben Pate 🤘🏻
2) None of the solutions feel very approachable. Documentation is thin, and examples are hard to find. Beyond the text of FEP-ef61, where should I go if I want to start building support into my own apps?
There isn't much documentation because everything is still very new and also due to the nature of what has already been made with nomadic identity via ActivityPub on which base and which level of stability.
Yes, there's Forte. Yes, it uses ActivityPub for nomadic identity. Yes, it has a stable release.
But: It has never been an ActivityPub project that went nomadic.
It evolved from the Red Matrix (2012)- based on Zot
- channel system; identity independent of account/login
- nomadic
- some non-nomadic protocols available optionally, off by default
- based on Zot, evolved to Zot6
- channel system; identity independent of account/login
- nomadic
- some non-nomadic protocols available optionally, off by default
- ActivityPub added long after the fact, again, optional and off by default
- based on Zot6, Zot8 or (would be Zot11, but it's incompatible with Zot6, so it's renamed) Nomad
- channel system; identity independent of account/login
- nomadic
- fewer non-nomadic protocols available optionally, off by default, if any
- ActivityPub added into the core eventually
- based on Nomad
- channel system; identity independent of account/login
- nomadic
- ActivityPub in the core as a secondary protocol, optional, on by default
- all other non-nomadic protocols removed
- based on ActivityPub, supports nothing else
- channel system; identity independent of account/login
- nomadic
So Forte looks back at 13 years of multiple identities per account and nomadic identity. When Hubzilla became the first Fediverse server application to adopt ActivityPub in 2017, the family had already had nomadic identity for over four years.
Implementing nomadic identity via ActivityPub meant switching the whole thing away from a protocol that was built around nomadic identity and over to ActivityPub while keeping nomadic identity.
What you seem interested in is what @silverpill is working on on Mitra. And that's to take a non-nomadic, ActivityPub-only, account-equals-identity server application and make it nomadic.
AFAIK, this is still highly experimental. It's done in a development branch of Mitra. I know that Mitra understands Forte's nomadic identity, but I can't even say whether that dev branch of Mitra is actually nomadic, as in whether you can clone an identity on one server running the dev branch to another such server and have them sync back and forth.
If anything, this would be what ActivityPub devs looking at nomadic identity should check out. "Would" because it's still in such an early and experimental state that I think there isn't anything worth looking at yet other than how to make your software recognise Forte's nomadic channels as nomadic.
By the way, silverpill is publishing FEP after FEP in which Forte or Mitra, (streams) and Forte are mentioned as implementations at most. So he doesn't just code stuff together, he also tries hard to make it "official" by casting it into FEPs. So I guess he's still figuring out the basics and documenting them rather than getting actual nomadicity to work out of thin air.
You've basically got two options if you want to turn non-nomadic, ActivityPub-only, account-equals-identity software into something that's every bit as nomadic as Hubzilla, (streams) or Forte.
Either you wait until silverpill rolls out the first stable release of Mitra with full-blown nomadic identity of its own. And then there should be quite some documentation on how it was done.
Or you make an experimental nomadic branch of Bandwagon and join silverpill and @Mike Macgirvin ?️ in getting nomadic identity via ActivityPub going.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.
The Sin of Overwhelming Complexity: Instance Selection Paralysis
The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.
In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.
In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.
Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.
Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.
Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.The Sin of Inconsistent Navigation: Timeline Turmoil
The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.
First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.
Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.
However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.
Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.The Sin of Remote Interaction Purgatory: Federation Gymnastics
Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.
But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.
You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.
Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.
So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.
Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.
Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).
Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.
Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.The Sin of DM Disasters Waiting to Happen
I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).
On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.
If I want to DM you, I can either tag you@!{[email protected]}rather than@[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.
Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.
Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.
If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).
Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.
Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.The Sin of Ghost Conversations and Phantom Follower Counts
And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.
Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.
This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.
Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.
Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.
Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.
So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.
The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.The Sin of Invisible Discovery: The Content Mirage
I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.
But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.
Also:- Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
- Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
- (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.
Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.
Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.
(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.
As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.The Sin of User Discovery Hell
Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.
Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.
The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.
Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.
Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?
Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.
Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.
Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.
(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.
These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").
Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.
This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.
(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.
If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.
A global directory of everything sounds like a good idea, but it's next to impossible to implement.
Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?
Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.
For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.
Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.
Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.
But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.
Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.
Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?
CC: @Risotto Bias
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers -
@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.
The Sin of Overwhelming Complexity: Instance Selection Paralysis
The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.
In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.
In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.
Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.
Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.
Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.The Sin of Inconsistent Navigation: Timeline Turmoil
The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.
First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.
Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.
However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.
Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.The Sin of Remote Interaction Purgatory: Federation Gymnastics
Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.
But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.
You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.
Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.
So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.
Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.
Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).
Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.
Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.The Sin of DM Disasters Waiting to Happen
I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).
On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.
If I want to DM you, I can either tag you@!{[email protected]}rather than@[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.
Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.
Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.
If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).
Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.
Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.The Sin of Ghost Conversations and Phantom Follower Counts
And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.
Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.
This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.
Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.
Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.
Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.
So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.
The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.The Sin of Invisible Discovery: The Content Mirage
I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.
But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.
Also:- Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
- Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
- (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.
Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.
Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.
(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.
As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.The Sin of User Discovery Hell
Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.
Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.
The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.
Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.
Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?
Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.
Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.
Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.
(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.
These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").
Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.
This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.
(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.
If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.
A global directory of everything sounds like a good idea, but it's next to impossible to implement.
Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?
Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.
For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.
Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.
Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.
But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.
Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.
Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?
CC: @Risotto Bias
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers -
@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.
The Sin of Overwhelming Complexity: Instance Selection Paralysis
The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.
In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.
In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.
Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.
Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.
Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.The Sin of Inconsistent Navigation: Timeline Turmoil
The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.
First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.
Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.
However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.
Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.The Sin of Remote Interaction Purgatory: Federation Gymnastics
Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.
But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.
You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.
Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.
So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.
Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.
Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).
Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.
Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.The Sin of DM Disasters Waiting to Happen
I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).
On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.
If I want to DM you, I can either tag you@!{[email protected]}rather than@[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.
Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.
Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.
If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).
Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.
Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.The Sin of Ghost Conversations and Phantom Follower Counts
And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.
Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.
This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.
Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.
Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.
Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.
So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.
The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.The Sin of Invisible Discovery: The Content Mirage
I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.
But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.
Also:- Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
- Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
- (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.
Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.
Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.
(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.
As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.The Sin of User Discovery Hell
Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.
Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.
The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.
Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.
Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?
Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.
Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.
Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.
(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.
These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").
Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.
This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.
(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.
If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.
A global directory of everything sounds like a good idea, but it's next to impossible to implement.
Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?
Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.
For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.
Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.
Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.
But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.
Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.
Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?
CC: @Risotto Bias
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers -
@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.
The Sin of Overwhelming Complexity: Instance Selection Paralysis
The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.
In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.
In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.
Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.
Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.
Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.The Sin of Inconsistent Navigation: Timeline Turmoil
The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.
First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.
Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.
However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.
Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.The Sin of Remote Interaction Purgatory: Federation Gymnastics
Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.
But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.
You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.
Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.
So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.
Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.
Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).
Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.
Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.The Sin of DM Disasters Waiting to Happen
I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).
On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.
If I want to DM you, I can either tag you@!{[email protected]}rather than@[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.
Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.
Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.
If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).
Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.
Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.The Sin of Ghost Conversations and Phantom Follower Counts
And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.
Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.
This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.
Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.
Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.
Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.
So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.
The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.The Sin of Invisible Discovery: The Content Mirage
I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.
But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.
Also:- Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
- Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
- (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.
Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.
Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.
(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.
As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.The Sin of User Discovery Hell
Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.
Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.
The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.
Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.
Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?
Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.
Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.
Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.
(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.
These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").
Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.
This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.
(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.
If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.
A global directory of everything sounds like a good idea, but it's next to impossible to implement.
Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?
Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.
For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.
Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.
Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.
But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.
Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.
Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?
CC: @Risotto Bias
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers -
@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.
The Sin of Overwhelming Complexity: Instance Selection Paralysis
The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.
In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.
In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.
Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.
Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.
Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.The Sin of Inconsistent Navigation: Timeline Turmoil
The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.
First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.
Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.
However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.
Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.The Sin of Remote Interaction Purgatory: Federation Gymnastics
Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.
But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.
You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.
Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.
So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.
Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.
Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).
Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.
Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.The Sin of DM Disasters Waiting to Happen
I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).
On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.
If I want to DM you, I can either tag you@!{[email protected]}rather than@[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.
Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.
Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.
If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).
Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.
Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.The Sin of Ghost Conversations and Phantom Follower Counts
And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.
Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.
This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.
Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.
Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.
Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.
So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.
The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.The Sin of Invisible Discovery: The Content Mirage
I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.
But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.
Also:- Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
- Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
- (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.
Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.
Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.
(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.
As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.The Sin of User Discovery Hell
Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.
Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.
The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.
Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.
Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?
Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.
Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.
Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.
(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.
These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").
Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.
This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.
(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.
If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.
A global directory of everything sounds like a good idea, but it's next to impossible to implement.
Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?
Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.
For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.
Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.
Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.
But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.
Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.
Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?
CC: @Risotto Bias
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers -
@RockManJoe Hahaha.
Tell you what: @Mike Macgirvin ?️ has decentralised Fediverse identities as early as 2011. He invented nomadic identity (https://joinfediverse.wiki/Nomadic_identity, https://opennomad.net/page/nomad/home) almost five years before Mastodon was made. And he first implemented it in 2012 on what would later become Hubzilla (https://hubzilla.org, https://joinfediverse.wiki/Hubzilla). That was still almost four years before Mastodon was launched.
Oh, and by the way: Hubzilla is very much part of the Fediverse. It is very much (albeit optionally) connected to and federated with Mastodon. I am replying to you right now from a Hubzilla channel which simultaneously and identically resides on two independent servers.
Nomadic identity is reality now. It is being daily-driven right now, and it has been daily-driven since long before Solid was even announced.
Solid is nothing but Hubzilla or (streams) or Forte (both are descendants of Hubzilla by Hubzilla's creator) as ordered from wish.com. A cheap and shoddy knock-off.
CC: @Johannes Ernst @Tim Chambers @Ben Pate 🤘🏻
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Johannes Ernst The first step is already done:
Forte, @Mike Macgirvin ?️ most recent project from the same family that started with Friendica 15 years ago, is the first and only stable Fediverse server application that uses ActivityPub for nomadic identity. Nomadic identity itself is a concept created by Mike in 2011 and first implemented by himself in 2012 in a very early version of Hubzilla which he called Red back then.
This means that you can have the exact same channel/identity (think Mastodon account, but without its own login) on multiple server instances with one account each. If one server goes down, you still have at least one clone (depending on how many clones you make).
@silverpill is working on implementing this on Mitra. It's still only available in development versions, though. The difference is that Mike had already created a whole bunch of Fediverse server applications with nomadic identity since 2012; he "only" had to port nomadic identity from the Zot or Nomad protocol to ActivityPub. Silverpill, on the other hand, has to implement nomadic identity in something that was built upon ActivityPub with no nomadic identity.
Both recognise each other's nomadic identities. (For comparison: Mastodon doesn't recognise any nomadic identities. It takes the two instances of this Hubzilla channel of mine for two fully separate identities.) But that's all for now.
The next step, and that's way into the future, would be to be able to clone from Forte to Mitra or from Mitra to Forte. This would give you one identity on at least two server instances of two separate Fediverse server applications.
The obvious downside is that you won't be able to take everything with you everywhere when you clone to other server types. For example, if you clone a Forte channel to Mitra, you won't be able to take your permissions settings, your permission roles, your friend zoom settings, the contents of your cloud storage, your CalDAV calendars and your CardDAV addressbook with you over to Mitra. That's simply because Mitra doesn't have any of these features.
What you envision is another step further. And that's the adoption of nomadic identity via ActivityPub and ideally also OpenWebAuth magic single sign-on, another one of Mike's creations, by all Fediverse server applications. And I mean all of them. Including extremely minimalist stuff like snac2 or GoToSocial. Including stuff that isn't actively being worked on like Plume. Including stuff that's dead, but that still has running servers, like Calckey, Firefish or /kbin. And including Mastodon which stubbornly refuses to make itself more compatible with the "competition" in the Fediverse and adopt technologies created by anyone else in the Fediverse, even more so if that someone is Mike Macgirvin.
In other words, this won't happen. Mastodon would rather turn itself into its own federated walled garden by becoming incompatible with all other ActivityPub implementations.
What many Mastodon users who know nothing about decentralisation wish for is another step further. And that's to create one account on one server instance of one Fediverse server software, no matter which, and then to have full-blown user permissions on any instance of any Fediverse server software.
Like, create one account on mastodon.social, go to a Pixelfed instance, post pictures Instagram-style, go to a PeerTube instance, upload videos, go to a WriteFreely instance, blog away, go to a Hubzilla hub, build a webpage, all with only your mastodon.social login.
Of course, this is impossible to do. This would mean that if you create an account on one Fediverse server instance, it would have to be cloned to all 30,000+ servers in the whole Fediverse instantaneously. And if you start your own instance, it would have to trigger 30,000+ servers to clone their tens of millions of accounts and channels over to your instance.
Usually, when I explain this to people who want to use everything with one login, they tell me that they don't want to use every server in the Fediverse. No, but they want to use any server in the Fediverse. Any one of the 30,000+.
And they want to use it immediately. Like, go there, use it with full-blown local user permissions right away, no delay.
Now you may argue that their account or channel could be cloned to that server when they visit it for the first time. Drive-by cloning, so-to-speak. Still, won't happen. Cloning takes time. I myself have cloned enough Hubzilla and (streams) channels over the years to be able to estimate just how long it takes. And none of my channels has ever contained tens of thousands of posts and thousands of pictures.
Besides, drive-by cloning would inflate Fediverse instances senselessly, not to mention bog them down with extra network traffic. Whenever you visit a Fediverse server instance for whichever reason (like, you want to look at a post on Friendica or Hubzilla to see what it looks like without being botched by Mastodon), your account or channel would automagically be cloned to that server instance. Another account (and channel, if necessary) on that server instance, another deluge of posts and files flooding into the database, and that clone would have to be synced with your 600 other previous drive-by clones on the 600 Fediverse server instances you've visited before.
Extra nefarious: Some "websites" that have to do with Hubzilla or a certain aspect of Hubzilla are parts of Hubzilla channels themselves. This includes the official Hubzilla website. If you visited them, you'd create a drive-by clone on the Hubzilla hub which hosts that website.
So if someone set up a single-user Hubzilla hub with their personal channel and a website channel on it, and the website is interesting enough, and 10,000 Fediverse users visit it, it'll end up bigger than the biggest current Hubzilla hub within days. It'll have 10,001 accounts, namely the owner's account with two channels and 10,000 accounts with drive-by clones, automatically created by the 10,000 external visitors.
But this will remain utopic not only because it's technologically pretty much impossible and very much not feasible at all. It also requires a mechanism for one Fediverse server to recognise logins on other Fediverse servers. You know, like OpenWebAuth. You want your Mastodon account to drive-by clone itself, Mastodon will have to implement OpenWebAuth, and I mean fully implement it.
There actually is a pull request in Mastodon's GitHub code repository that would have implemented client-side OpenWebAuth support (= Hubzilla, (streams) and Forte would recognise Mastodon logins). This isn't even about full-support that'd include login recognition on Mastodon's own side. This pull request has been there for two years. It was never merged. And it probably will never be merged.
This means that the Mastodon devs have practically rejected OpenWebAuth as a feature to implement. Won't come. Ever. Not even half of it.
And this should say everything about the chances that Mastodon will ever implement nomadic identity.
CC: @william.maggos @Richard MacManus @Tim Chambers @Ben Pate 🤘🏻
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity -
@Fabrice Desré @TuxPhones :linux: Ackchually...
The AT protocol has yet to prove that its concept of portable identity works.
In the meantime, @silverpill (creator and maintainer of Mitra) has been working with @Mike Macgirvin 🖥️ (creator of a family tree of almost a dozen Fediverse server applications over a decade and a half, designer of two Fediverse protocols and inventor of nomadic identity as early as 2012) to implement nomadic identity in ActivityPub since 2023. Previously, nomadic identity required the Zot or Nomad protocol. (Oh, and yes, it actually works, and it's being daily-driven by many Hubzilla and (streams) users right now.)
In August, 2024, Mike launched Forte, his most recent creation and the first Fediverse server application to entirely rely upon ActivityPub for nomadic identity. Nomadic identity via ActivityPub has been reality ever since.
In March, 2025, Forte officially had its first stable release. So much about nomadic identity via ActivityPub being experimental. People are using it as their primary daily driver already.
Just because Mastodon doesn't have it, doesn't mean ActivityPub doesn't, or the Fediverse doesn't.
Unfortunately, I don't expect Mastodon to ever implement it. After all, the Mastodon devs have already practically rejected OpenWebAuth as well, another one of Mike's creations.
(This comment was brought to you by a nomadic Hubzilla channel with one clone.)
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Nomad #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity