[ScottEvtuch]

I'm curious about the decision to make team names globally unique and unchangeable. It obviously has some trust benefits in that you can't spoof a team if you know the name, but shouldn't the proof of legitimacy be in the membership and signature chain, not the name?

If Keybase popularity grows, then any sufficiently large company will probably have to use "CompanyName-Corp" or something equally vague as their team name would be taken by squatters. A malicious user could invite someone to "CompanyName-Corporate" and most users probably wouldn't even notice.

[malgorithms]

There are so many conveniences around a global team name. Any time we played through the mental exercise of ambiguous names, it led us back to the deep pains of reading out loud security codes or fingerprints, or relying on some kind of hard-to-use web of trust around trusting people and then their vouching for teams. (note people, too, have unique names.)

With our testers, I've already had so many conversations about team names. If it's an in-person conversation it's validated entirely without looking anything up. If it's digital over an alternative medium - then the sharer doesn't have to go look up their team's identifier in order to talk about it. Everything is easier.

Also, I'm not that cynical by nature, but I've had a lot of conversations with people about security since we started Keybase. People don't check codes. From encrypted chats to SSH server fingerprints (ugg!) -- people don't check them. If a team name can be equivalent to one, but the cost is that the space is limited, it's worth it.

I guess in summary: why is a name better than a fingerprint? It can be memorized without effort. It can be visually or verbally reviewed without effort. And it often has meaning.

[rcthompson]

> [A name] can be visually or verbally reviewed without effort.

Have you considered the possibility of typo-squatting, look-alike Unicode characters, and other such tricks (basically all the same tricks people use for domain names)?

[another-dave]

One option could have been to use top-level domains for a team (e.g. add a TXT record to prove ownership of 'example.com' and then you can create that the 'example.com' team).

Out of interest, is there a reason you didn't go for that? Would be easy to memorise and validate while also ensuring uniqueness. Feels like it could also play in quite nicely with letting people on-board — e.g. you could have a feature that anyone with an email address in my domain is allowed to join the main team without needing admin approval.

That said, this sounds great — can't wait to try it out :)

[azag0]

Potentially, they could still roll this out, because a dot, ".", is currently not an allowed character in a team name.

[chias]

That's because it's used to designate sub-team (e.g. companyname.infosec is a sub-team to companyname)

[tokenizerrr]

And how will you deal with squatting? I am looking forward to holding all the popular names hostage.

[Deadolus]

Seems like they limit the number of teams you can create [per user] to 101. I guess it's the same dilemma as with domain names again.

[gregmac]

Requiring the team name to be a domain name (validating that they own said domain name) seems like it would be a reasonable solution. Domains are already globally unique, already tied to organization identity, and already closely related to anything keys will be used for (software, e-mail, etc).

Someone could still spoof "companyname-corp.com" but then it's at least obvious in the same way spoofed URLs already (usually) are.

[james_pm]

Domain names as identity is something I would love to see happen, mostly because I have a vested interesting in selling millions of people those domain names via Hover.com

Keybase does a nice job aggregating those various identities, be it a domain name, Twitter handle, HackerNews ID. It's probably a better solution to help people/businesses establish an interconnected series of online identities that are provably the same entity.

ps. Thanks to Chris for reserving some of the more common team names including hover and making sure we could get our hands on it.

[proactivesvcs]

What if neither Alice nor Bob have a domain name? What happens if the domain name is dropped, transferred to a third party, suffers a dispute etc?

[zokier]

Keybase could just offer free subdomains from a domain owned by Keybase for people who don't have their own domains.

[alexeldeib]

This actually seems like a remarkably elegant solution to the above problem. I'm hesitant to make it domain linkable though. A cool kind of solution to ambiguity would be a graph network, say "join team X with members X,Y" to identify the team uniquely. And that is referenced to the people you're linked to on keybase, and the groups they're in. If a group by the same name exists with the same named people, it shouldn't be picked over the correct group, and if it were, you would be rejected from joining the team.

[LeoPanthera]

What happens if you forget to renew your domain name, or someone steals it by the trademark rules? Would that person then gain access to your encrypted chat?

[WorldMaker]

If it's just a pointer to a merkle root for the admin chain then they don't get access to the encrypted chat, they'd still have to request access from an existing user.

You could simulate that today by say creating a weird named team (say random GUID), adding a text file like .well-known/keybase-team.txt on the domain with that team name, and then encouraging people to sign up via something like:

    keybase request-access `http GET http://example.com/.well-known/keybase-team.txt`