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 I agree about servers but I disagree about domain names. Domains are extremely easy and cheap to get, but our fediverse software mostly doesn't let you bring your own domain. I think it would be a lot better to work on BYOD for Fediverse software or even start a new hosted service that lets you BYOD.

@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

@Johannes Ernst You would still need write permission to lemmy.world's local database. For that, a local user account on lemmy.world would be a hard requirement. Local actions saved in a Lemmy database cannot reference a user in a database on a wholly different server running under a wholly different domain.

This would require
  • nomadic identity both on Mastodon and Lemmy so your j12t.social identity can have a local representation (= "clone") on lemmy.world
  • OpenWebAuth magic single sign-on, implemented on Mastodon at least client-side (will never come; there's an actual PR on Mastodon's GitHub which has never been merged, and which can be regarded as silently rejected) and on Lemmy at least server-side, in order for lemmy.world to recognise your j12t.social login
  • a clone of your j12t.social identity on lemmy.world that's created
    • either "drive-by" when you visit lemmy.world for the first time
    • or before you visit lemmy.world for the first time
A clone before your visit sounds more practical, but it's non-sense. It simply isn't doable. How is your Mastodon instance supposed to know before the fact which Fediverse servers you want to visit and interact with like with a local account?

"Drive-by cloning" during your first visit is more doable. But cloning takes time. And I'm talking from personal experience here. I myself have cloned a number of Hubzilla and (streams) channels over the years. It always took quite a bit of time to sync all the contents from one server to the other one. And none of them were even nearly as active as your Mastodon account.

Granted, cloning from Mastodon to Lemmy would be quick because Mastodon and Lemmy have next to nothing in common. Lemmy would have no use for your toots, for your images, for your followers and followed.

But let's suppose I post a (non-federating) article, I advertise it in a federating post, and it sounds interesting to you. Then you'll have to come over to hub.netzgemeinde.eu to read it because, again, the actual article doesn't federate to your Mastodon timeline. Upon visiting hub.netzgemeinde.eu, j12t.social would automatically register a local user account on hub.netzgemeinde.eu and then clone your entire Mastodon account into a Hubzilla channel. And I mean pretty much all of it. This would take considerable time.

Also, drive-by cloning would have quite a few other disadvantages.

In particular, it would bog Fediverse instances down. Anyone who visits them would have their account or channel drive-by-cloned. Every Fediverse instance would have a clone of each visitor's account or channel. With all their posts and comments and DMs and all their files on it. And these clones would be sync'd with their main instances all the time.

This would also mean the end of tiny, self-hosted single-user servers like yours. Everyone who even only goes check your Mastodon profile locally on your server (and on some Fediverse server applications, that's the only way, for there's no viewing remote profiles locally) would have their account or channel drive-by-cloned.

If your account is popular enough, you'd end up with maybe tens of thousands of local user accounts with clones of other people's Fediverse identities, with all their posts and comments and DMs, with all their images and other files. And j12t.social would be pelted with nomadic syncs of all these identities all the time.

You want to use any Fediverse server like with a local account, but with your j12t.social identity? Then grant everyone else the same wish. And order a big honkin' rack server for your single-user server because it won't stay single-user for long.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Lemmy #Hubzilla #OpenWebAuth #SingleSignOn #NomadicIdentity
Zot, Nomad, and Nomadic Identity in the Fediverse