We need to separate identity from servers in the ActivityPub world. It's time. I should be able to have a single identity and use it with lots of servers from Mastodon to Lemmy and beyond.

Then, various instances could reflect different communities with different people in them, different features and policies.

This also would elegantly solve the "instance selection paralysis" in @tchambers 's Deadly Fediverse UX sin #1.

Fortunately @benpate is starting to assemble people to solve this.

@j12t @tchambers @benpate why would I want to share an identity across services?

I have friends who are geeks who happen to have Crohn's and family members who have Crohn's, so I was invited by algorithm to a Crohn's support group. Irrelevant but harmless. Why would I want the same identity across groups that would allow more spurious (or politically dangerous) connections?

Multiple identities is a feature, not a bug, despite what Google, Meta and the rest want us to believe.

@craignicol @tchambers @benpate both use cases are valid. I want multiple uncorrelated personas to keep aspects of my life separate — work vs personal, political activism vs shopping etc. I want the same persona when I want people to see that I’m the same person in multiple places — like I write this blog, I post on mastodon, share on Pixelfed, all within the same persona.

@ craignicol Redundancy. Resilience against losing the server that you're on by being on another server simultaneously.

Also, just because you can spread your identity across multiple servers and even server types, doesn't mean you can only have one identity.

Look at me, for example:

  • I have @ Jupiter Rowland on the Hubzilla hubs hub.netzgemeinde.eu and hub.hubzilla.de.
  • I have my "in-world sister's" channel @ Juno Rowland on the same two Hubzilla hubs. It's still a separate and fully independent identity, and I could clone either of them to other Hubzilla hubs independently from one another. Like, I could clone @ Jupiter Rowland to hub.hubzilla.hu and @ Juno Rowland to klacker.org or whatever.
  • I have my in-world image-posting channel @ Jupiter Rowland's (streams) outlet on the (streams) servers streams.elsmussols.net and nomad.fedi-verse.hu.
  • I have my Fediverse meme channel @ Jupiter's Fedi-Memes on (streams) on the (streams) server streams.elsmussols.net; I haven't cloned it yet.
  • In addition, I also have my non-nomadic WriteFreely blog @ Aus Hypergrid und Umgebung and my non-nomadic Lemmy account @ Jupiter Rowland.

That's six fully separate, fully independent Fediverse identities, even though Mastodon and most of the rest of the Fediverse (anything that doesn't understand nomadic identity) perceive them as nine identities. And as you can see, what you may have taken for utter science-fiction two minutes ago is being daily driven in the Fediverse right now. And it has been for well over a decade, for longer than Mastodon has been around.

Why have I cloned my identities? For the very reason that nomadic identity was invented in the first place: redundancy. Safety. Always having a live backup. Resilience against servers shutting down or malfunctioning. It was invented because its inventor, the creator and then-still-maintainer of Friendica, kept seeing Friendica users lose everything whenever a Friendica node disappeared. And he understood that the only way to really make an identity resilient against server shutdown is for it to reside on at least two servers simultaneously.

If glasgow.social goes belly-up unexpectedly, you lose everything. Potentially forever. Good luck starting over from scratch.

If hub.netzgemeinde.eu goes belly-up, I lose nothing because I still have the identical clones, live, hot, bidirectional backups, on hub.hubzilla.de.

Tell you what: A while ago, hub.netzgemeinde.eu did go belly-up. The queue worker was so overloaded that the hub was bogged down. Nothing went in, nothing went out. Without a clone, I would have been fscked.

Luckily, I had my clone. I logged into hub.hubzilla.de and used my clone to a) do what I'd normally do on hub.netzgemeinde.eu and, especially, b) alert the admin who was on vacation. He and the Hubzilla lead developer ssh'd onto the server and fixed the issue. This might never have happened, hadn't I had that clone on another server.

So you could:
  • make a Crohn-related identity and clone it or not
  • make a Doctor Who fandom identity and clone it or not
  • make an activist identity and clone it or not
  • make a Web development-related identity and clone it or not

Oh, by the way: The aforementioned six identites may or may not be all of my Fediverse identities. I may or may not have more than these. You wouldn't be able to tell unless I told you.

CC: @ Johannes Ernst @Tim Chambers @ Ben Pate 🤘🏻

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Hubzilla # Streams # (streams) # NomadicIdentity

@jupiter_rowland@hub.netzgemeinde.eu @fedimemes_on_streams @jupiter_rowland@streams.elsmussols.net @juno_rowland I'm cool with this use case: already have numerous federated alt accounts. One from Bluesky bridge, one from Threads federated. Would be find to hae another on another server that was clearly a "backup account" but in a perfect world would bridge between each other.

