- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
Mike Macgirvin, the long-time developer that brought us Friendica, Hubzilla, Streams, and the Zot protocol, is bringing his most powerful concept to the rest of the Fediverse: Nomadic Identity.
IMO, this seems exactly what the fediverse needs to thrive. The whole “choose a server” thing is a big disincentive to adoption by most people.
That’s not exactly what nomadic identity is about, although it can also help with that.
The way nomadic identity is implemented in Hubzilla for example is that you can have accounts on multiple servers and by importing a shared cryptographic identity into all of them, other servers know to treat them as a single entity. Once that is established you can log into your account on any of the linked servers and use it normally. But if a server goes down or you decide to delete your account on one, you can seamlessly continue to use everything from another linked server.
This article was the first time I understood that particular way of implementing nomadic identity, and it’s the first time I’ve felt genuinely excited by the idea.
My concern is that with “instanceless” nomadic identity on the fediverse is that ultimately, it would mean that instance would lose their sense of differentiation and community, and would simply be infrastructure instead, and that’s how we we end up with bluesky.
This implementation though is amazing. It lets people actively lean in to community based instances, without having to only pick one, and it gives people protection against loss of any particular instance.
Indeed I am also slightly weary of too easy account migration. Not only do instances lose character because of it, but also are much more likely to be shut down or abandoned if it can be justified with easy account migration. The instance I am currently on for example would probably not exist anymore had not the previous admin felt the need to hand it over to someone else.
But in the bigger picture I think Hubzilla’s nomadic identity is a good compromise of balancing out these different considerations.
Super disagree. A community at the protocol level can have just as much character as a community at the network level, but without most of the drawbacks. The “instance as community” idea was always a poor substitute for actual
Groups. The community shouldn’t be a server that users are bound to; it should be aGroupthat has access controls and private memberships (if desired). The moderators get all the same benefits of maintaining a limited community with their own rules, but users aren’t beholden to petty drama via instance blocks or defederation.That’s one way to look at it, sure. But it fails to account for community dynamics. The fediverse is largely run by volunteers and funded by that small percentage of users that feel strongly committed to their particular instance. If you break that up you end up with only a few large and likely advertisement funded instances being able to survive.
This is also why I doubt Bluesky federation will be ever anything but a novelty for some self-hosters.
I’m not saying I don’t think instances should be able to use that model, only that I think that model should not be the dominant way of building a community on the fediverse. But I don’t see why a user would be less attached to a community just because its hosted on a different server from them, especially on the threadiverse which is topic based and where users are most likely going to engage in multiple topics.
I think another way to look at it is that accounts are tightly coupled to instances, to the point of being a detriment. I’ve personally lost all of my data and had to start over from scratch 5 or 6 times due to servers suddenly going down over the years.
Groups are one way to abstract community functions up a level, and what’s crazy is that Group Actors themselves could also have a similar thing. People have talked about merged cross-instance communities on Lemmy; this would be one way of enabling that.
That makes total sense. Still, it removes the pressure of choosing a server, since migration and use of several servers becomes seamless. As it is right now, there’s the resilience and future lifespan of an instance to consider, plus fragmentation of your identify as defined not by your username but by your actual “online persona” constructed from your posts, etc. (unless you’re really going for alts, of course). You can create other identities on other instances but they are separate, you “lose” your posts, etc. if something happens. if I understood correctly, that becomes less of an issue with nomadic identity?
Super cool, the worry of an instance dying will make people avoid smaller instances and pick the big stable ones. Having this safety net should help balance things out.
I wonder if this could work with threadiverse communities. We’ve seen communities disappear when an instance goes down. Could the communities also be saved like this?
I don’t see why not. And in fact, they would benefit from the whole relay thing, allowing multiple accounts on different instances to be the “same” community
That could be an improvement over following 3 or 4 identically named communities on different instances
It wouldn’t change that, unless the moderators of those communities agreed to merge them by using the same cryptographic identity.
Personally I like that there are different communities with different characters, but the option for community moderators to opt into such a nomadic arrangement would certainly not hurt. At least it is much better than if 3rd parties like clients or alternative implementations like Piedfed smash them together with currently no way for communities to opt out of that.