social
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social] [briar-devel] Fwd: GNU/social legacy


From: Melvin Carvalho
Subject: Re: [Social] [briar-devel] Fwd: GNU/social legacy
Date: Thu, 13 Dec 2012 12:24:53 +0100



On 13 December 2012 09:32, Michael Rogers <address@hidden> wrote:
Hi Hellekin,

> Tg (from the Secushare project) commented recently that he "doesn't have any issue with the identifier being the hash of a public key, as long as the UI can alias it to something meaningful for the user, such as address@hidden" I tend to agree with that statement. Dereferencing a unique key is not out of scope.

We've run into a similar issue with Briar pseudonyms and I'd be interested to hear your thoughts.

When a message is posted to a group, it may be received by people who don't know the author. The author may sign the message with a private key, in which case we can treat the public key as a pseudonym. Pseudonyms would allow authors to establish personas and reputations without revealing their offline identities. But how should pseudonyms be displayed to the reader? Public key hashes are unwieldy and unmemorable, so it would be nice if pseudonyms could have a friendly form - perhaps something like a chat nick (I agree that the email address format is already overloaded).

But here we run up against Zooko's triangle: if we allow authors to choose their own nicks, we can't enforce uniqueness. If "Subcomandante Alice" becomes a trusted persona, anyone can create a pseudonym with the same nick to cause disruption; the only people who'll spot the difference will be those who compare the (unwieldy, unmemorable) key hashes (and understand what a key hash is).

On the other hand, if we allow readers to assign nicks to pseudonyms purely for their own use, it becomes tricky to refer to nicks within the group conversation: I can't meaningfully tell you "I prefer Subcomandante Alice's take on this issue" if I'm the only one who calls her by that nick.

So I suspect we need something between the two: allow authors to suggest their preferred nicks, while making it clear to readers that pseudonyms are unique but nicks aren't.

Any thoughts on how to achieve that?

Dont you have the same problem in real life?  You call someone "Tim" and that works until you have a large room with two people called Tim in it.  Then you may need Tim A and Tim B, or firstname / lastname

What's key here in the digital paradigm is that an identifier is simply a string.  You can use local identifiers in a local context, but as things scale you need a wider context.  The ultimate solution to this is to have a URI to identify.  The URI can be linked to the local identifier too and http is an easy method of doing this.

There are URI schemes such as di: which stands for digest.  This can be a hash of a public key for example.  GPG uses hex_id. 

Best of all worlds, on my homepage (which i use as identity) I have my URI my GPG key, my exponent and modulus, my hex_id, my nicknames, my full name, my avatar and links to my friends. 

Obviously @tim as an id is not going to scale globally, but if you tie together the local id and the universal id you can use the string in the right context, and importantly both machines/systems and humans can benefit from robust naming.
 

Cheers,
Michael


reply via email to

[Prev in Thread] Current Thread [Next in Thread]