The handle namespace issue is weighing on me. Having one global namespace with unique names is going to create some difficult dynamics. Landgrabs will be a nightmare. If people are selling handles, we’ve done something wrong. The trademark issues will be challenging too.
LinkedIn doesn’t do handles. They do names, and they don’t worry about uniqueness. If you see two people with the same name, you differentiate by looking at their profiles and their networks. In our universe, we have a ton of social data and could also add verification authorities to do checkmarks, etc. We have options that are better than “whoever claims this name first wins”. Similarly, we learn from Adam Langley’s pond app that the solution here is to steer users toward pet names and try not to lean on an individual’s assertion of their own name.
All this leaves aside the mess that would be trademark issues. The domain name space spent a long time coming up with rules on squatting and it took new legislation to really address it. I don’t think we want to end up there, so we should avoid creating a situation where everybody is competing for one limited namespace.
I might even go so far as to cap the number of names in any one namespace. This will force some decentralization and prevent a primary namespace (a la .com). Forcing decentralization in this way is a lesson we learn from the pump.io folks.
All of this adds up to one thing: we should think about how to decentralize handles just like we do everything else!
LinkedIn does have a form of a unique handle, it is just not very obvious. It is your vanity url. However they are not very prominent. I bring that up to wonder if our handles are/could be more like that, simple helpful identifiers, but not all that important?
Additional namespaces just recreate the problem at a different level, just you have the question of if those namespaces are owned. Wouldn’t that get us back into the same problems of lack of user control over their handles?
One of the large questions handles are designed to assist with is the issue of reverse lookups. How do we safely go from a wallet address to a DSNP Id? By design we do not control the logic of the identity delegation contracts, so a wallet address may be added without the owner of that wallet address’s permission. That means that it could be easy to spoof a reverse lookup. Human selected handles help with this (although granted create other issues).
I could see perhaps creating (semi) random namespaces… I’ll have to think about that. Imagine if we have [selected username].[random non-selected chars or numbers?]. That way there would always be a name. That said randomness is hard to find for a smart contract.
If handles are not all that important, maybe it’s ok if they’re not owned by the user. Maybe a handle is just how we get to your DSNP Id if we don’t know each other. Once we’re connected, your client should know my DNSP Id and let you refer to me by a pet name. If I switch handles tomorrow, my existing contacts shouldn’t even notice. New contacts will get to me via my new handle. People with stale handle info will not reach me. Or maybe my old handle can continue to work for a while. Maybe a user can have multiple handles that all point to the same DNSP Id.
I think I don’t understand the flows around the wallet well enough yet to answer this. I’ll keep working on it!
Notes from today’s group video-chat discussion on handles (human-readable names) and namespaces:
(Denise Duncan, Christina Hwang, Wil Wade, Chris Chen, Heather Finney, Rose Karr, TJ Thomsen, Scott Bendar, Harry Evans, Max Jenkins, James Vasile, Karl Fogel.)
Karl made these notes. Attribution is a bit inconsistent, because I didn’t always record who said what – my apologies to those (Harry) who said substantive things that are mostly reflected below but not attributed. Also, the block where I said something is misleading large; that’s just because I have the most detailed memory of what I said.
Rose led off with overview of the current registry discussion, about a specification for a registry contract to associate a handle with the user’s GUID.
Problems of centralized registry
If there is a centralized registry enforcing uniqueness of handles, then we have the usual land-rush problem (which, to be fair, can incentivize early user engagement, at least to the extent of a person creating an account, but that would be fairly low-value engagement and may not be something we want to encourage). Enforced uniqueness also has the problem of being (warning: possible editorial bias from the note-taker), well, centralized.
James: multiple namespaces
Would be great to have a way to have multiple namespaces, to take some of the pressure off. Imagine if DNS TLD only had “.com”, for example. Actually, we don’t have to imagine it, since in the early days everyone acted like “.com” was all that mattered and name contention was indeed frequent. With more TLDs today, there’s less pressure.
“Pet names” may also be part of any solution. A pet name is what you call me: it’s determined by you, not me, and its usage may be private to you. E.g., the Contacts database on your phone is your list of pet names for your contacts. The fact that they often match up with the names other people use for those same contacts is natural and not coincidental, but it’s also not enforced in any way by the system.
Wil: user sovereignty
“How do I know that you’re you and how do you know that I’m me?” is the key question. Problem with the human-lookup case is that you could in theory have two users that look exactly identical except for a few machine-readable differences (e.g., different GUID, different contract, and that one little piece of code that says I control this identity instead of you controlling it). “User sovereignty problem”.
James and others: DNS as a fallback
We discussed DNS as a fallback identity resolver. Rose pointed out that it’s still centralized. (Karl didn’t have a chance to say this in the meeting, but notes here that, after all, anyone can choose what DNS root servers they want to listen to, it’s just that in practice people usually choose the same set as everyone else.)
Karl: “user sovereignty” vs “social sovereignty”
“Ownership” may be a somewhat distorting lens through which to look at identity in DSNP. A person has their self-claimed identity, and then there are socially-affirmed identities for that person, which sometimes only partially overlap with the self-claimed identity (and for that matter with each other).
This is why Twitter has the blue-checkmark verified identity thing, but note that Twitter doesn’t enable its users – that is, all of us, not the particular account holder in question – to subscribe to different identity verifiers. Twitter could enable that, but chooses not to because it’s a centralized social network. But DSNP is a decentralized social network and should be thinking about social affirmation processes, as allowing different identity affirmation services (chosen by the identity consumers, not by the identity claimers) may be a key ingredient of being decentralized.
This implies that handles need not be unique. The underlying GUID would be the only unique thing. If two users both want to claim to be “CNN”, well, there are a lot of affirmations / endorsements the actual Cable News Network corporation will have that a faker won’t have.
Idea of services offering automated confirmation. Someone claims to be so-and-so @ gmail, and gmail can automatically confirm that. (Think Keybase.io, but with a smoother and less user-involved affirmation process.)
Wil: Non-user-originated revocation
What happens if an identity affirmer takes it away? Like you handed out business cards that say “jrandom@example.com”, and then the owners of example.com take away your email account (and even give it to someone else)?
This is a perfectly plausible real-world situation already, and DSNP doesn’t necessarily have to solve it, but we need to think about it.
Overview of options / solutions discussed
More namespaces
Less prominence to handles, more to display names (which can overlap)
Pet names
Independent verification services (e.g., Keybase-style services, and services provided by iDSPs like Google/Gmail). The identity-consuming user, not the identity-originating user, chooses the service(s) they want to use.
Non-uniqueness of handles, and letting “the market” sort it out (scare quotes deliberate but not necessarily ironic).
Care: For betanet, we want/need an underlying GUID per “user” that is divorced from the chain for migration needs
Contract addresses are GUIDs, but they are not predictable and would require translating any connection data when migrating chains (such as to mainnet).
GUIDs can be given out through a single smart contract (centralized, but “ownerless”) and do not need to access the same space as contracts. Thus the GUID can be a mere 64 bits of data vs 160 bits of data (a space savings of 60% per GUID reference).
Care: Frontrunning Handles
While not discussed above, it is a worry that user handles could be snipped by actors watching the mempool.
ENS resolves this issue through auctions instead of claims, but that takes time and money.
Is there something I can read on frontrunning handles?
Is there a slide or other resource on the current scheme? I think I need to see how handle, GUID, registry, DNSP id, and contract address all relate. A slide on handle registration and then one on reverse lookup would be ideal.
Tentative assertion: We’ll never have a system in which fraud and fakery are impossible. Names in the non-digital world have never been fraud-proof either, after all. However, we can have a system in which:
There are numerous mechanisms available, at various levels, to combat fraud and fakery;
The degree of fraud-resistance is proportional to the effort invested through those mechanisms.
That investment should roughly balance between the discoveree and the discoverer, right? (Real question, not rhetorical.) That is, the more effort you put in to making your identity imposter-resistant, the less effort other people have to put in when verifying your identity.
This would match how identity works in practice already. For example, American Express does a lot of things to prove who they are so that you can do less work to verify them when dealing with them. Similarly, I’ve done some up-front work at keybase.io/kfogel so that you can do less work to verify me when you need to. Now, in both of these examples some semi-esoteric knowledge was needed to make the up-front investment. In DSNP, with help from service providers, the mechanisms can be less esoteric – something anyone can do, with help from a good UI, though there will still be complex privacy tradeoffs (since social-graph affirmation inevitably involves privacy tradeoffs).
IMHO we shouldn’t start from the assumption that handles are unique, nor that they’re permanent & unchangeable, nor that a given GUID has only one handle mapping to it at a given time. Note that ditching uniqueness greatly reduces the motivation to do frontrunning (and reduces the land-grab problem similarly).
@wil I actually don’t know what “user sovereignty” means in this context. Can you describe/define it? (For the record, I did look in the glossary.)
