#openwebauth — Public Fediverse posts

@Strypey Locally writing content to the database of an ActivityPub-based server will inevitably require a local user account on that very server.

I mean, we already have OpenWebAuth magic sign-on which was invented by @Mike Macgirvin ?️ for Hubzilla in 2017, and which also has full implementations in his later server applications (streams) and Forte and a client-side implementation on Mike's first project, Friendica. But without an actual account on another server, OpenWebAuth can only authenticate you on that other server as a guest and grant you certain guest permissions. It does not give you all the powers of a local user, at least not without a local account.

Also, if you want to actually log in on another server, you will inevitably need local login credentials on that server. Which means that a user account with these login credentials must be created prior to you logging in on that server so that that server knows your login name and your password. Even if you want to use something like OAuth, that server will still require to know your credentials. They will have to be in that server's database before you can successfully log in.

A server cannot and will not authenticate you against credentials in a wholly different remote server's database. What you and many other Fediverse users dream of can only be solved in two ways and both only theoretically because, in practice, they are just as impossible or at least very unfeasible.

Either if you register an account on one Fediverse server, that account with the exact same credentials is simultaneously created on literally all other Fediverse servers, and on Hubzilla, (streams) and Forte, you also automatically get a channel along with that account. This also means that each Fediverse server that's installed and spun up for the first time will immediately have to create tens of millions of accounts so that everyone all over the Fediverse automatically has login credentials on that server. I guess it should be clear that this is impossible, also because this requires a) a centralised list of absolutely all Fediverse accounts and identities and b) a centralised list of all Fediverse servers to be hard-coded into every last instance of every last Fediverse server out there.

Now, I keep reading stuff like, "But I don't want to use all Fediverse servers!" No, but you want to be able to use any Fediverse server. And then you will have to have an account there. How is the Fediverse supposed to know in advance which servers you will visit this year, the next two years, five years, ten years so that accounts can be automatically created for you exactly there and nowhere else?

See? And that's why, if you want to be able to use any server like with a local account, every server must be prepared for it before you arrive.

Or drive-by registration: You visit a Fediverse server for the first time, your active login is recognised by that Fediverse server, and an account is created for you on the fly with the exact same login credentials as where you're already logged in. That's its own can of worms.

Also, it requires remote authentication. OpenWebAuth. As I've already said: This is technology that's eight years old, and that's being daily-driven right now. But: You will never have this on Mastodon. There actually is a pull request for Mastodon from two years ago that would have implemented client-side OpenWebAuth support. It was never merged. It was silently rejected by the Mastodon developers. The PR was closed in November, 2024.

Some people go even further: They don't just want their login credentials wherever they go, they want their whole identity cloned to everywhere. They want all their stuff, all their posts and comments and DMs, all their followers and followed, all their settings, all their filters etc. etc. pp., they want it everywhere all the same. Like a nomadic identity (an invention by Mike from 2011, first implemented in 2012) across up to 30,000 servers.

Now, you and many others on Mastodon are probably going to cry out, "YES, YES, PLEASE MAKE THIS REALITY!"

But seriously: I myself have actually cloned enough Hubzilla and (streams) channels of mine in my time. None of them even had nearly as much content on them as your Mastodon account. And I can tell from a lot of personal experience that this cannot be done within a blink of an eye.

Nomadic identity won't come to Mastodon anyway. Nomadic identity via ActivityPub is probably being daily-driven already. Forte has it, and it relies on it. But Mastodon will never implement it. In particular, Mastodon would rather re-invent the "nomadic identity" wheel in a way that's incompatible with what we already have than implement something made by Mike Macgirvin. Not after all the head-butting that has happened between Mike and Gargron over the years.

And OpenWebAuth won't come to Mastodon either. Probably also for the same reason.

CC: @Tim Chambers @rakoo @Ben Pate 🤘🏻

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity

@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.

The Sin of Overwhelming Complexity: Instance Selection Paralysis

The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.

In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.

In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.

Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.

Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.

Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.

The Sin of Inconsistent Navigation: Timeline Turmoil

The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.

First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.

Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.

However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.

Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.

The Sin of Remote Interaction Purgatory: Federation Gymnastics

Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.

But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.

You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.

Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.

So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.

Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.

Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).

Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.

Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.

The Sin of DM Disasters Waiting to Happen

I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).

On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.

If I want to DM you, I can either tag you @!{[email protected]} rather than @[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.

Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.

Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.

If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).

Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.

Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.

The Sin of Ghost Conversations and Phantom Follower Counts

And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.

Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.

This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.

Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.

Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.

Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.

So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.

The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.

The Sin of Invisible Discovery: The Content Mirage

I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.

But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.

Also:

• Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
• Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
• (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.

Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.

Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.

(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.

As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.

The Sin of User Discovery Hell

Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.

Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.

The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.

Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.

Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?

Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.

Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.

Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.

(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.

These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").

Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.

This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.

(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.

If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.

A global directory of everything sounds like a good idea, but it's next to impossible to implement.

Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?

Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.

For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.

Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.

Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.

But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.

Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.

Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?

CC: @Risotto Bias

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers

@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

@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

@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

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

@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.

@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.