Saw an article this morning noting that movement of users from #Twitter to alternatives is dropping off now. When it came to a discussion of #Mastodon, it noted specifically the issue of having to research and choose an instance to get started, noting that most people wanting to leave Twitter want to do so quickly with as few additional decisions required as possible. Of course, there are many people here who clearly don't *want* folks from Twitter easily "contaminating" their ecosystem here. And I will continue to speak out against this view.
@lauren and to finalise my three part reply!
Choosing an instance on Mastodon, placed me immediately in a community of interest. I had immediate engagement that was at least somewhat relevant, unlike in twitter where I was just having stuff shoved at me by algorithm.
I think there's actually an advantage in requiring people to choose an instance, or at least, putting a roadblock, albeit an easily bypassable one, that encourages people to choose an instance of interest before joining
/3
@techlife I've heard this so many times. And I still view it as an essentially narrow and selfish view. Period.
@lauren I'm not clear which specific point I made that you are replying to? I'd like to know what's selfish about anything I said, if you are willing to elucidate.
Btw by putting a roadblock, I wasn't suggesting forcing people to have to choose an instance (though I'm curious how it is decided what instance they join if they don't have a choice).
I'm talking about having as part of the sign up, a screen that explains the advantage of choosing a relevant instance, that user can "skip"
@techlife The instance choosing part is the biggest roadblock. I haven't had time to write up a document on this, so I can only refer you for now to my many posts on this topic here, which I wish I had a good way to index ...
There is the annoying conflation of (at least) two things that an instance is: identity provider and community. If we could decouple those at least somewhat, one could imagine a setup where one could be a member of many instances. In that world instance choice is much easier ("identity provider" is not important ~at all, "community" is postponeable).
@lauren @robryk I have argued for this in other posts, to make movement between federated platforms much more portable.
My layman's grasp of activitypub (I'm experienced in IT, networking etc but not specifically about activitypub) there's no baked in decentralised user management. I guess I see something like tor network for authentication.
Not something we'll get quickly even with the will. But it's vital, I believe, and for similar reasons as you Lauren, that it does become a thing.
> I guess I see something like tor network for authentication.
I don't understand how. Tor establishes short-lived circuits. There are (by intent!) no long-term identities anywhere.
You might with to take a look at Secure Scuttlebutt. It implements the "hand the user a private key" approach.
So, whatever you do, the duality from my original comment applies: you either need global consensus (in the meaning of https://en.wikipedia.org/wiki/Consensus_(computer_science)), or identifiers can't be freely chosen. (Otherwise you could impersonate a user by "just happening" to choose the identifier they are using. Preventing that is ~equivalent[1] to consensus.)
[1] "~" because I haven't thought enough to prove it
I don't know what bitchain in; based on 30s on Google it seems to be Yet Another blockchain thingy. I will assume so below.
You might wish to take a look at namecoin, which is (was?) an attempt at doing DNS that way.
Note that blockchains don't magically solve consensus. They provide solutions under additional assumptions of a very weird shape (PoW ones' assumption is ~"no one can acquire as much as a third of the computational power we are burning", PoS ones' assumption is ~"no one can acquire a third of the tokens we are keeping track of ownership of").
@robryk @lauren While you want your cryptocurrency wallet to be anonymous, if it was the container for a user account, you'd be using it to ID yourself on the network and you'd want to reveal the name of your wallet. Social network platforms could trust the content of the wallet (your ID) for the same reason recipients of crypto trust the coin you are transferring to them.
I'm an extreme novice in most of this. So happy to be educated why or if I'm wrong. Just trying to learn myself
Can you try expressing what you are saying using lower-level primitives? For example, can you rephrase this without talking about a "user account"?
Failing to follow my own advice, an interesting difference is that the "coin" "exists" beforehand and just changes the "owner", whereas a "user account" would be created out of thin air.
@robryk @lauren yep that's fair I'm not being very precise. User account = identifier ak wallet name. User profile = wallet content.
Doesn't need to be blockchain. Loginradius talk about it https://blog.loginradius.com/identity/what-is-decentralized-authentication/
Also IBM are talking about it. I expect if those companies have hope, the skepticism you have expressed about the possibility of decentralised authentication at least isn't shared by other people also with knowledge on the subject.
A quick skim of what they're suggesting shows that it's a setup where identity is longer lived than handles attached to it. Identity is of the "please hold onto this private key" kind. Handle-to-identity mapping is provided by otherwise authenticated organisations, who can revoke and reassign handles at will. So, organisation from whose namespace a handle is can repoint it however it pleases.
One interesting thing is that they seem to ask for some cert-transparency-style logs of handle-to-identity assignments, so that changes of those are necessarily publicly visible. (So, the expectation changes from "handles cannot be stolen/impersonated" to "stealing/impersonation of handles is auditable".)
You might be interested in how keybase's identity model works. It's remarkably similar to this one.
@robryk @lauren yeah that's still not completely free of a third party. The instance you choose could be in control of the namespace (user@instance) just as it is now. So it's not completely non reliant on the instance management. But your ID can be transferred to another instance. Which gives the portability. The network just needs to recognise changes in domain.
I'll keep reading up on this. But in lieu of complete decentralised auth, anything that allows the ID to be portable is a plus
> The network just needs to recognise changes in domain.
Try to figure out how that could happen (who trusts whom to make what statement). I don't think you get any stronger portability that what you have right now with old instance saying "this fellow is now foo@bar".
BTW. I've been only talking about authentication so far, but routing is an issue that also needs to be solved. I think that (as long as you actually want not terribly weak integrity guarantees) routing is simpler, and we have a couple of ways to do that in a distributed fashion (-> DHT, the most well-known example thereof being the thing that backs magnet links in BitTorrrent).
@robryk not my preference hence holding out for hope in decentralised auth. I mean in absence of that, I have to trust someone right?
Note that the "your handle is a public key" setup exists, is well, and is used in some places. If handles are to be choosable and global:
Not everything is possible. Regardless of how many people are working on it, I will strongly doubt that e.g. they can accelerate something to more than speed of light.
I don't want to say that it's surely an unsolvable problem, because it's too poorly defined to assert anything like that. However, I doubt that a formalization of that problem that's close enough to be still subjectively considered the same problem is solvable. I expect that we'll use something that either doesn't have global chooseable handles or that adds some very strong assumption.
@robryk @lauren is an intermediate system possible? For example authentication via blockchain (or other decentralised authentication method), where usernames are chosen on the basis of handle+serverinstance (as handles are currently crafted on mastodon). Then each server only has to manage the uniqueness of the ID within their own user base.
@lauren @robryk I'm not actually a fan of using blockchain. I just mentioned it as one possible avenue for decentralised authentication and the convo got side tracked onto that. Happy to keep blockchain out of it. I'm actually looking more towards nee technologies developed specifically for decentralised auth. Not repurposing other technologies.
@robryk @lauren hesitate to mention, but bitchain maybe? Like a bitchain wallet but for users.