I think Jon was just trying to provide some information on the spectrum of possible identity solutions one can choose from. At Hypothes.is, it's extremely unlikely we would try to do anything like this. However, it does represent a form of "verified pseudonymous" identity, in which your uniqueness as an entity is verified by a central authority, but that identity is never exposed. See my comment below for more information about what we might actually implement.

This reply still seems to indicate a fundamental misunderstanding of multifaceted identity. The fact that i am one physical person should be irrelevant to a reputation service. If I have one identity that I use to post jokes on reddit and another identity that I use to post serious content, those identities should have different reputations. What I do with one should not affect the other. My uniqueness should not have to be verified, the only thing that should matter towards my reputation is what the persona I am currently acting as has done before.

Yes. I totally agree. I would certainly love to support multiple distinct personas. There is an open question of how to do that while mitigating the damage potential. There are also cases where multiple personas might usefully be linked. For example, when commenting on programming issues you might want to link your persona to your stackoverflow identity or your HN account. Honestly, the biggest mistake I could make would be to assume I know what the community wants before we have a community. I think it's probably wise to err on the side of less friction and more prismatic identity and deal with restricting multiple signups if/when we need to. For now I plan to enforce uniqueness for outside identities (only one pseudonym per Twitter account) but also allow a basic reCAPTCHA username/password signup. If someone wants to contribute code to manage multiple personas within one account that would be fabulous, but annotation functionality feels more priority for me. If you think there's still a fundamental misunderstanding please continue, but I totally agree with your comment and don't think there's anything about it that's incompatible with my current vision.

Thanks for the clarification. But the concern remains that a single "central authority", namely hypothes.is, gets to maintain a huge database that links online pseudonyms to verified real-world identities. That's going to make hypothes.is one hell of a target, not only for identity thieves but also for government authorities of all stripes. Meanwhile you'll need to convince people that they should trust you with that information.

Sure, any large online identity provider that possesses enough data to link online identities to real-world identities (such as Facebook) will face the same problem. If this takes off, Chinese hackers will be crawling under your mattress and your PO Box will be overflowing with subpoenas and national security letters before you can say eff-bee-eye. But ideally I'd like to see this problem fixed in some creative way, not merely repeated and exacerbated in a centralized form.

Honestly, I have no idea how one might achieve both verification and pseudonymity without cutting corners somewhere else. But I do have some hope for you guys because it seems that EFF is involved. Those people really know how to play with pseudonyms.

/tinfoil hat

Thanks! Wherever possible I'd like to ditch the personal information after signup and just keep a hash or something that we can use to prevent multiple accounts using the same Twitter, OpenID, etc, linking only these opaque tokens to user IDs in our database. I'm trying to put together our user tables and login system in the next day or so and welcome any comments or concerns you have with the implementation. Feel free to jump into our dev list or #hypothes.is on Freenode.

That raises an interesting question. How are you going to hash a person's Twitter username or OpenID in such a way that (1) you can quickly determine if the same person tries to sign up more than once using the same credentials, and (2) the original credentials are effectively discarded?

If you just store something like sha1(openid), it will be easy to check for duplicates, but any staff, intruder, or three-letter agency that wants to connect hypothes.is accounts with OpenID's can also easily launch a dictionary attack. On the other hand, if you store something like bcrypt(salt | openid), it will be a lot of hassle to check for duplicates, and your database is still susceptible to a known-plaintext attack. In neither case have you actually irrecoverably discarded the personal information. And thus we get back to the problem of South Korean web sites requesting National ID numbers from every member. They only claim to use it to prevent multiple signups, but then they wonder why every Chinese hacker has easy access to millions of South Korean National ID numbers.

Meanwhile, nothing prevents a determined spammer from creating multiple Google (for OpenID) or Twitter accounts. So if I had a suggestion, it would be that you should stop wasting time trying to enforce one account per person, and instead give people an incentive to minimize the number of accounts they create. Make it dead easy for people to associate different accounts on different services with any of their personas, and make it dead easy for people to organize and manage them, so that most people don't even feel the need to create additional accounts.

Feel like using your joke personality on Reddit today? Just select that persona in a dropdown menu in the browser add-on bar. Wanna switch to your serious account for just one comment? Another click in the menu and you're automatically logged in as the other user. (Reddit Enhancement Suite can already do something like this, which means there's a demand for this feature.) Different example: I sometimes want to log into Gmail with one Google account while browsing YouTube with another Google account. Right now, this means messing with incognito windows. If each tab were pinned to a different persona, I could do this just as easily as flipping Chris Poole's prism in my palm.

BTW, sorry for the wall of text.

I started thinking about the dictionary attacks, too, and ultimately you're right. Not worth enforcing and easy dropdown changing is eventually what we want. Thanks for your thoughts.