@ RockManJoe Hahaha.

Tell you what: @ Mike Macgirvin ?️ has decentralised Fediverse identities as early as 2011. He invented nomadic identity (https://joinfediverse.wiki/Nomadic_identity, https://opennomad.net/page/nomad/home) almost five years before Mastodon was made. And he first implemented it in 2012 on what would later become Hubzilla (https://hubzilla.org, https://joinfediverse.wiki/Hubzilla). That was still almost four years before Mastodon was launched.

Oh, and by the way: Hubzilla is very much part of the Fediverse. It is very much (albeit optionally) connected to and federated with Mastodon. I am replying to you right now from a Hubzilla channel which simultaneously and identically resides on two independent servers.

Nomadic identity is reality now. It is being daily-driven right now, and it has been daily-driven since long before Solid was even announced.

Solid is nothing but Hubzilla or (streams) or Forte (both are descendants of Hubzilla by Hubzilla's creator) as ordered from wish.com. A cheap and shoddy knock-off.

CC: @ Johannes Ernst @Tim Chambers @ Ben Pate 🤘🏻

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

@ 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 @!{benpate@mastodon.social} rather than @[url=/@benpate%40mastodon.social]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

@evan @j12t @tchambers @benpate Yes, it’s easier than ever to BYOD. If you’re a nerd.

As a decentralization radical, I still fret about identity verification systems relying on DNS.

DNS is not a self-sovereign digital technology. My domain name can be revoked by governmental fiat.

More and more these days, I find that an unacceptable vulnerability.

@evan Bringing my own domain to somebody else who runs a multi-tenant server would be very nice indeed. I can bring my own domain to most e-mail providers and they will run e-mail for me at my domain, we should have the same here.

I want to do one better, though, which is mostly orthogonal to this: I want to go to lemmy.world and log in with @j12t and post, on that lemmy server, while being identified by that Mastodon-hosted identifier. Otherwise nobody knows it's me!

@tchambers @benpate

What I have in mind does not need protocol changes as far as I can tell. It needs OpenID-style SSO (Mastodon as the IdP, Lemmy as the RP in my example) into a local Lemmy account that can continue to have its own local identifier, but in the UX my Mastodon identifier is shown.

(I don't have a detailed proposal yet, but it sounds like it's possible, and right now I'm just floating a requirements to see whether anybody else agrees ...)

@evan @tchambers @benpate

@j12t @evan @tchambers @benpate I agree with this goal and I have a proof-of-concept of the OAuth2/OIDC part of this: https://codeberg.org/FenTiger/FedIAM

If you want to try it - you can log in to my demo Discourse instance using a Mastodon, Hubzilla or BlueSky account: https://discourse.mythik.co.uk/

I imagine this will work with Mastodon/Lemmy/etc as the RP, but I haven't done any work on the "how does posting work" part of it!

I like the principles behind this. Don't fully understand the details of it yet. Let's talk this through:

I visit Lemmy and sign in with my Mastodon account. I like a cat video. Does Lemmy use something like the C2S API to publish the activity via my Mastodon outbox?

Sounds doable.

It may require a common, more well-defined activity schema than we have today, so that each server knows what is being said.

@j12t @evan @tchambers

@benpate @evan @tchambers thats one way of doing that, and I would like to give credit to @mike from whom I heard that idea for the first time.

Another is to post to Lemmy which then publishes into the local actor’s feed, but with receivers showing the mastodon identifier instead — with a rel=me alias set backing up the equivalence. (There may be a few bumps, not entirely fully formed thought)

@j12t @benpate @evan @tchambers @mike I think it would be cool if there was a passkey-like way to give the end clients a way to sign as the same "user", and have the servers handle negotiating that,

e.g. if mastodon-android, pachli, tusky, toot, lemmy-android, etc all supported the same C2S import methodology or you could move keys around (or cross sign them)

((I know there's another migration proposal hanging around somewhere))

This would be a vast improvement to "FEP-3b86 Activity Intents" which is trying to improve inter-server UX without changing the protocols too much.

It would be a lot of new engineering for every project that wanted to participate, but worth the effort for sure.

We'd have to talk about how this works on mobile/desktop apps as well. So much Fediverse is happening OFF of the web, and it would be a shame to build a spec that gets this UX wrong.

@j12t @evan @tchambers

@j12t that sounds awesome and exactly what I want too. It's totally possible, seems kind of like how WebAuthn works with all the registration capabilities. I like to think of it as possibly a WebAuthn profile and the mastodon IDP being like a verified registered device. (Or I'd want to have a personal IDP on a domain I control logged into a mastodon profile to publish to)
Can be many scales of anonymity and validation/verification as needed.

@evan @tchambers @benpate

@mikedev
> explore the fediverse and find out what others developers are doing and have already done in this area

This ...

https://fediversity.site/item/9f514756-42b7-4e3d-9a5e-2561fae9c8ce

... could have been a really useful contribution to the discussion with about 90% less snark and links to examples. Here's a couple of good starting points for work on portable identity in AP;

https://wedistribute.org/2024/03/activitypub-nomadic-identity/

https://wedistribute.org/2024/03/extending-activitypub/

@j12t
@tchambers @benpate

@ Johannes Ernst The first step is already done:

Forte, @ Mike Macgirvin ?️ most recent project from the same family that started with Friendica 15 years ago, is the first and only stable Fediverse server application that uses ActivityPub for nomadic identity. Nomadic identity itself is a concept created by Mike in 2011 and first implemented by himself in 2012 in a very early version of Hubzilla which he called Red back then.

This means that you can have the exact same channel/identity (think Mastodon account, but without its own login) on multiple server instances with one account each. If one server goes down, you still have at least one clone (depending on how many clones you make).

@silverpill is working on implementing this on Mitra. It's still only available in development versions, though. The difference is that Mike had already created a whole bunch of Fediverse server applications with nomadic identity since 2012; he "only" had to port nomadic identity from the Zot or Nomad protocol to ActivityPub. Silverpill, on the other hand, has to implement nomadic identity in something that was built upon ActivityPub with no nomadic identity.

Both recognise each other's nomadic identities. (For comparison: Mastodon doesn't recognise any nomadic identities. It takes the two instances of this Hubzilla channel of mine for two fully separate identities.) But that's all for now.

The next step, and that's way into the future, would be to be able to clone from Forte to Mitra or from Mitra to Forte. This would give you one identity on at least two server instances of two separate Fediverse server applications.

The obvious downside is that you won't be able to take everything with you everywhere when you clone to other server types. For example, if you clone a Forte channel to Mitra, you won't be able to take your permissions settings, your permission roles, your friend zoom settings, the contents of your cloud storage, your CalDAV calendars and your CardDAV addressbook with you over to Mitra. That's simply because Mitra doesn't have any of these features.

What you envision is another step further. And that's the adoption of nomadic identity via ActivityPub and ideally also OpenWebAuth magic single sign-on, another one of Mike's creations, by all Fediverse server applications. And I mean all of them. Including extremely minimalist stuff like snac2 or GoToSocial. Including stuff that isn't actively being worked on like Plume. Including stuff that's dead, but that still has running servers, like Calckey, Firefish or /kbin. And including Mastodon which stubbornly refuses to make itself more compatible with the "competition" in the Fediverse and adopt technologies created by anyone else in the Fediverse, even more so if that someone is Mike Macgirvin.

In other words, this won't happen. Mastodon would rather turn itself into its own federated walled garden by becoming incompatible with all other ActivityPub implementations.

What many Mastodon users who know nothing about decentralisation wish for is another step further. And that's to create one account on one server instance of one Fediverse server software, no matter which, and then to have full-blown user permissions on any instance of any Fediverse server software.

Like, create one account on mastodon.social, go to a Pixelfed instance, post pictures Instagram-style, go to a PeerTube instance, upload videos, go to a WriteFreely instance, blog away, go to a Hubzilla hub, build a webpage, all with only your mastodon.social login.

Of course, this is impossible to do. This would mean that if you create an account on one Fediverse server instance, it would have to be cloned to all 30,000+ servers in the whole Fediverse instantaneously. And if you start your own instance, it would have to trigger 30,000+ servers to clone their tens of millions of accounts and channels over to your instance.

Usually, when I explain this to people who want to use everything with one login, they tell me that they don't want to use every server in the Fediverse. No, but they want to use any server in the Fediverse. Any one of the 30,000+.

And they want to use it immediately. Like, go there, use it with full-blown local user permissions right away, no delay.

Now you may argue that their account or channel could be cloned to that server when they visit it for the first time. Drive-by cloning, so-to-speak. Still, won't happen. Cloning takes time. I myself have cloned enough Hubzilla and (streams) channels over the years to be able to estimate just how long it takes. And none of my channels has ever contained tens of thousands of posts and thousands of pictures.

Besides, drive-by cloning would inflate Fediverse instances senselessly, not to mention bog them down with extra network traffic. Whenever you visit a Fediverse server instance for whichever reason (like, you want to look at a post on Friendica or Hubzilla to see what it looks like without being botched by Mastodon), your account or channel would automagically be cloned to that server instance. Another account (and channel, if necessary) on that server instance, another deluge of posts and files flooding into the database, and that clone would have to be synced with your 600 other previous drive-by clones on the 600 Fediverse server instances you've visited before.

Extra nefarious: Some "websites" that have to do with Hubzilla or a certain aspect of Hubzilla are parts of Hubzilla channels themselves. This includes the official Hubzilla website. If you visited them, you'd create a drive-by clone on the Hubzilla hub which hosts that website.

So if someone set up a single-user Hubzilla hub with their personal channel and a website channel on it, and the website is interesting enough, and 10,000 Fediverse users visit it, it'll end up bigger than the biggest current Hubzilla hub within days. It'll have 10,001 accounts, namely the owner's account with two channels and 10,000 accounts with drive-by clones, automatically created by the 10,000 external visitors.

But this will remain utopic not only because it's technologically pretty much impossible and very much not feasible at all. It also requires a mechanism for one Fediverse server to recognise logins on other Fediverse servers. You know, like OpenWebAuth. You want your Mastodon account to drive-by clone itself, Mastodon will have to implement OpenWebAuth, and I mean fully implement it.

There actually is a pull request in Mastodon's GitHub code repository that would have implemented client-side OpenWebAuth support (= Hubzilla, (streams) and Forte would recognise Mastodon logins). This isn't even about full-support that'd include login recognition on Mastodon's own side. This pull request has been there for two years. It was never merged. And it probably will never be merged.

This means that the Mastodon devs have practically rejected OpenWebAuth as a feature to implement. Won't come. Ever. Not even half of it.

And this should say everything about the chances that Mastodon will ever implement nomadic identity.

CC: @ william.maggos @ Richard MacManus @Tim Chambers @ Ben Pate 🤘🏻

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

I'd love to know more about what you're thinking here.

I don't think we're replacing #Webfinger. I think we're trying to follow through on #WhatCorySaid at #FediForum (https://www.youtube.com/watch?v=7_Gs1t0qe78)

...which is basically: Let regular people take their account to a new server any time they want, without relying on awful XML/CSV import/export jobs. This would go a long way to solving Fediverse UX issues and preventing enshitification.

Is there more that I've missed?

@mro @j12t @tchambers

Hi @benpate @j12t @tchambers,
oh, I see. I thought of near instant and frequent nomadic moves without a host-based identity. (Don't know why)

What do you think #WhatCorySaid @pluralistic means with "their account" - all interactions ever? With or without a time machine at hand?

Ask a sci-fi author and get a solution based on time machines. grr.

@j12t @ricmac @tchambers @benpate

but doesn't the ID live somewhere? I'd worry the people running those services eventually exert power...

I think we need servers based on locality with a shared set of proven rules most of those kinds of servers can adopt. and that server software needs to handle what most people want to do. most personal accounts are on one of these.

but of course this requires breaking out of the dedicated app/server concept we brought over from the corporate world.

There was a great concept that came up at #FediForum - the identity of Theseus.

Perhaps it's okay if we have MANY identities, so long as we can reliably bind them together. Imagine rel=me links on angeldust.

Servers might come and go, but my identity straddles all of them (somehow, TBD) in a way that can be unified at the UX level by other servers.

Sean mentioned this in his article:
https://deadsuperhero.com/my-dream-fediverse-platform/

@j12t @wjmaggos @ricmac @tchambers@deadsuperhero

@j12t @ricmac @tchambers
@benpate

I'd love for this to happen but we're also stuck in the stage of replicating corporate platforms, instead of thinking about what we can do that they can't.

#ghost and #wordpress are doing this by making the article an AP item, instead of linking to it from a post. Maybe lemmy and mastodon should merge. most people don't post videos so maybe they don't need a #peertube account. maybe it should function more like podcasts. same with #funkwhale and #bandwagon.

My unpopular opinion: I love making decentralized clones of corporate tech.

Historically, innovation happens in startups who take a risk and break new ground. So, let them figure out the costly product/market fit. OSS products ALWAYS lag behind the corporates.

We just need to 1) copy them one-by-one 2) expand their value prop with the unique advantages of an open, federated network of millions of existing users, 3) win fair-and-square in the marketplace.

@wjmaggos @j12t @ricmac @tchambers

I love this article, and can't wait for Part 2. It is right in line with https://deadsuperhero.com/my-dream-fediverse-platform/

I've been getting started on a UX hit list for #Emissary but there's only so many words I can type in one day. Perhaps we can chat once you've put your thoughts into the next blog post?

@j12t @tchambers@deadsuperhero