#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 -
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 -
@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 -
@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.
-
@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 -
@Hrefna (DHC)If your server disappeared tomorrow with no ability to export your follower graph, how would you rebuild it?
If you do a server move, what happens to your post history?
Widespread adoption of Nomadic Identity, if it ever happens, may help with this.
I am sure you already know this, but for other readers, these two 2017 articles explain how Nomadic Identity works in Hubzilla, which is based on the Nomad/Zot protocol.
#^https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b
#^https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b
Mike Macgirvin recently got Nomadic Identity working on ActivityPub too.
#^https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584
Unfortunately, the ActivityPub world keeps pretending that Mike Macgirvin and his work does not exist (Nomadic Identity has been around and working in Hubzilla for roughly a decade).
There's also OpenWebAuth (Federated Single Sign On). As Sean Tilley explains in this March 2024 article, Nomadic Identity and OpenWebAuth together can enable network resilience, censorship resistance, and ease of migration.
#^https://wedistribute.org/2024/03/activitypub-nomadic-identity/
No idea whether Nomadic Identity, OpenWebAuth, conversation containers, etc. will ever get widespread adoption. At present, the user base of software such as Hubzilla, Forte etc. (which have these features) is negligible. And at least in case of Hubzilla (which I am using), the UI and UX needs a lot of work; don't know about Forte (which is based on ActivityPub).
And yes, all the other problems with the Fediverse that you listed will still remain. At this point, I doubt if the Fedi will ever become socially and politically relevant.
#ActivityPub #ATProto #Nomad #Zot #NomadicIdentity #OpenWebAuth #Fediverse -
@Rob Shearer
Excellent write-up, agree with most of the points.
On a related note: it is a pity that the poorly thought-out and designed Mastodon became the overwhelmingly popular Fediverse platform. I wish it were one of the Mike Macgirvin creations such as Hubzilla or (streams) or Forte, with their advanced features such as Nomadic Identity, OpenWebAuth (Federated Single Sign On), conversation containers for threaded conversations, extremely fine-grained privacy controls, etc.
Nomadic Identity, in particular, is brilliant. This is how it works. You have a channel (that participates in the Fediverse, this is equivalent to an account on Mastodon) on any account on, let us say, Hubzilla instance A. You can open another account on Hubzilla instance B, and create a clone there of your channel on instance A. So this clone becomes a live, real-time backup of your channel; the backup includes your connections as well as your posts. And it is bidirectional. You can log on to your clone channel on B, and use it like your main instance, and now the clone on instance A will mirror your activity. If you wish, you can clone the channel on a third instance C. If one of A or B or C abruptly shuts down, you can continue operating your channel from your clone channel, so you lose nothing.
This addresses one of your pain points as to how account migration does not work on Mastodon.
By the way: you can have multiple channels per instance, and you can have clones of each channel on different instances. So if you wish, you can have separate channels for your hobbies and your professional activities and your politics; all contained and operated within a single account on a particular instance.
You can read more about Nomadic Identity here
#^https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b
and here.
#^https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b
It is said that Bluesky is working on pioneering something like Nomadic Identity. Ironically, Mike Macgirvin had already pioneered it all the way back in 2012. He initially did it with Nomad (which underlies Hubzilla and (streams)), a protocol far richer and better-defined than ActivityPub; and recently, he even got Nomadic Identity working on ActivityPub.
#^https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584
Unfortunately, the movers and shakers of the ActivityPub world keep pretending that Mike Macgirvin and his work does not exist.
Then there’s OpenWebAuth for Federated Single Sign On. This enables seamless granting of permissions for you to operate your social dashboard from different parts of the Fediverse.
You can read here how Nomadic Identity and OpenWebAuth together enable network resilience, censorship resistance, and ease of migration.
#^https://wedistribute.org/2024/03/activitypub-nomadic-identity/
There’s also conversation containers—these ensure that unlike on Mastodon, every single post/comment in a conversation thread is visible to every single person participating in or merely viewing the thread. (Also: you don't need @ tagging, anyone who participated in the conversation by replying at least once or by boosting or liking some post is notified of all new posts/comments.)
I won’t elaborate on the fine-grained privacy controls, but I think they too address some of your pain points with Mastodon.
Having said all that, I must mention that your core criticism of Mastodon also applies to Hubzilla, (streams), and Forte: there is asynchronous distribution of “some subset of a global database across some parts of the network”. I personally think there ought to be a truly universal search and community-controlled user-specific custom algorithms to address this problem, but I doubt the vocal part of the userbase here would agree.
And relative to Mastodon, the Hubzilla+(streams)+Forte community is tiny, so there is hardly any local content.
#Nomad #Zot #ActivityPub #Mastodon #Hubzilla #Forte #NomadicIdentity #OpenWebAuth #ConversationContainers #PrivacyControls
@Jeff Atwood -
@Kellam⚙️Бур This may come as a surprise, but: Nomadic identity is not an abstract concept or a science-fiction idea for the Fediverse.
It is reality. It exists. Right now. In stable, daily-driver software that's federated with Mastodon. And it has been for over a decade.
I'm literally replying to you here from a nomadic channel that simultaneously exists on two servers.
Nomadic identity was invented by @Mike Macgirvin 🖥️ (formerly American software developer of about half a century who has been living in rural Australia for decades now) in 2011 and first implemented in 2012. Almost four years before Mastodon was first launched.
In 2010, he had invented the Facebook alternative Friendica, originally named Mistpark and based on his own DFRN protocol.
Over the months, he witnessed lots of privately operated public Friendica nodes shut down with or without an announcement and the users on these nodes lose everything. He added the possibility to export and import Friendica accounts. But that would only help if a permanent shutdown was announced. It did not protect you against shutdowns out of the blue.
There was only one solution to this problem. And that was for someone's identity to not be bound to one server, but to exist on multiple servers simultaneously. The whole thing with everything that's attached to it. Name, settings, connections, posts, files in the file storage etc. etc., everything.
So in 2011, Mike designed a whole new protocol named Zot around this brand-new idea of what he called "nomadic identity" back then already.
In 2012, Mike forked Friendica into something called Red, later the Red Matrix, and rebuilt the whole thing from the ground up against Zot. Red was the first nomadic social networking software in the world, almost four years before Mastodon.
In 2015, ten months before Mastodon was first released, the Red Matrix became Hubzilla, the Fediverse's ultimate Swiss army knife.
I am on Hubzilla myself. This channel of mine is constantly being mirrored between its main instance on https://hub.netzgemeinde.eu and its clone on https://hub.hubzilla.de. Anything that happens on the main instance is backed up on the clone. I can also log into the clone and use that, and whatever happens there is backed up on the main instance.
https://hub.netzgemeinde.eu could go down, temporarily, permanently, doesn't matter; I still have my channel, namely the clone. And I can declare the clone my new main instance.
Well, Mike didn't stop at Hubzilla and its original version of the Zot protocol. He wanted to refine it and advance it, but in ways that wouldn't be possible on daily-driver software.
Zot went through several upgrades: Zot6 in 2018 (backported to Hubzilla in 2020, along with OpenWebAuth magic single sign-on). Zot8 in 2020. Zot11 in 2021 which had become incompatible with Zot6 and therefore was renamed to Nomad. Today's Nomad would be Zot12.
Also, in order to advance and test Zot, Mike created a whole bunch of forks and forks of forks. Osada and Zap for Zot6 in 2018, followed by another short-lived Osada in 2019. A third Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 in 2020 for Zot8. Roadhouse for Zot11 Nomad in 2021. All Osadas, Zap, Misty, Redmatrix 2020 and Roadhouse were discontinued on New Year's Eve of 2022.
The most recent software based on Nomad is from October, 2021. It can be found in the streams repository. It is officially and intentionally nameless and brandless, it has next to nodeinfo code that could submit statistics, and it is intentionally released into the public domain. The community named it (streams) after the code repository.
I also have two (streams) channels, one of which is cloned so far.
The newest thing, and that's what the Friendica and Hubzilla veteran @Tim Schlotfeldt ⚓?️? referred to, is nomadic identity using nothing but ActivityPub, no longer relying on a special protocol.
This was not Mike Macgirvin's idea. This came from @silverpill, the creator and developer of the microblogging server application Mitra. He wanted to make Mitra nomadic, make it resilient against server shutdown. But he didn't want to port it to Nomad. He wanted to achieve it with nothing but ActivityPub.
So he hit up Mike. The two came to the conclusion: This is actually possible. And they began to work on it. Amongst the results were several FEPs coined by silverpill.
This time, Mike did not create another fork to develop nomadic identity via ActivityPub. He did it all on the nomadic branch of the streams repository while silverpill did his part on a special development branch of Mitra.
In mid-2024, after enough sparring between (streams) instances, between Mitra instances and between (streams) and Mitra, Mike was confident enough that his implementation of support of nomadic identity via ActivityPub was stable enough. He merged the nomadic branch into the dev branch which ended up being merged into the stable release branch in summer.
Now, at this point, (streams) didn't use ActivityPub for nomadic identity. It still used the Nomad protocol for everything first and foremost, including cloning. But it understood nomadic identity via ActivityPub as implemented on experimental Mitra.
However, while it worked under lab conditions, it blew up under real-life conditions. At this point, (streams) had to handle so many different identities that it confused them, and it couldn't federate with anything yet.
In mid-August, while trying to fix the problem, Mike eventually forked the streams repository into Forte. It got a name again, it got a brand identity again, it got its nodeinfo back, it was put under the MIT license again.
But most importantly: Any and all support for Nomad was ripped out, also to get rid of a whole number of IDs, namely those for Nomad-actually-Zot12 and for Hubzilla's Nomad-actually-Zot6. Forte only uses ActivityPub for everything. And so, Forte also had to fully rely on ActivityPub for nomadic identity, cloning and syncing.
For almost seven months, Forte was considered experimental and unstable. For most of the time, the only existing servers were Mike's.
But on March 12th, 2025, Mike Macgirvin released Forte 25.3.12, the first official stable release of Forte. This is what Tim wrote about. Because this actually made it into Fediverse-wide news.
Not because it's nomadic. Nomadic identity has been daily-driven for over a decade now.
But because it uses ActivityPub for nomadic identity. Which means that you can theoretically make any kinds of Fediverse software nomadic now, all without porting it to the Nomad protocol first.
For the future, Mike and silverpill envision a Fediverse in which one can clone between different server applications. A Fediverse in which one can have one and the same identity cloned across multiple servers of Mastodon, Pixelfed, PeerTube, Mitra, Forte, Mobilizon, Lemmy, BookWyrm etc., all with the same name, all with the same content and settings (as far as the software allows; you will certainly not be able to clone your PeerTube videos to Mastodon and Lemmy).
Even if you don't intend to clone, it will make moving instances and even moving from one software to another dramatically easier.
If you're concerned about your privacy, let me tell you this:
Hubzilla's privacy, security and permissions system is unparalleled in the Fediverse. Except for that on (streams) and Forte which is another notch better.
I can define who can see my profile (my default, public profile on Hubzilla where each channel can have multiple profiles).
I can define who can see my stream and my posts when looking at my channel.
I can define who can see my connections (Hubzilla, (streams) and Forte don't distinguish between follower and followed; they aren't Twitter clones).
I can define who can look into my file space (individual permission settings per folder and per file notwithstanding).
I can define who can see my webpages on Hubzilla (if I have any).
I can define who can see my wikis on Hubzilla (no shit, I've got wikis on my Hubzilla channel).
On Hubzilla, I can define individually for any of these whether it's- everyone on the Internet
- everyone with a recognisable Fediverse account
- everyone on Hubzilla (maybe also on (streams); anyone using ActivityPub is definitely excluded here)
- everyone on the same server as myself (AFAIK, only main instances of channels count here, clones don't)
- unapproved (= followers) as well as approved (= mutual) connections
- confirmed connections
- those of my confirmed connections whom I explicitly grant that permission by contact role
- only myself
There's a whole bunch more permissions than these. And they all have seven or eight permission levels (depending on whether the general non-Fediverse public can be given permission).
On (streams) and Forte, I can define whether things are allowed for- everyone on the Internet (where applicable)
- everyone with a recognisable Fediverse account
- all my approved connections
- only me myself plus those whom I explicitly grant that permission in the connection settings
Yes, connection settings. Hubzilla, (streams) and Forte give you various ways of configuring individual connections, much unlike Mastodon. This includes what any individual connection is allowed to do.
Hubzilla uses so-called "contact roles" for that, presets with a whopping 17 permissions to grant or deny for any one individual connection. That is, what the channel generally allows, a contact role can't forbid.
(streams) and Forte still have 15 permissions per contact, but they lack some features which Hubzilla has permissions for. These permissions can be set individually for each connection, or you can define permission roles that cover all 15 permissions to make things easier.
Okay, how about posting in public vs in private? And when I say "private", I mean "private". It's "private messages" on Hubzilla, (streams) and Forte, not "direct messages".
Hubzilla, (streams) and Forte let you post- in public
- only to yourself
- only to your connections ((streams) and Forte only; Hubzilla requires a privacy group with all your connections in it for this)
- to all members of one specific privacy group (Hubzilla)/access list ((streams), Forte); that's like being able to only post to those on one specific list on Mastodon
- to everyone to whom one specific non-default profile is assigned (Hubzilla only)
- to a specific group/forum (I'll get back to that later)
- to a custom one-by-one selection of connections of yours
Now, let's assume I have a privacy group with Alice, Bob and Carol in it. I send a new post to only this privacy group. This means:- Only Alice, Bob and Carol can see the post and the conversation.
- Alice can reply to me, Bob and Carol.
- Bob can reply to me, Alice and Carol.
- Carol can reply to me, Alice and Bob.
- Nobody else can see the post. Not even by searching for it. Not by hashtag either. Not at all.
- Nobody else can see any of the comments.
- Nobody else can comment.
If one of them was on Mastodon, they'd see my post as a DM, by the way, and they could only reply to me. But that's Mastodon's limitation because it understands neither threaded conversations nor permissions.
Or how about reply control? This is something that many Mastodon users have been craving for quite a while now. Hubzilla, (streams) and Forte have them. Right now. And they work. They have since 2012.
Hubzilla optionally lets me disallow comments on either of my posts. Users on Hubzilla, (streams) and Forte won't even be able to comment; they won't have the UI elements to do so. Everyone else is able to comment locally. But that comment will never end up on my channel. It will never officially be added to the conversation. And at least users on Friendica, Hubzilla, (streams) and Forte will never fetch that comment from my channel as part of the conversation, i.e. never at all.
(streams) and Forte can go even further with all available options. They can disallow comments like Hubzilla. But in addition, they can allow only the members of one particular access list to comment, regardless of who can see the post/the conversation. On top of that, comments can be closed at a pre-defined point in the future. And then you even have a channel-wide setting for how long people can comment on your posts.
Oh, and there's even a setting for who is generally permitted to comment on your posts. And you can additionally allow specific connections of yours to comment on your posts.
Lastly, I've already mentioned groups/forums. Like, you know, Web forums or Facebook groups or subreddits or whatever. Like Guppe Groups on a mountain of coke and with moderation and permission control and optionally private.
Hubzilla has them, and it has inherited them from Friendica. (streams) has them. Forte has them. They're basically channels like social networking channels, but with some extra features. This includes that everything that's send to a group/forum as what amounts to a PM is automatically forwarded to all other members.
On Hubzilla, a forum can be gradually made private by denying permission to see certain elements to everyone but its own members (= connections): the profile, the members, what's going on in it. Depending on what you want or do not want people to see.
On (streams) and Forte, you have four types of forums:- public, and members can upload images and other files to the forum channel
- public, but members cannot upload images and other files to the forum channel
- like above, but additionally, posts and comments from new members must be manually approved by the admin(s) until their connections are configured to make them full members
- private, non-members can't see the profile, non-members can't see the connections, non-members can't see what's going on in it, but members can upload images and other files to the forum channel
In addition, on all three, a group/forum channel can choose to hide itself from directories. This is always an extra option that's independent from public/private.
What we have here is the most secure and most private Fediverse software of all.
And, once again, at its core, this is technology from 2012. It pre-dates Mastodon by almost four years.
Finally, if you want to know how Hubzilla and (streams) compare to Mastodon: I have made a number of tables that compare Mastodon, Friendica, Hubzilla and (streams).
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #ActivityPub #Zot #Zot6 #Zot8 #Nomad #NomadicIdentity #Security #FediverseSecurity #Privacy #FediversePrivacy #Permissions -
@doctorambient
But do you really think ActivityPub is the ultimate best solution?
Ask Hubzilla or (streams) users, and they're likely to say it isn't.
Even with FEP-ef61 and other unofficial add-ons, ActivityPub will never handle nomadic identity as gracefully as a protocol like Nomad which has been built around nomadic identity and advanced, fine-grained permission control from the get-go.
The main reason why nomadic identity is being introduced to ActivityPub is so that Fediverse server apps that have always only supported ActivityPub can eventually become nomadic without having to be re-written against a wholly different protocol.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Nomad #Hubzilla #Streams #(streams) #NomadicIdentity -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
@Bryan Redeagle
I found a really cool one called Zot that had cross site authentication, which made privacy settings really interesting and useful. Unfortunately, the developer took down all of the drive and instead created a reference application called (streams), the parenthesis are correct. (streams) has no good info or documentation. You have to read the code to figure it out.
A few corrections. Source: I've been using that stuff since before Mastodon was hot. Oh, and this is going to be long.
First of all, the creator, @Mike Macgirvin 🖥️, not only created the Zot protocol, but also a reference implementation at the same time. As in 2012. The reference implementation was named Red and a fork of his very own Friendica from 2010. Since Red turned out to be a not-so-good name, it was renamed Red Matrix. And as it didn't really take off, it was redesigned and renamed into Hubzilla in 2015. Hubzilla still exists today. I'm using it right now.
Mike kept advancing the Zot protocol further and further with a whole string of forks and forks of forks and so forth. Zot6 matured with Zap around 2019 and brought OpenWebAuth magic single sign-on with itself. Both were backported to Hubzilla, which has been maintained by someone else since 2018, in 2010.
Zot's killer feature is not OpenWebAuth magic single sign-on, though. It's nomadic identity. The very thing it was designed for.
In 2021, Zot11 was reached, but it had advanced so far that it was no longer compatible with Zot6, so it was renamed to Nomad. Today's Nomad would be Zot12.
(streams) is only a semi-official name, given to it by the community, based on the name of the code repository. Officially, the application is not a project, it is intentionally nameless (no, I'm not kidding, this thing has no name), it is intentionally devoid of any traces of a brand identity, it intentionally had almost all nodeinfo code removed, and it was intentionally released into the public domain.
As (streams) is not a branded product, it does not have a website either.
The reason why it doesn't have any documentation is another one: The documentation it had was painfully outdated. It was basically handed on from fork to fork to fork and never touched. Parts of it have remained untouched since before Osada and Zap were forked from Hubzilla, and that was in 2018. Other parts still speak of Red, and that name ceased to exist in 2012. I know because Hubzilla's current documentation is every bit as old.
Hubzilla is right now having its entire documentation re-written from scratch in German and English by a community member.
For (streams), however, the only solution was to rip the whole documentation out because no documentation was deemed better than one that's so outdated it's useless.
It was considered not so bad for as long as how few people a) learned about (streams) and b) figured out how to find an open-registration instance of something that has neither third-party instance lists nor a unified instance identifier actually joined (streams). After all, they all came from Hubzilla, so they could figure out most themselves.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #NomadicIdentity #SingleSignOn #OpenWebAuth -
@Strypey @Laurens Hof I think I have to jump into this conversation here.
> Fediverse platform Streams has added nomadic identity to their platform, based on ActivityPub
To be clear, Streams has always had Nomadic Identity, using their own protocol (Zot/ Zap/ Nomad, whatever it's currently called).
First of all, a little nitpicking: It is not "officially named 'Streams'" like other projects are officially named "Mastodon" or "Friendica" or "Hubzilla".
It's officially and intentionally unnamed. It's intentionally nameless and brandless. Not even its instances have a unified identifier like "mastodon" or "friendica" or "hubzilla". "Streams" is the name of the code repository which was absolutely required to have a name, so Mike only speaks of the repository, and the community speaks of "(streams)" in parentheses.
And yes, it has always had nomadic identity. And it's at the end of a long string of forks, all by Mike himself, that have been supporting nomadic identity since 2012 when Mike forked Friendica into something named Red and ported it from Friendica's DFRN to his new nomadic Zot protocol.
In other words, nomadic identity has been in use for almost four years longer than Mastodon has been around. And the idea itself is from 2011 when Mike discovered one critical shortcoming of decentralised networks, and that's people losing their online identities when the instances they're on shut down.
Red still exists, only that it has been Hubzilla since 2015.
(streams) is based on a protocol named Nomad. Technically speaking, Nomad would be Zot12, but when Zot11 was reached during the development of Roadhouse which (streams) is a fork of, it had become incompatible with Hubzilla's Zot6. So in order not to confuse people, this version was renamed Nomad.What's changed is ...
> Streams is using FEP-ef61
Mike is actually a big contributor to FEP-ef61 because what FEP-ef61 tries to do, he has done before way back in 2011 when he conceived the Zot protocol and in 2012 when he implemented it for the first time.
So thanks to Mike, the wheel doesn't have to be re-invented from scratch by someone who has never heard of the existence of wheels before, much less seen or even used them.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Zot #Zot6 #Nomad #ActivityPub #FEP_fe61 #NomadicIdentity -
@glyn @We Distribute
It's true that Nomadic Identity is largely only implemented by Streams and Hubzilla at this time, which are PHP implementations of the Zot/Nomad protocol. Admittedly, it's a bit hard to find quality documentation on these. Paradoxically, the implementations are quite mature, and have been around for years at this point.
Yes, nomadic identity was created along with the Zot protocol as early as 2011. Zot was first implemented on the Red Matrix which is based on a Friendica fork, which had its 1.0 release in 2013, and which was renamed into Hubzilla and repositioned with a different set of features in 2015. So all this happened before Mastodon was released.
Nomadic identity has been in daily, stable use for over a decade.
Like Friendica's DFRN before, Zot was never meant to be an officially standardised protocol like ActivityPub that other, completely different and independent server applications could use. Zot and Hubzilla have always been firmly tied to one another. Zot is not nearly as vague as ActivityPub. And Zot not only covers nomadic identity, but also Hubzilla's permission system which exceeds even a Mastodon user's wildest imagination by magnitudes.
Over the years, Mike advanced Zot further and further, often requiring new forks to test Zot. In 2018, two different Osadas and Zap became the testbeds for Zot6 which Hubzilla would later be upgraded to, and short-lived Zap even saw stable releases. In 2020, another Osada and two more projects which resurrected the names Mistpark and Redmatrix were the testbeds for Zot8 which was so advanced that it had become impossible or at least unfeasable to upgrade Hubzilla to it.
Roadhouse from early 2021, a fork of the third Osada, Redmatrix 2020 and/or Mistpark 2020 (they had the same code base), was either the last application on Zot8 or the first one on what would have been Zot11, but what was so advanced that it had become incompatible with Zot6. Therefore, it was renamed Nomad. And it became the base protocol for the nameless, brandless server application in the Streams repository which Mike is currently maintaining and constantly advancing. And current Nomad would be Zot12 if it was still Zot.
The reason why nomadic identity has only ever been implemented in PHP is because the only one who has ever built server applications with nomadic identity was Mike Macgirvin who also created the protocols behind them. And being built in PHP, everything that Mike has ever created from 2010's Mistpark to 2021's (streams) can be installed on a run-of-the-mill LAMP stack without having to fumble around with stuff like Ruby on Rails.
If you come from a "Fediverse = ActivityPub" background, all this may seem strange. But it was the only way for nomadic identity, Zot, Nomad and their implementations to advance to such power so quickly. Mike is still the sole keeper and maintainer of Nomad and its only implementation. This means that nobody else can meddle with it, and Nomad and (streams) are perfectly matched to each other. Thus, (streams) is probably the most quickly advancing Fediverse project currently.
That said, it is not a fully closed ecosystem. However, the idea behind developing stuff for Nomad is vastly different from the idea behind developing stuff for ActivityPub.
If you want to make something for ActivityPub, you usually sit down and start from scratch, from completely zero, except for the ActivityPub spec.
If you want to make something for Nomad, the recommended ways involve (streams). See, unlike Mastodon, (streams), just like Hubzilla, is not an enclosed monolith. It's modular. It can be expanded. And, in fact, both come with official add-ons right away. ActivityPub support itself is an add-on. A big difference is that Hubzilla comes with more add-ons whereas (streams) is slimmed down in this regard to make development easier. But it's possible to add third-party add-on repositories to server installations of both.
So if you want to make something for Nomad, you start with (streams). No need to start from scratch.
Either you simply develop add-ons for (streams) and offer them in a third-party repository that can be added to (streams) instances. Or you could soft-fork (streams), its core is in the public domain, add your stuff, slap a name on it and offer it as a new project.
I myself wouldn't recommend a hard fork, though, seeing as how rapidly (streams) is evolving and improving.
Sure, it'd be possible to develop something against Zot6 or Nomad completely from scratch. But if you build against Zot6 to stay compatible with Hubzilla, you're at Mario Vavti's mercy because he is the main dev of Hubzilla and therefore the keeper of Zot6 now, although I guess he doesn't change much about the protocol anymore.
And if you build against Nomad, you're at Mike's mercy, and Mike keeps advancing Nomad constantly and (streams) along with it. Also, if you build against Nomad, you must go multi-protocol because Hubzilla doesn't understand Nomad, so you also have to implement Zot6.
Standardising Nomad and handing it over to a W3C commission so it's no longer in the hands of one individual would be the worst that could possibly happen to it. Such a commission would water it down and remove stuff that they deem unnecessary. And Mike, no longer in control over Nomad, would have to play along and water (streams) down.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #NomadicIdentity -
@Sandro Santilli Mastodon doesn't have it, and Mastodon doesn't really need it.
The channels structure was created to make nomadic identity possible or at least facilitate it.
Basically, a Hubzilla channel is a Friendica account with boatloads of extra stuff on top. All stuffed into a container. And that container resides on an account on one server.
What nomadic identity does is copy that container to another account on another server. A 1:1 identical copy. Even keeping the same identity, using the domain of the original server. Whenever one of them changes, the other one is kept in sync. They stay identical.
So yes, the identity of that container on foo.social is [email protected], and the identity of its clone on bar.social is still [email protected]. At least it is for servers that understand nomadic identity. Mastodon, for example, will see any post sent from the clone on bar.social as coming from [email protected] which to Mastodon is a wholly different actor from [email protected].
Hubzilla still uses the Zot protocol, it must have been around 2020 when it switched to the current and last version to come out, Zot6.
(streams) is based on Nomad. Nomad should actually be Zot12, but it is so much different from Zot that it is no longer directly compatible with Zot, and it got its own name.
(streams) has actually got even better ActivityPub support than Hubzilla. However, while Hubzilla federates with almost everything that moves, just like its predecessor Friendica, (streams) only supports Nomad, Zot6 and ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #CWFediMeta #FediverseMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Zot #Zot6 #Nomad #NomadicIdentity #Channels -
tl;dr: Hubzilla has had at least some of this for over a decade now. And it won't replace any of it with a new standard tailor-made for Mastodon.
@silverpill If you look past projects based on ActivityPub and at projects that have ActivityPub as an additional protocol, some of this already exists.- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.
Exists in the shape of nomadic identity. Invented by @Mike Macgirvin 🖥️ in 2011 with his Zot protocol and first deplayed in 2012 with the Red Matrix, nowadays known as Hubzilla. Also available on (streams), Mike's current project at the end of a string of forks from Hubzilla, now based on the Nomad protocol.
Mike would like to see nomadic identity and other special features of the Zot and Nomad protocols included in the ActivityPub protocol. He has actually submitted a number of proposals for this. They were all rejected. Even though he is a protocol developer first and foremost, and he has both created and worked on more Fediverse protocols than anyone else, so he should be considered competent.
Nomadic identity with ActivityPub won't come unless either Evan Prodromou and the W3C commission cave in and allow Mike's suggestions, or someone re-invents the wheel from scratch in a way that's utterly incompatible to Hubzilla and (streams). And it won't come to Mastodon unless Eugen Rochko can imply that Mastodon has had it first.
And there will never be a nomadic identity standard that meets Mike's requirements as well as Eugen's wishes.- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.
AFAIK, all three of Mike's still existing projects, Friendica from 2010, Hubzilla from 2012/2015 and (streams) from 2021, have it. Optionally, but still. I think Friendica actually advertises military-grade encryption.- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
Friendica, Hubzilla and (streams) have had support for add-ons, including third-party add-ons, plus a number of official add-ons since their respective inceptions. If you want a cross-platform add-on standard, I hope you don't expect these three to throw their own standards over board in favour of the new standard. Otherwise, good luck developing a replacement for Pubcrawl that makes Zot-based Hubzilla compatible with ActivityPub while working on ActivityPub-based Mastodon just the same. Friendica, Hubzilla and (streams) rely on add-ons for all federation beyond their respective base protocols (DFRN, Zot, Nomad).- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.
Friendica, Hubzilla and (streams) have had support for discussion groups/forums since their respective inception. On Friendica, a group is a user account with special settings; on Hubzilla and (streams), it's a channel with special settings. In addition, especially Hubzilla and (streams) have access permission control on a level that most people for whom the Fediverse is only ActivityPub couldn't imagine in their wildest dreams. All three can be used by users from all over the Fediverse already now.
Good luck forcing Friendica to give up its 13-year-old standard that's used by Fediverse News, just to name one, and Hubzilla to give up its 11-year-old standard that blows everything else but what (streams) does out of the water. Good luck forcing them to adopt something inferior.
On the other hand, good luck forcing Lemmy and /kbin to switch to a wholly different standard. Don't forget that these two exist as well. And good luck having the Fediverse outside of Hubzilla and (streams) adopt both server-side and client-side OpenWebAuth.
And I'm not even talking about how different Fediverse projects handle threads differently. Mastodon has a Twitter-like thread structure: many posts, tied together with mentiones. Just about everything that's built on ActivityPub has taken this over. Friendica, Hubzilla and (streams) have a Facebook/blog/Tumblr-like thread structure: one post, the start post, and many comments which aren't posts. It's similar on Lemmy and /kbin which are Reddit clones, only that they don't allow thread starters to moderate their own threads.- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.
This is something that almost the whole Fediverse has implemented, save for Mastodon.
And again, Friendica has had quotes since its inception in 2010, almost six years before Mastodon was launched (which, by the way, federated with Friendica and Hubzilla on the spot). Hubzilla has had quotes since 2012, inherited from Friendica. Their way of quoting is dead-simple: BBcode.[quote][/quote](streams) supports Markdown and HTML in addition to BBcode, but otherwise it's the same.
Oh, and by the way: Friendica, Hubzilla and (streams) have also supported quote-posts a.k.a. quote-tweets a.k.a. quote-toots a.k.a. quote-boosts from their very beginnings.- Markets. So far there's only one server implementation capable of processing payments.
At least two. Hubzilla has a payment add-on, too. It isn't installed on all hubs, but it's there.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CWFedisplaining #Fediverse #Mastodon #MastodonIsNotTheFediverse #NotOnlyMastodon #ActivityPub #Friendica #DFRN #Hubzilla #Zot #Streams #(streams) #Nomad #Lemmy #kbin #/kbin #NomadicIdentity #OpenWebAuth #Group #Groups #Forum #Forums #Quote #Quotes #Encryption #E2EE #E2EEncryption -
I wonder when we'll see custom domain #WebFinger in the #Fediverse / #ActivityPub ?
For example, I want to use:
* @-live.youronly.one for my #Streams account
* @-sns.youronly.one for my #Firefish account
* @-photos.youronly.one for my #Pixelfed account
* @-mblog.youronly.one for my #Mastodon account
* @-reading.youronly.one for my #BookWyrm accountIdeally, even if I move to a new host/service, I can use the same WebFinger.
#MycelialWeb #MyceliumNetwork #ActivityPub2 #AP #AP2 #Portability #AccountPortability #Nomadic #NomadicIdentity #SNS #SocialWeb #SocialMedia #SocialNetwork
-
Basically, everything in the #Fediverse that's based on #ActivityPub is built against #Mastodon. Because Mastodon defines the ActivityPub spec all alone.
Says the man who has created more federated protocols - #DFRN, #Zot, #Nomad - and Fediverse projects than anyone else and invented #NomadicIdentity.
Mike Macgirvin wrote the following post Tue, 05 Sep 2023 22:28:16 +0200 I provided my input to the AP spec editor and it was rejected outright. Everything I provided to the ActivityPub editor was rejected outright. If there were any questions, it had to go through the Mastodon dictator, who rejected anything he didn't invent. And then the ActivityPub editor would likewise reject it. "Mastodon has millions of users, you don't".
That's the way the process works.
The major concern was that nomadic identity is hard, and the clock was ticking on when the spec had to be finalised. The ActivityPub editor also insisted that it be done using the draft digital identity spec. So that ensured it would never make it into ActivityPub.
Here we are 5-6 years later and they still can't figure out how to do nomadic identity in a decentralised framework (outside of using torrents or centralised resolvers). Meanwhile we've had it, used it, and improved it for well over a decade.
There's a specification in the public domain. Some complain that it isn't enough, but I'm one person in a planet of 8 billion and haven't had any help developing this. The only help I ever get is with bike shed stuff - web interfaces. Not one person has offered any help polishing up the spec or improving the actual implementation code or even offered critique and discussing the subject. Just "I can't use this. Bye." [edit: apologies. That isn't entirely correct. I did get help from one person.]
I've started to pick it up and try again using did's as a proof of concept, but I'm retired now and really can't be bothered dying on the same hill over and over again.
But I will try and update Nomad (the protocol, formerly Zot) to use a did: form. It's just a replacement WebMTA for delivering JSON ActivityStreams which is nomadic aware. There's still no chance of it ever getting into ActivityPub unless it's invented by the Mastodon dictator.
Meanwhile the spec is in the public domain and there are working implementations and it federates with ActivityPub and nobody is holding a gun to anybody's head.
https://codeberg.org/streams/streams -
@CynthesisToday If you want to speak to someone who really knows his way around communications protocols, I'll have to refer you to @mike, creator of #Friendica, #RedMatrix, #Hubzilla, #Osada, #Zap, #Misty, #Roadhouse and #Streams and of the #FederatedSocialWeb protocols #DFRN (base protocol for Friendica) and #Zot (base protocol for all the others), thus also inventor of #NomadicIdentity, as well as contributor to both the #Diaspora protocol and #ActivityPub.
-
@Kevin Davidson @LabSpokane @Chris Trottier It's the very same thing as people demanding the #Linux ecosystem be reduced to ONE distribution with no variants, ONE graphics toolkit, ONE display manager with ONE desktop environment. Because Linux is "too complicated" otherwise. Because it makes people choose where Windows and Mac users don't even have a choice.
But this would leave many dissatisfied because that unified Linux will not cater to their individual tastes. If it sucks, Linux sucks altogether.
Of course, in the #Fediverse case, the one unified project which the Fediverse must be reduced to is always #Mastodon. Preferably always with the same set of features. No other projects, not even forks.
First of all, this would mean that the Fediverse would lose a great deal of its features. Mastodon can't do podcasts; #Funkwhale and #Castopod can. Mastodon can't do blogs; #WriteFreely and #Plume can. Mastodon can't do YouTube; #PeerTube can. Not to mention the many things that #Hubzilla can do that Mastodon can't.
Now, someone could suggest to cram all features of all these projects into Mastodon. But not only is this very likely impossible without re-designing great deals of Mastodon which, for example, doesn't offer the multiple-channels-per-account model and doesn't even differentiate between posts and comments. It would also irritate those who stick with Mastodon because it's the most simple of all Fediverse projects.
And indeed, there are many who wish for Mastodon to be frozen on the feature level of late 2022 when they joined. They're even opposed to the introduction of text formatting or quotes to Mastodon, features which would thereby vanish from the Fediverse altogether if the Fediverse was reduced to late-2022 Mastodon.
Besides, you won't be able to get everyone to cooperate on Mastodon, much less on Mastodon staying at the level of late 2022. Literally every project leader who isn't Eugen Rochko will demand more features than Mastodon had half a year ago, actually, even more features than Mastodon has right now.
So you've got two possibilies.
One, Mastodon ends up an even heavier feature monster than Hubzilla because everyone can add to it what they deem necessary or useful.
Two, Eugen Rochko becomes the supreme ruler over the Fediverse, and only he decides which features the Fediverse is allowed to have. And he bases his decision on the wishes of those who want Mastodon to stay simple. Everyone else is reduced to a code monkey with no free will, including Mike Macgirvin, inventor of the #DFRN protocol, #Friendica (both 6 years before Mastodon), the #Zot protocol, #NomadicIdentity (both 5 years before Mastodon), Red Matrix/Hubzilla (4 years before Mastodon), Osada, Zap, Roadhouse, #Streams etc. -
@Fred Brooker Not on #Mastodon with #ActivityPub as it is right now.
But the #Zot protocol, created by the #Friendica inventor Mike Macgirvin in 2011, seven years before ActivityPub became a standard, allows for something that's called #NomadicIdentity. In fact, Zot was created specifically for this feature.
Friendica with its #DFRN protocol already allows full account portability between instances on a degree that Mastodon users still think is absolutely impossible, and a Friendica account contains much more data than a Mastodon account.
Nomadic identity goes even further: It lets you have the very same channel on multiple instances at the same time. So you don't move to a new instance, leaving a dead and disconnected account behind. You create a 100% clone of your channel. And that clone will remain a clone, for it's kept in-sync with the original in real-time. And you can have as many clones as possible.
Sounds like utter science-fiction, right? But it's reality.
In 2012, four years before Mastodon, Macgirvin himself forked his own Friendica, ported it to Zot and renamed it Red. It was later renamed #RedMatrix, and when it saw its 1.0 stable release in late 2015, still months before Mastodon, it got its final and current name, #Hubzilla.
If you think it's still born, if you think something like this couldn't possibly have survived: Hubzilla is still around. It is still being developed. Its current version is 8.2 from last month, and 8.3 is being field-tested.
And yes, it still offers nomadic identity while each channel has features which Mastodon users couldn't imagine in their wildest dreams. And all of it is kept in-sync between instances by nomadic identity.
Also: I speak to you from Hubzilla right now. No, I'm not on Mastodon, although this should be clear from how long this post already is. Hubzilla has optional ActivityPub support per channel.
And even Zot itself is advancing. Not long after the launch of Hubzilla, Macgirvin created two forks for the development of Zot/6, #Osada with ActivityPub and #Zap without it. More forks came after Hubzilla had been upgraded to Zot/6 in order to develop Zot/8, #Mistpark2020 and #Roadhouse. All four are EOL now and superseded by #Streams which first saw the light of day last year, and which runs on #Nomad, formerly known as Zot/11, providing better integration of non-nomadic protocols such as ActivityPub. -
@fastfinge What if I told you that just about the whole Fediverse supports quotes, only Mastodon doesn't?
What if I told you that #MastodonIsNotTheFediverse? What if I told you that I myself am not on Mastodon, although this post of mine has appeared on your timeline?
What if I told you that, in fact, the Fediverse has been around for much longer than Mastodon?
What if I told you that it started in 2008 with something called Laconi.ca, now known as #GNUsocial (#^https://en.wikipedia.org/wiki/GNU_social)
Okay, GNU social doesn't really count as part of today's Fediverse because it doesn't support #ActivityPub. And okay, it wasn't called the Fediverse back then but the #FederatedSocialWeb. But still, the whole concept isn't new. It was not invented by Eugen Rochko.
Still, even today's Fediverse is more than Mastodon and older than Mastodon. And just about everything that isn't Mastodon supports quotes while still being fully federated with Mastodon.
But let me elaborate (warning, this post is over 12 times as long as a toot can possibly be):
#Friendica (#^https://friendi.ca, #^https://en.wikipedia.org/wiki/Friendica, #^https://joinfediverse.wiki/Special:MyLanguage/What_is_Friendica%3F) was launched in July 2010. That was six years before Mastodon. It was created by a guy named Mike Macgirvin as a decentralised, distributed, federated replacement for Facebook. No, not Twitter. Facebook.
From the very beginning, it had many features which Mastodon users keep demanding today. Including quotes. Again, when Mastodon was launched, Friendica had had these features in daily productive use for six years already.
And yet, people don't use quotes to harass others by "stealing" discussions. This is technically impossible on Friendica due to its architecture which is more like Facebook or a blog or a forum and less like Twitter or Mastodon. Threads aren't stand-alone posts floating around the timelines, loosely tied together by increasing numbers of mentions. Instead, they're start-post-and-comments structures. Replies aren't stand-alone posts. Replies are comments firmly tied to one start post by Friendica's internal structure.
Oh, and Friendica doesn't run on ActivityPub. It has its own internal protocol, #DFRN. Still, Friendica quickly created an ActivityPub connector and federated with Mastodon, thus becoming part of the Fediverse. Friendica federates with a whole lot of projects and platforms. In fact, there is a growing number of forums mostly frequented by Mastodon users which run on Friendica, such as FediverseNews.
I myself am on #Hubzilla (#^https://hubzilla.org, #^https://joinfediverse.wiki/Special:MyLanguage/What_is_Hubzilla%3F). It started life in 2012, still four years before Mastodon, as a fork of Friendica, created by Friendica's own inventor. In 2011 already, Mike had conceived an even more powerful protocol named #Zot which comes with features that are outright utterly unimaginable for Mastodon users such as #NomadicIdentity. Hubzilla even had its first stable release before Mastodon was launched.
And Hubzilla still has almost all the features Friendica has with a whole lot more on top. Again, including quotes. Again, yes, before Mastodon refused to have them. And again, yes, without anyone misusing them for harassment.
And again, it's part of the Fediverse and federated with Mastodon. Otherwise you wouldn't be able to read this.
I should also mention that both Friendica and Hubzilla have technical barriers in the way of publicly quoting private or restricted posts, at least with references/a connection to the quoted post. Hubzilla in particular has access rights control on a level you couldn't possibly imagine in your wildest dreams.
And just about everything else in the Fediverse that's microblogging or macroblogging has official, built-in quote support.- #Pleroma (#^https://pleroma.social/, #^https://joinfediverse.wiki/What_is_Pleroma%253F) has quotes. And it's part of the Fediverse and federated with Mastodon.
- #Akkoma (#^https://akkoma.social/), a Pleroma fork, has quotes. And it's part of the Fediverse and federated with Mastodon.
- #MissKey (#^https://misskey-hub.net/en/, #^https://joinfediverse.wiki/What_is_Misskey%253F) has quotes. And it's part of the Fediverse and federated with Mastodon.
- #CalcKey (#^https://calckey.cloud/, #^https://joinfediverse.wiki/What_is_Calckey%3F) has quotes. And it's part of the Fediverse and federated with Mastodon.
- #FoundKey (#^https://akkoma.dev/FoundKeyGang/FoundKey) has quotes. And it's part of the Fediverse and federated with Mastodon.
- #GoToSocial (#^https://docs.gotosocial.org/, #^https://joinfediverse.wiki/What_is_GoToSocial%3F) has quotes. And it's part of the Fediverse and federated with Mastodon.
- #Socialhome (#^https://socialhome.network/) has quotes. And it's part of the Fediverse and federated with Mastodon.
Yes, they're all federated with Mastodon. This means that users of any of these projects, including Friendica and Hubzilla, can read Mastodon posts and quote them in their replies, and these replies, in turn, can be read on Mastodon.
Okay, so the Fediverse has two, three, four... ten projects, and all but Mastodon support quotes, and nowhere are there people demanding the feature be removed due to rampant harassment?
No, these are only the microblogging and macroblogging projects, and only those of the macroblogging projects that aren't primarily for long-form blogging, i.e. that aren't mimicking Medium, that aren't mimicking WordPress, that aren't #Wordpress itself. Yes, there are WordPress blogs in the Fediverse, federated with Mastodon.
In fact, the Fediverse is even much, much bigger than that (#^https://fediverse.party/en/miscellaneous/, #^https://the-federation.info/).
Now go block me for harassing you, for being an ableist swine because I treat blind people equally instead of mollycoddling them wherever possibly, even for being a fascist or just for shattering your worldview into itty bitty pieces. This post of mine stands.
CC @Patrick, the Linux guy so that you know that the Fediverse is more than Mastodon, too
Also CC @Ada @James - #Pleroma (#^https://pleroma.social/, #^https://joinfediverse.wiki/What_is_Pleroma%253F) has quotes. And it's part of the Fediverse and federated with Mastodon.
-
@lafnlab @Bluedepth @Ada @Dave Troy :toad: @Supernovae aka Byron Miller @Mark Earnest @Paul Chambers :chambers: @Darren du Nord @Flaming June @Flatbush Gardener 🌈 @HistoPol @Qazm @David Boles @Fediverse Report
#Diaspora has its own protocol. It's distributed and federated within itself, but it is not interested in federating to anything else. All federation to the outside was established by the developers of other networks and by reverse-engineering Diaspora*'s protocol and directly tapping into its databases because it didn't have an API back then.
#Friendica has its own internal protocol, #DFRN. But Friendica's main goal was to federate with everything that moved. It was Friendica which established the first cross-project federation with Diaspora*. And Friendica also has #ActivityPub support. Otherwise, pretty much none of you could connect to @Fediverse News.
#Hubzilla has its own internal protocol, #Zot. Hubzilla also has ActivityPub support, this time optionally for each user channel because everything that isn't Zot kind of stands in the way of Zot's main killer feature, #NomadicIdentity.
Anything built from #Streams uses a successor of Zot, #Nomad. (streams)-based projects and instances have ActivityPub support, too, and like on Friendica, it's on by default.
So the latter three can directly connect to everything that uses ActivityPub. Interaction between Diaspora* users and, for example, Mastodon users can only happen in the comments on a post from Friendica or Hubzilla. -
@Brennan Stehling It isn't even the first. Not even for social networking.
Laconica = #StatusNet = #GNUsocial was the first. It was what drove Identi.ca. That was in 2008.
Then, in 2010, came #DFRN, the internal protocol created for and used by #Friendica. (Friendica can also use ActivityPub, that's how you can post on @Fediverse News.)
A bit later, also in 2010, came the internal protocol created for and used by #Diaspora.
In 2011 came #Zot, the first protocol that went beyond decentralisation and federation and introduced #NomadicIdentity. Starting the next year, it became the technical basis of what is known today as #Hubzilla. (Hubzilla can use ActivityPub as well, that's how you can read this post of mine. But its nomadic features don't translate fully to ActivityPub.)
All of this was before #ActivityPub.
The newest version of Zot, Zot/11, was renamed #Nomad and has been used by #Streams since last year. And (streams) being a "fork me and build something nice out of me" code repository rather than a run-as-is branded platform like Mastodon or Hubzilla indicates that Nomad, much like Zot, is quite versatile, as does the fact that Hubzilla's entire huge set of features is made nomadic by Zot.
Oh, and by the way, e-mail and #XMPP predate them all. And there's also #Matrix, for example.
@John Socks @Chris Trottier @{[email protected]} -
@Bob Wyman #Friendica doesn't use #ActivityPub because it predates ActivityPub by 7½ years.
The ActivityPub standard was published in January 2018. Friendica, then still called #Mistpark, had its 1.0 release in July 2010.
Switching seven-year-old Friendica to ActivityPub would have meant a complete re-write of an established social networking project in daily productive use. During the migration, it would have disrupted connections between instances. Also, Friendica would have suffered and degraded from the switch because current ActivityPub doesn't have nearly the feature set which #DFRN, Friendica's scratch-made internal protocol, had in 2010 already.
#Hubzilla had its 1.0 release, along with being renamed from #RedMatrix, in December 2015. This was still 2½ years before there was ActivityPub. Hubzilla had been in the making since 2012, originally being a Friendica fork named Friendica Red, created by Friendica's own inventor, Mike Macgirvin, then renamed Red, then renamed Red Matrix, then renamed Hubzilla.
Essentially, Hubzilla was created around a new protocol idea which Mike had in 2011 with an all-new feature: #NomadicIdentity. This feature could not be made possible by upgrading DFRN, so a new protocol was conceived in 2011, #Zot.
Migrating Hubzilla from Zot to ActivityPub as its base protocol would degrade it even more than migrating Friendica from DFRN to ActivityPub. Hubzilla has got even more features beyond what ActivityPub supports. Switching it to ActivityPub would mean axing one of its absolute killer features, nomadic identity.
@Nuno Nonetheless, both Friendica and Hubzilla are part of the Fediverse and fully and bidirectionally federated with, amongst other projects, Mastodon. Proof: You're on Mastodon, I'm on Hubzilla, and yet, you can read this post.
Still, the idea of requesting a mobile app for Android and iOS that can harness Hubzilla's full feature set, just like Tusky can harness pretty much Mastodon's full feature set, along with the full feature sets of all other Fediverse projects, no exception, can only come from someone who only knows Mastodon. You want easy access to all of Hubzilla's features through a touch screen? You better get yourself a USB touch screen the size of a newspaper, and even that wouldn't be sufficient.
Go back in this thread, and read through the feature list once again. -
@Bob Wyman For starters, everything I've listed is not only part of the #Fediverse, but bi-directionally federated with #Mastodon. So there's little to do with regards to establishing interoperability in the first place.
Beyond that: You can't blindly write a mobile app for these projects without knowing these projects in the first place. They aren't all Twitter-like microblogging services.
You need to know that these projects exist. You need to know how they work. You need to know their features. You need to know their specific APIs if they have any.
Also, #Friendica and #Hubzilla aren't even native #ActivityPub platforms. They have ActivityPub bolted-on as applications. On Hubzilla, you as a user even have to activate ActivityPub on your channel(s).
Friendica uses its own protocol internally, #DFRN, which, along with Friendica, was created eight years before ActivityPub was established as a standard.
Hubzilla was created around a protocol named #Zot which was invented in 2011 and introduced a concept named #NomadicIdentity. I can't see ActivityPub being expanded to everything that Hubzilla's current #Zot6 can do, much less everything that its direct successor, #Nomad, used by #Streams, can do.
Also, if you wanted to standardise Hubzilla's full feature set in ActivityPub so that app developers can create a mobile app for Hubzilla without ever having seen Hubzilla, you'd have to blow that standard up to gigantic proportions.
Since you obviously have never heard of it, let me list up some of its features:- cross-instance authorisation via #OpenWebAuth (which really only makes sense in a Web browser)
- multiple separate channels per user account with separate identities, each with multiple profiles à la Friendica which can assigned to individual users or privacy groups
- nomadic identity; not only easy moving of channels to other instances, but real-time mirroring of individual channels between multiple instances
- fine-grained privacy/access rights control through both channel roles and pre-definable sets of contact roles
- posts can have an almost unlimited number of characters; formatting is possible through the full standard set of BBcode plus Hubzilla-specific extensions, some of which tie into Zot/OpenWebAuth
- additional long-form writing support through articles which support the same BBcode set
- support for simple webpages which support the same BBcode set plus Markdown plus HTML
- built-in wiki engine which supports BBcode and Markdown plus individual edit access control for other users/channels
- built-in file server with WebDAV support and individual access rights control per directory
- image gallery which can tie into the file server
- public calendar inherited from Friendica
- secondary calendar engine with variable access control for other users/channels and CalDAV support
- address book with CardDAV support
- ca. 55 built-in per-channel applications, most of which are optional
- etc.
Let me put it this way: Hubzilla is something which, at its current state, can barely be harnessed in a desktop browser with a hardware mouse, a hardware keyboard and a 20+" display. I can't see Hubzilla's full set of features be made accessible in a mobile app, much less more easily than on the desktop.
If you really want to have all features from all Fediverse platforms standardised in ActivityPub, then ActivityPub would end up with three different calendar implementations alone, two of which Hubzilla uses (and they aren't connected to one another in any way), the third being that used by #Mobilizon.
Besides, I can't even see long-form blogging working on mobile phones. Apps for writing articles on #Plume, #WriteFreely or Hubzilla's article application don't make much sense without a hardware keyboard. Not to mention that Plume, WriteFreely and Hubzilla have different implementations of long-form blog post writing. - cross-instance authorisation via #OpenWebAuth (which really only makes sense in a Web browser)
-
@Chris Trottier @Christopher :coffefied: By the way, I think the devs behind #Hubzilla and #Streams are looking at ways of tying AT's #NomadicIdentity to #Zot6 and #Nomad already now.
The purpose would probably only be to present a nomadic channel on Hubzilla or (streams) to #Bluesky users as one entity and not one per instance, and to notify Bluesky contacts when you change your main clone, create a new one or shut down an existing one. That'd eliminate an issue still present in the federation between Hubzilla/(streams) and #ActivityPub connections. Maybe it'll facilitate migration between both sides. It probably won't allow you to mirror your channel between Bluesky and Hubzilla/(streams), though. -
@Kristian @Chris Trottier Free, non-corporate, decentralised projects have different intents and purposes than non-free, commercial, corporate, centralised silos. They're created by different people for different people, for different target audiences. And even the huge corporate silos don't start with a shiny iPhone app and then develop the server backend around it.
If it's free (as in, for example, Affero GPL), decentralised and distributed, it's made by geeks for geeks first and foremost. #Friendica first became available in 2010, and unlike Facebook, it never had the intention of becoming the next Internet for everyone in the world. Also, behind Facebook stood a huge megacorporation. Behind Friendica stood only one man, @mike, all alone, with zero budget. And yet, he managed to release something that was more powerful than Diaspora*, where at the same time only the crowdfunding campaign was running, would ever become.
Friendica's target audience were geeks. The same people that also used Linux as their main OS. Friendica wasn't made for the same people as Facebook or the iPhone. In fact, your typical Friendica user wouldn't touch an iPhone or any other Apple product with a 10-foot barge pole. They'd rather have a Nokia N900, and that was a clunky QWERTY slider that ran a modified Debian GNU/Linux.
#Redmatrix, the direct successor of Friendica, was experimental. Its sole purpose was to work on the brand-new #Zot protocol and the concept of #NomadicIdentity. It still had a small number of users and an even smaller number of instances, but they were generally voluntary guinea pigs. At this time, Friendica was already maintained by its own community which is about as far away from a Silicon Valley gigacorp as you could possibly get.
Redmatrix wasn't declared ready for prime time until late 2015 when it was renamed #Hubzilla. And even then, it didn't come with the "vision" of rolling over the mass market and replacing Facebook, WordPress, MediaWiki and the various GAFAM cloud services in one fell swoop. Again, Hubzilla was developed pretty much only by Mike Macgirvin.
#Osada and #Zap were both largely experimental again. Mike had forked them off Hubzilla because he still wasn't satisfied with what Zot could do at the time. However, the development of the new version #Zot6 couldn't happen on that monster named Hubzilla that was in everyday use now. That's why these two new projects were launched.
There's a good reason why they were two projects. Zap was there first. Zap was the actual Zot6 testbed, and thus, Zap was Zot6-only. Osada retained compatibility with Friendica and Hubzilla to test how well Zot6 would interact with ActivityPub with had meanwhile appeared as a draft and, IIRC, adopted by both Friendica and Hubzilla. Eventually, Osada and Zap ended up having the exact same codebase, and the difference between the two was an admin switch: ActivityPub on made it Osada, ActivityPub off made it Zap. As this was non-sense, Osada was axed, and Zap got ActivityPub and was declared the next stable one.
First, Zap's main killer feature over Hubzilla was Zot6 which had introduced #OpenWebAuth. When Zot6 was finally backported to Hubzilla, the remaining advantage was that Zap wasn't nearly as bloated with a somewhat less overwhelming UI. By the way, Redmatrix continued to exist with one user until Mike Macgirvin upgraded his own instance to Zap.
Now, again, you can't tinker with something that's stable. And tinkering continued. #Mistpark, Friendica's early name, returned in 2020, as did Redmatrix and Osada, all as Zap forks at various stages of instability and being experimental, none intended for a wider audience. And all created by Mike Macgirvin again. You could happily switch back and forth between Redmatrix, Osada, Zap and #Misty by simply rebasing your server code. (Installing either usually involved "git clone".)
He actually had a very good reason for this maze of names: He is opposed to big mass products with big brand identities. He wants to offer people technical solutions, not cool stuff with a sleek brand on it.
Anyways, on top of all this came #Roadhouse, another fork from somewhere in this conglomerate which was created in 2021 and solely intended for the development of the next Zot version, originally named Zot8, now known as #Nomad. Roadhouse was so experimental that there has never even been an official text saying what it actually was.
Also in 2021 came #Streams, a Roadhouse derivative that started out just as mysterious but was eventually intended for the public. It's often also referred to as (streams) because it's different from its predecessors in one point: It's even less of a brand. It isn't a product to be used as-is. (streams) is not a "Fediverse platform" that's waiting for its own iPhone app. (streams) is a code repository on Codeberg. And its purpose is for others to take the code and make something out of it. It isn't meant to be run as-is, although you can do that, and some people do. And even then, it comes without a fixed brand and kind of asks you to "rebrand" it, even on a per-instance basis. Most (streams)-based instances don't identify as (streams). Mike who is still involved in the project has his own instance based on (streams) but, probably deliberately and intentionally, still has it identify as Zap.
Another interesting fact: (streams) uses a wild hodge-podge of free licenses. Most of it is in the public domain, but parts of it are under various free licenses which aren't compatible with each other. This is fully intentional, too. It makes using (streams) for commercial products pretty much impossible because no corporate legal department will be able to figure out how to legally comply with all these licenses at the same time. Free use stays basically unlimited, though.
By the way: As of January 1st, 2023, Redmatrix, Osada, Zap, Misty and Roadhouse are EOL and discontinued, and their code repositories were closed. Instances running them can and shall be upgraded to (streams). All that's left is Friendica (the old faithful one), Hubzilla (the nomadic monster) and (streams) (the one for the tinkerers).
Now there's still the question: Why do all these projects, in fact including #Mastodon, use this approach? Why do they start with a server platform plus Web frontend instead of doing as big corporations do and start with an iPhone app and develop a server backend around it? Why appeal to a small bunch of Linux nerds rather than to a mass-market of billions?
Because if you want to go free and decentralised and distributed and federated, you'll need those Linux nerds before everyone else.
First of all, you'll need someone to run instances. Thus, you'll need people who are willing and able to do that. This requires Linux knowledge. The ability to use the command line. The ability to set up and configure a Web server. Network knowledge to connect it to the internet. You can't set up a Web server from zero with three taps on a mobile app.
In fact, when Diaspora* was young, it only ran on Mac servers. All four creators were Apple fanbois who didn't care for anything without the Apple brand on it. The Diaspora* server application was built against macOS. The result was a dire lack of public pods (instances) and everyone piling on the official pod. Mac users don't run Web servers at home, and I guess there were no hosting companies that offered Web hosting on Macs. The devs eventually had to make the server app at least halfway Linux-compatible to get more people to run pods, and you still had to compile Ruby on Rails from sources on Debian stable because Diaspora* depended on a newer version.
Also, you'll need these tech geeks to spot and report bugs. Your typical Windows or Apple user doesn't report bugs; they only complain about them or switch to a competing product. In stark contrast, many Linux users even know how to file a good and informative bug report. Some are even capable of submitting pull requests with bug-fixing patches through git.
And at least in the case of Mike's projects, you'll need a community that's capable of taking over the project itself and continuing its development. You'll need people who know how to code. You'll need people who know how to use git. And so forth. You'll hardly find such people amongst the masses who have spent all their digital lives in the cosy world of corporate-designed GUIs.
If, for example, Mastodon had started out with iPhone and Android apps and gone from there, appealing to a rather tech-illiterate mass audience, it would probably never have become decentralised. At least not beyond the federation between mastodon.social, mastodon.online and whatever more instances Eugen Rochko would have had to launch because these two were full.
And why not? Because Mastodon wouldn't have appealed to people who know how to install and run Mastodon instances. Mastodon would have only had the Windows/Mac/iPhone/Android crowd as users. All the geeks who would have known how to set up and run a Web server would have stayed on Friendica and Hubzilla. Some may have used ActivityPub to connect to Mastodon, but hardly anyone would have switched to that actually inferior platform with a wholly different crowd on it. -
@aijooyoom @Chris Trottier @David Slifka @Fediverse Identity Discussion @Fediverse News Or one could use something that has existed in the #Fediverse for years already: #Zot6 or #Nomad along with #OpenWebAuth.
#Zot, the protocol created for #Hubzilla, introduced #NomadicIdentity a good decade ago. Nomadic identity means you can not only move from instance to instance with ease, but you can have identical, synchronised copies of your channel on as many instances as you want instead of on only one. You always have one "main copy," but your identity is not firmly tied to any one instance.
OpenWebAuth, to explain it in brief, transfers your login on supported sites to other supported sites.
The OpenWebAuth specs: #^https://zotlabs.org/page/zot/specs+openwebauth
And yes, Hubzilla is part of the Fediverse. -
@Ada @defcon42/Mirko @[email protected] To me, it sounds more like some #Mastodon users, especially those who came in through the #TwitterMigration, actually can't stand there being something else in the #Fediverse than their beloved Mastodon. When they caught their first glimpse of the Fediverse beyond Mastodon, they reacted much like the people of Krikkit when they caught their first glimpse of the universe beyond Krikkit: "It has to go!"
They make themselves and each other believe that Mastodon is superior to any other Fediverse project in just about any regard imaginable while apparently completely refusing to learn about those other projects. They're supported in their belief by mass media only ever writing about Mastodon and the number of Mastodon users.
However, mass media only write about Mastodon because they simply don't know a thing about the rest of the Fediverse, and they didn't know a thing about Mastodon until the #TwitterTakeover had actually happened, and the second wave of former #birbsite users had come flooding into Mastodon in such numbers that it was impossible to ignore even for those who act as if #FLOSS doesn't exist.
As for the numbers of Mastodon users, they're so high because I guess more than 90% of all Mastodon users still don't know that the Fediverse is not only Mastodon, because they have never heard of anything else in the Fediverse. Mastodon was pretty much the only Fediverse project advertised on #BirbSocial when this was still possible.
There are various reasons why Mastodon users don't spread across the Fediverse in masses. None of it is because Mastodon is superior to everything else because, truth be told, it isn't. I'll come to this later. One reason is, again, that the vast majority of them still don't know anything else. Another one is because it was hard enough to get used to Mastodon after years of using #Twitter, and they don't want to get used to yet another platform. And another one is that it's hard to move from Mastodon to something else and take your account or at least your connections with you.
Another reason may be because people don't need anything beyond microblogging, and that's what Mastodon does. Now, sorry for all those of you who fight tooth and claw to defend Mastodon against the competition, but #Akkoma does microblogging, too. With extra features beyond Mastodon, some of which Mastodon users have been pestering Eugen Rochko to include in Mastodon for ages (e.g. "quote retweet"). All while being more lightweight and requiring fewer server resources than Mastodon. Oh, and it federates with Mastodon.
Other Fediverse projects aren't even competition for Mastodon because they specialise in something else. @Pixelfed specialises in posting pictures, much like #Instagram. @PeerTube specialises in video upload and streaming, not too dissimilarly from #YouTube. #Plume and #WriteFreely specialise in distraction-free traditional blogging, much like #Medium. #Lemmy specialises in groups and posting and discussing news, much like #Reddit or #HackerNews. You can't claim that Mastodon is better at each of these things than these platforms.
And then there are the jacks-of-all-trades which are usually filed under either "macroblogging" or "like #Facebook ". They weren't launched to have something that goes beyond Mastodon because their history reaches far back before Mastodon. Mastodon was launched in 2016 (and not 2022 like many believe). #Friendica was launched in early 2010, even before the crowdfunding campaign for the development of #Diaspora started. And in that early stage, Friendica, then still named #Mistpark, was vastly more powerful than Diaspora* ever got and also vastly more powerful than Mastodon 13 years later.
#Hubzilla, created by the same man as Friendica, is the most extreme one of them all. For starters, it eliminates the need for multiple accounts by having multiple independent channels with separate identities on the same account. Each channel can have multiple profiles like on Friendica so you can present your channel differently to individual contacts or groups of them and differently again to the general public.
It can do micro- and macroblogging with 50,000 or more characters and just about everything that can be done with #BBcode (italics, bold type, underline, lists with bullet points or numbers, quotes,code blocks), and you can embed as many pictures as you want in your posts where you want them instead of them automatically being attached to the end of the post.
Group handling in Hubzilla is much easier than list handling in Mastodon. You never have to type the name of a contact to find them. You can edit contacts and add them to groups or remove them, and you can edit groups and add or remove contacts, all with a few mouse clicks. And while Mastodon shows a maximum of four lists on the main page, Hubzilla will give you easy access to all your groups.
On top of that, you can have- very fine-grained access rights control with pre-definable contact roles
- forums (just like Friendica, Hubzilla has #Guppe built in)
- more elegant macroblogging with articles which, in addition to BBcode, support #Markdown
- simple webpages (or not so simple if you're the admin of a hub, and you can expand it further)
- wikis (I'm not even kidding)
- a public calendar
- a virtually unlimited number of private calendars with #CalDAV connection
- a virtually unlimited number of address books with #CardDAV connection
- a file server with #WebDAV connection with its own access rights management which also ties in with the Photos and optional Gallery app (Mastodon drops your pictures somewhere, Hubzilla lets you upload them to your personal cloud space where you can access them whenever you want)
All with one run-of-the-mill Hubzilla account. And once per channel, separately.
And as if that wasn't enough, Hubzilla introduced the #Zot protocol and with it a concept named #NomadicIdentity.
Mastodon and Friendica let you have multiple accounts, even on separate instances. They also support migration from one account to another, and unlike Mastodon, Friendica lets you take all your content with you. Hubzilla (and #Streams, the successor of its slimmed-down successor, still created by the same guy) goes even further: Not only can you easily move from one hub to another, you can have channels on multiple hubs and automatically keep them fully in sync! If one hub goes down, it doesn't matter because you've got everything on all your other accounts.
Last but not least, both Friendica and Hubzilla federate with almost everything that moves, even far beyond the #ActivityPub Fediverse. This could be Diaspora*, this could be #GNUsocial, this could be #Wordpress blogs with or without the ActivityPub add-on, this could be RSS feeds (and they both generate feeds themselves, so this is bidirectional, too), this could even be Twitter until the API is shuttered. Friendica even used to federate with Facebook until Facebook put rocks in the way; this is the only connector that Hubzilla didn't take over.
The obvious downside is that for someone who just came in from the #birdcage, all this is utter overkill. In fact, people who are used to Mastodon may find Friendica borderline unusuable due to its many features. And Hubzilla is so infamous for its own clumsy UI capitulating before its sheer power that even Friendica users find it hard to use, fresh converts from Twitter to Mastodon even more so.
Some design decisions may be hard to understand for outsiders. Converts from other Fediverse projects to Hubzilla regularly fail at something as seemingly similar as connecting to users on other ActivityPub-based projects until you tell them that ActivityPub is an optional app on Hubzilla that has to be activated first because Hubzilla concentrates on Zot with its Nomadic Identity.
Also, just because these projects offer so much power, that doesn't mean that everyone needs it. If you do, it can be convenient to have it all under one login. But if all you're looking for is a bit of microblogging and online socialising, you don't need to drag a CMS and a full-blown cloud server with all bells and whistles along with you that just clutter up the UI. In that case, projects like Mastodon and Akkoma win because they're more approachable.
And while Friendica, Hubzilla & Co. can do threaded discussions and even have something like forums, Lemmy can do this more elegantly because it specialises in it. While you can use Hubzilla's private calendar feature for event planning, it's easier to do the same with #Mobilizon which, again, specialises in it. Or you can host podcasts on Friendica, Hubzilla & Co, but you can host them better on #Funkwhale and even better on #Castopod.
Wanting the Fediverse to be only Mastodon hinders development, namely the development of new projects within the Fediverse that may be able to do all-new things that we haven't seen in the Fediverse yet. Things that, sorry to say again, you'll never be able to do with Mastodon.
P.S.: For extra kicks, don't just read this on Mastodon. Open my original post; there you can see what Hubzilla is capable of, and what Mastodon strips away. - very fine-grained access rights control with pre-definable contact roles
-
CW: This is how I witnessed the development of Friendica, Hubzilla, Streams & Co.
Allow me to digress from the usual topic on this channel once more.
I'm pretty sure that no human being on this planet has created nearly as many federated social platforms as @mike. But all these (actually not always so) different platforms can be a bit confusing. Even I may be wrong here and there, but I'll try to make some sense of them by putting them into a kind of chronology.
So first, there was #Friendica. Only that it started out under the name of #Mistpark. I'll get to the name later.
Remember #Diaspora? Remember summer 2010 when the crowdfunding run was launched so that those four guys could spend all their time creating a free, #OpenSource, decentralised, federated social network (a.k.a. #Facebook killer) which they wanted to name Diaspora*?
Well, they unknowingly wanted to re-invent the wheel. #StatusNet was already there, #GNUsocial was already there, and especially, Mistpark was already there with a 1.x release and more powerful than both, actually, more powerful than Diaspora would ever become. I think Mistpark even already had Diaspora*'s aspects, only that they were called groups.
As for its concept, Mistpark went beyond that of Diaspora*. Mistpark didn't only want a bunch of instances ("nodes" in this case) of its own kind to connect with one another, it also wanted to federate with everything else that moved, be it e-mail, be it StatusNet, be it Twitter, be it whatever.
The first name change was from Mistpark to #Friendika. The reason was that the original name sounded repelling to German speakers. "Mist" means "fog" in English, but "dung" or "manure" in German, not to mention that it's a German curse word.
When Diaspora* was finally there, Friendika didn't see it as competition, it saw it as another federation target. To this day, Friendica is fully federated with Diaspora*, and that has exclusively been the work of the Friendika developers who studied Diaspora*'s source code and reverse-engineer it because it didn't have an API.
Probably the biggest coup was the bidirectional federation with Facebook. This was what everyone was waiting for. This, however, was also where the trouble started. Facebook didn't want to be federated with a non-commercial social network and started taking defensive measures. Also, Friendica users (the second name change was through meanwhile) who used the Facebook connector had their entire and often very busy Facebook timelines mirrored onto Friendica nodes, one of the reasons why even nodes on powerful root servers often had to close new registrations even though they only had a little over a hundred users. So there were several reasons why Facebook federation was axed again.
Internally, Friendica uses its own protocol named #DFRN. But I guess Mike had meanwhile seen it as a dead end, also because he had a new idea: #NomadicIdentity, not only the ability to easily take your account from one instance to another, but the possibility to have it on multiple instances at the same time, keeping the copies in sync.
That's why he laid the foundation for a new protocol that could do that: #Zot.
And with it came the next social platform. It was first just simply named Red from Spanish "red" = "net". Red was based on Zot from the beginning, and as an experimental platform, it only understood Zot. On Friendica which was now running at full steam on dozens upon dozens of nodes, and which Mike had passed on to the community, the development was followed with interest. And just like later platforms, I think Red actually got a few small public instances because someone really wanted to try it out. Red eventually changed its name to #RedMatrix.
Also, Red didn't just want to be a social network like Friendica. The idea was rather to have a "social content management system" that could do just about everything you could do with a website and/or a cloud server. Third-party federation was slightly reduced, connections to commercial platforms didn't come back. But as Red evolved, the Diaspora* connector was included which was also used to federate Red with Friendica.
From the Red Matrix emerged #Hubzilla, the Swiss Army knife of the #Fediverse. Still today, its possibilities have rarely ever been fleshed out: not only microblogging, but macroblogging, article publication, websites, wikis (no, I'm not kidding), #WebDAV, #CalDAV and #CardDAV server and so forth.
Next to the nomadic identity that came with Zot, Hubzilla introduced another killer feature: one account, many separate channels. Each one of these channels is basically like one Friendica account. You can have multiple fully separate identities on one account, and nobody (except the instance admin) can tell that they're all you. So this goes way beyond Friendica's multiple profiles. By the way, Hubzilla still has multiple profiles per channel.
Some say that the Red Matrix was renamed Hubzilla. This isn't true. Hubzilla is a fork of the Red Matrix, one could say it was a stable snapshot of the Red Matrix.
For the development of the Red Matrix continued. Planned advancements on Zot couldn't be tested on stable Hubzilla, they needed their own testbed. Eventually, the last Red Matrix instance was Mike's personal one with himself as the only user. It still federated with Friendica and, of course, Hubzilla.
In the meantime, #ActivityPub came along. It wasn't just another obscure networking protocol, though, because #Mastodon made it huge. So at least Friendica and Hubzilla had to adopt it. Friendica firmly integrated it. Hubzilla made it into an app just like all other protocols that aren't Zot because they stand in the way of fully nomadic identity. By the way, both profited from its introduction because the federation between each other no longer had to use the Diaspora* protocol.
For the next advancements of Zot, two new platforms were forked from the Red Matrix or Hubzilla. At this point, Mike wasn't involved with Hubzilla anymore either. First, there was #Osada, an early testbed for what would become #Zot6, but still with ActivityPub. For pure Zot6, #Zap followed suit. Most connectors that are neither Zot nor ActivityPub, including the one to Diaspora*, weren't taken over, as were many of Hubzilla's extra abilities (websites, articles, wiki, CardDAV, two parallel calendar systems etc.) to keep it slim. It did get to keep the various types of channels as well as one CalDAV server and the WebDAV connection, though.
Eventually, when Mike handed them over to the community, they used the exact same code base. The only differences between Osada and Zap was whether or not the admin had ActivityPub on (Osada) or off (Zap) and the name.
As having two different names for the same thing, depending on the instance configuration, Osada was discontinued in favour of Zap which now included ActivityPub itself. In the meantime, Zot6 became stable and was backported into Hubzilla which thereby became fully compatible to Zap, only that what Hubzilla can that Zap can't cannot be mirrored to Zap.
Then Osada re-emerged as Zap's unstable branch. Along with it came a new Red Matrix which, as far as I could see, was now an even more purist, even more unstable branch that only served for testing Zot8 and lacked all other protocols.
To top this off, in 2020, Zap itself got a stable branch even more intended for productive use. For this purpose, the name Mistpark was dusted off. The new stable branch was named #Mistpark2020 or simply #Misty. Misty was the first of its kind to not even get an announcement anymore, though. Its home page on Zotlabs disappeared along with Zotlabs before it could be filled with any useful information.
Two things were interesting: Red Matrix, Osada, Zap and Misty were based on various states of the same code base. It was possible to switch from one to another by rebasing the local code repository on your server. This became obvious through instances that carry the name of one project but run another one.
It must have been in 2021 when #Roadhouse showed up, again, unannounced. It seemed to be nothing more than a concept for the next generation of distributed social platforms. Roadhouse was the first of its kind to use the #Nomad protocol which, I guess, is forked from #Zot because it serves the same purpose. It got its own home page on Zotlabs which remained as uninformational as Misty's.
And then the most recent name popped up: #Streams. At first, it was even less clear what Streams was supposed to be and what set it apart from Roadhouse, not to mention Red Matrix, Osada, Zap and Misty, also because Zotlabs didn't say what Streams was either.
But I guess Streams' purpose has emerged in the meantime through word-of-mouth: It's the experimental successor of all five and the solution to this maze of names. Streams isn't even a product with a name, it's a concept that uses Nomad for nomadic identity and that is in constant flux, hence Streams. The idea was to do away with fixed names to get rid of the previous chaos. Everyone can name whatever they do with Streams however they want.
There is currently only one more or less public Streams instance, but it still carries "Stream" in its name. At least two more instances which may be private are named something with "Streams", too. So whether Mike wants or not, Streams has become a name of its own, and people use it.
How many Streams instances exactly exist right now is hard to tell, even from Communities pages on Streams instances or Sites pages on older platforms, because they don't necessarily identify themselves as Streams instances. So if you go through one of these pages, and there are names in the Projects column which you don't know as Fediverse platforms, check out what's behind them. It's often only one instance. Open the instance, click its burger menu, and if there's a Communities link, it's a Streams instance. I've discovered a lot of Streams instances not named anything with Streams this way. Private instances included, I guess Streams must have more than a dozen instances already.
There has even already been a request to launch a Streams support forum much like the one for Hubzilla; after all, Streams still supports forums. It's safe to say that Streams is doing quite well for something so obscure.
Feature-wise, Streams is the same as Zap and Misty.
But what became of the six platforms between Hubzilla and Streams?- Red Matrix kept having only this one single-user instance because nobody else dared to touch it and set up another instance. It's a Zap instance now as far as I can see.
- Osada never really took off, Zap probably did only after Osada was merged into it, and some Osada instances became Zap instances. This explains why Zap has got comparably many instances. Most of them, however, are tiny, probably private and utterly undermaintained as they run rather old Zap versions. Zap only lives by numbers, and it's the only one of the five listed on Fediverse Observer. Also, while the FediDB lists all five, it only knows that one Dominican public Zap instance and none of the others (looking through its connected sites reveals many unlisted instances of Zot-based networks, by the way). Still, it seems to be on the deathbed, being superseded by Streams, experimental as the latter may be.
There still seem to be a very few running Osada instances, but Osada can be considered dead as the focus is on Streams now. - Misty didn't take off either, even though it was considered more stable and more production-grade than Zap. This time, the reason may simply be because Misty got zero advertising, so nobody heard about it, probably not even some of the Zap crowd. Misty never had many instances, they weren't properly advertised either (the same applies to most Zap instances, by the way), and Misty's death knell may have been the unannounced shutdown of its largest instance. Basically, there was little room for Misty next to less obscure Zap.
- Roadhouse didn't even manage to get much limelight before Streams appeared shortly afterwards. In both cases, the only way to find out what they were and what they did was by either studying the source code or installing a private instance. Streams, however, had the advantage of being even newer. The-Federation.info knows exactly one German Roadhouse instance which was originally set up as Misty and has meanwhile been upgraded beyond Roadhouse to Streams, and there only seems to be one remaining unlisted Roadhouse instance.
- I've seen another result of an upgrade from Zap to Misty. So it's safe to assume that you can upgrade all five to Streams. If this is the case, then now that Streams is here, it probably isn't worth spreading the developer community across six almost identical platforms. Basically, Streams has become the latest version of Red Matrix, Osada, Zap, Misty and Roadhouse.
- At least Red Matrix, Osada, Zap and Misty are still being maintained in a sense, though. All four got the same small Git commit from Mike a good month ago. Roadhouse got one four months ago.
As of now, Friendica is still going strong, so is Hubzilla, and Streams seems to be cleaning up the mess that came after Hubzilla.
If you really want to try out something with Zot, my current recommendation is Hubzilla, even if it may seem bloated and cumbersome to you, even if you'll never harness its full power. Many of its extra functions are additional apps and switched off by default; this includes ActivityPub, by the way, this is important to know.
It's hard to find a public Streams instance with open registrations currently, much less multiple ones that'd be required for a nomadic identity. Neither Fediverse.party nor the FediDB nor The-Federation.info nor Fediverse.info even knows Streams, and existing Streams instances usually don't identify to other Fediverse servers as Streams instances. It's still a rather underground and grass-roots project with no publicity at all. As Streams is rather experimental, however, you may want a nomadic home on at least two instances to have an instant backup, should one of them shut down.
Zap has got exactly one instance open to the public, and seeing as Zap may be shrinking rather than growing, I don't expect this to change. Again, due to Zap's still small size and unclear future, I wouldn't recommend using it without nomadic identity as a safety net.
As for Osada or Misty, good luck finding an instance to join, much less one that's here to stay and ideally be upgraded to Streams one day.
Hubzilla may not be as bleeding-edge as Streams, and it may be overkill for your purposes if Zap or Streams would be sufficient, but it's stable, it's big enough, it's established, and it's different enough from Streams to not be endangered by it. I mean, Hubzilla hasn't managed to kill off Friendica either, right? - Red Matrix kept having only this one single-user instance because nobody else dared to touch it and set up another instance. It's a Zap instance now as far as I can see.
-
what if use #cjdns address as primary id for #nomadicidentity . #activitypub nodes could be interconnected via #hyperboria, and handle user's interaction using their cjdns address. So you can join any type of node, and start sharing your followers with videos from #peertube or with photos from #pixelfed . If chosen instance dies, user can just join another, without losing his social network. Node's domain will just expose user's content to www