- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
In response to Bray’s toot, Evan Prodromou — one of the creators of ActivityPub, who is currently writing an O’Reilly book about the protocol — noted that this “is also the argument for using the ActivityPub API.” He described the API as “an open, extensible API that can handle any kind of activity type — not just short text.”
This gets to the nub of the issue. The fact that I can’t use my Mastodon identity to, for example, sign up to Pixelfed is not actually an ActivityPub issue — it’s because the two applications, Mastodon and Pixelfed, each require you to create an account on their respective products. What Prodromou is suggesting is that, technically, you can use the ActivityPub API for account access.
Nothing about this idea implies centralization. There is no reason identity has to be tied to the platform using the identity and no reason why there needs to be a central identity store.
In fact, right now my identity IS centralized to lemmy.world and I have no control over that.
Your solution to create as many identities as you want is great for avoiding having one identity, but not an example of decentralized identity.
I would like to be able to have multiple, decentralized, identities.
It’s a single identity that would be used to log in to all relevant sites. How is that not “centralized?”
The reason I prefer that is that then that identity is specific and limited - it’s not me on all sites, but just me on that site. Me on another site is an entirely separate identity.
But with this, there is, for all intents and purposes, a central identity “store.” That’s how it would work - I provide whatever ID is used as a trigger and then the site would access “my” “store.” And presumably that would be an ongoing process, since another of the things that’s being floated is the ability to essentially federate all of my content across instances.
And all of that is going to have to be hosted somewhere, and if I don’t use my own hardware, then it’s going to be hosted on someone else’s hardware, and that means that they - not I - ultimately have control over it. Sure, they can promise that I maintain full control, but that can, as has happened far too many times in the history of the internet, just be a lie.
Granted that that’s the case currently too, again, it’s decentralized. Each individual instance just has control over my identity on that instance - not over my identity fediverse-wide.
Only your lemmy.world identity, which isn’t you.
Is that the part I’m missing? I still don’t understand what the supposed problem is in the first place. Is it that you feel that your lemmy.world identity is in fact “you?” Like that particular online identity is identical to your actual real world self, so not being able to use one and only one identity throughout the fediverse is existentially unsettling?
I’m still trying, and failing, to understand how this is a supposed problem in the first place.
Anyway, only your lemmy.world identity is (by a stretch of the term) “centralized,” and only to lemmy.world, and I guess to whoever it federates with. But that’s not you - that’s just one internet handle, for one site.
And the worst that can happen is that lemmy.world does something shady, in which case you can just create another identity at another site. And that last, as I understand it, was always the central point of decentralization - to make it so that harm that might be done was limited to only the one instance on which it was done, and couldn’t permanently harm the broader fediverse or an individual’s access to it.
Having one central identity though means that any harm done to or through that identity is done throughout the fediverse, and to the affected individual on all instances. That seems like a recipe for trouble, and seems to be directly contrary to the ideal of decentralization.
How is it not? My identity on the fediverse is spread around multiple accounts on multiple instances. That’s about as “decentralized” as it gets.
Yes - each identity is tied to a specific instance, so can be said to be “central” to that instance, but again, all that means is that that one instance can potentially cause me harm on that one instance. The rest of my identities are out of their control.
So with this single identity scheme, imagine that it’s somehow compromised or violated or held for ransome or whatever. That affects every single individual account I have throughout the fediverse. While with the way I currently do things, all it could ever do is affect the one account I have on one instance, and dealing with it would be just as easy as avoiding or closing that account. All the rest of my accounts, and my fediverse access broadly, would remain entirely unaffected.
How is that not the better alternative, and much more to the point, more in keeping with the ideal of decentralization?
Imagine if login was a federated feature in lemmy.
What this would mean is that I could go to lemmy.ml and login using my lemmy.world account credentials and people from lemmy.ml could go to lemmy.world and log in using theirs.
Neither could go to beehaw and login because it does not federate with the two of them.
In this world I could create an identity on lemmy.world and a separate identity on lemmy.ml if I wanted to.
Now imagine if I could login with my lemmy.world account on a non lemmy platform that lemmy.world federates with.
There’s nothing centralized about this, and it is exactly in the spirit of everything else in the fediverse. To login on beehaw I would have to create an identity on beehaw or someone they federate with.
What you seem to be against is forcing you to have only one login. That does go against the model we are talking about.
And it isn’t what’s being suggested.
Yes - that isn’t what’s being suggested. And that’s entirely irrelevant.
The correct way to measure the threat a proposal poses isn’t by what’s specifically being proposed, but by what the proposal, if enacted, carries with it - what it necessitates, implies or even just allows.
As I mentioned before, and this seems to me to be the biggest potential threat vector, unless people host their identities on their own hardware, that information is going to be on someone else’s hardware. And that’s not going to be a charity - it’s going to be a business, that’s going to profit off of it somehow. If this proposal goes through and is relatively widely adopted, there will one day be an industry leader in the identity-hosting business, and that company will have leverage over the fediverse as a whole. And at that point it would be easy enough for them to, for instance, strike a deal with the biggest instances so that the instances, in the name of security or convenience or whatever might suffice, only accept registrations through that particular service.
I’m not saying that that will happen - only that it could. And that’s enough, in my estimation, to make it a bad idea, because if the history of the internet has shown us anything, it’s that if there’s a way for someone to control something and profit off of it, someone will control it and profit off of it, and the original proposal that made that possible doesn’t mean a damned thing.
You are describing the current situation in the fediverse, not a problem caused by the idea proposed.
Allowing for federated identity would also imply allowing migration of identity, which wholly prevents what you just described.
The current system is guaranteed to have larger instances where people won’t want to leave because doing so abandons your identity.
If I could move around the fediverse freely I would do so, but that is not a feature that is supported so I stick to the largest instance which happens to be the one I chose. I am not unique in this. Obviously, or this instance wouldn’t be so large.
Offering federated identity is only a better situation than today.
No, it’s not the same.
You’re only describing what would happen at the instance level, and skipping over the fact that the whole thing hinges on your identity on each and every instance actually being one and only one identity that would reside in one particular place. It would actually exist on, and be federated from, one particular server somewhere.
What that means, and the part you’re leaving out, is that whoever controlled that server would control your access to the fediverse as a whole - not just on one particular instance, which is the reality with instance-specific identities, but on all instances of all services.
The only way to avoid putting control over your access to the fediverse as a whole in the hands of one company would be to maintain your server on your own hardware, and as the article itself notes, most people can’t or won’t do that. So most people will end up with their identity on all instances of all services under the control of one specific company. Which is very much NOT the case now.
Now, if someone wants to somehow use their control over my fediverse access for some self-serving purpose - either maliciously or simply as a goad with which to extract profit from me - they’re necessarily limited to one identity on one instance of one service because that’s as high as it goes. They might, for instance, hijack or disable or demand a subscription fee for access to my .world identity, which resides on .world’s server. All that would mean to me though is that that one particular identity on that one particular instance would be compromised. I could still access the fediverse, and even access .world, just by coming in through my kbin identity or my lemm.ee identity or my .ml identity or whatever, since all of those are out of their control.
With this scheme, if someone wants to use their control over my fediverse access for some self-serving purpose, they have one specific place to do it - at the one specific server on which my identity is hosted and from which my identity is federated. With one move, they could hijack or disable or restrict extort payment for my access to ALL instances of ALL services, all at once.
Again, that is very much NOT the case today.