4 ms·

> I'm using branle (https://branle.fiatjaf.com/ https://branle.fiatjaf.com/) as my client and you can follow me with my pubkey: 22e804d26ed16b68db5259e78449e96d

> I'm using branle (https://branle.fiatjaf.com/ https://branle.fiatjaf.com/) as my client and you can follow me with my pubkey: 22e804d26ed16b68db5259e78449e96dab5d464c8f470bda3eb1a70467f2c793. It isn't too hard to improve upon the status quo in various ways when you just drop a key usability requirement (in this case, the need for human-memorable 'handles'). It is worth reading 'Why Johnny Can't Encrypt' (1999) [0], 'Why Johnny Still Can't Encrypt' (2011) [1], and 'Why Johnny Still, Still Can't Encrypt' (2015) [2]. [0] https://www.usenix.org/legacy/events/sec99/full_papers/whitten/whitten_html/index.html https://www.usenix.org/legacy/events/sec99/full_papers/whitt... [1] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.227.7902&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22... [2] https://arxiv.org/abs/1510.08555 https://arxiv.org/abs/1510.08555

vidarh 5y ago
That's true, but you can disconnect those requirements on the server side. E.g. a "name/profile to key/value" service would be useful for more than this. If people want mastodon style handles, for example, it's easy enough to create a mapping that can leverage DNS for example to let you query for a matching pubkey in a cacheable and easily scalable way and without the need for that to be built into the messaging protocol.
- webmaven 5y ago
  > That's true, but you can disconnect those requirements on the server side. > E.g. a "name/profile to key/value" service would be useful for more than this. At which point you've reintroduced a global namespace SPOF that is vulnerable to censorship, etc. You can push the complexity around like food on a plate, but getting rid of it is another matter entirely.
  - fiatjaf 5y ago
    No, you don't. You can have DNS-based aliases to pubkeys, and then people will follow pubkeys and interact with pubkeys, not with the DNS aliases. So if these users are censored later from the DNS then they still keep their identity, their contacts, their followers etc.
    - pseudozach 5y ago
      You could even deterministically map pubkeys to handles with something like bip39. it won't be pretty but it will be unique, human-readable and uncensorable.
    - webmaven 5y ago
      That's kind of like saying that people don't interact with domain names, but with IP addresses. The point of having the mapping of a name to a key is for users to use it in place of the underlying key in their interactions with the system.
      - vidarh 5y ago
        Missing the point, which is that the lookup doesn't need to function or be available for anyone but the person composing the message at the time they compose it. It can be entirely private, entirely public, or a mix. What gets transmitted is the pubkey. Optionally the relay can provide a mapping, which may be globally consistent or entirely based in some private mapping. Users just need a catalog which includes the keys of people they care about. The relays can backfill this information. You have little reason to know mappings for users whose messages you're not seeing, and if the messages are not censored the mappings won't be either.
      - fiatjaf 5y ago
        The analogy would be valid if IP addresses were permanent and DNS was only consulted once -- and then communication between these two parties was done directly through the IP forever.
  - vidarh 5y ago
    That's only true if you choose to introduce a global namespace. There's nothing requiring you to have just a single such catalog of users as long as the canonical reference is the pubkey any more than the contact list on my phone requires you to name people the same on your phone. (and in fact on reading the protocol specs, they do have a way for relays to publish mappings [1] . EDIT: and that would seem to make it possible for crawlers to crawl relays to assemble non-canonical catalogs fairly easily). There are downsides to having multiple namespaces, such as e.g. that there's no guarantee that your client will be able to map a given pubkey back to a human-readable name and/or dealing with collisions between mappings from different sources, of course, but this is reasonably well thread ground. [1] https://github.com/fiatjaf/nostr/blob/master/nips/02.md https://github.com/fiatjaf/nostr/blob/master/nips/02.md
    - webmaven 5y ago
      Sure, you can have multiple namespaces, and each would have to be censored, but that's about as difficult as playing whack-a-mole with multiple domains pointed at an IP address.
      - vidarh 5y ago
        If you can censor the catalogs you can censor the relays. Not least because the protocols allows the relays to serve up catalogs of name to pubkey mappings. Having this lookup functionality makes no difference at all to the ability to censor. If you have an issue with the censorship resistance of this you have an issue with the core concept of this project. That's fine. But it's entirely independent of whether or not you provide a lookup mechanism for names.
swalsh 5y ago
the eth guys have solved this with ENS, you could add your public key address in your ens record if this ever becomes a thing. Then you just tell people to add me <myname>.eth
upofadown 5y ago
YJCE identified a lack of usable concepts as the root problem. Human-memorable 'handles' actually make things worse in that they add in another concept that the user has to learn about and understand. The idea that the ridiculously large number represents a human identity is very easy to comprehend and the user can not avoid contact with that number in a system like this. The number is the identity. Usability and convenience are two different things. A system that is difficult to use might be easily understood by the user and vice versa.

vidarh 5y ago

That's true, but you can disconnect those requirements on the server side. E.g. a "name/profile to key/value" service would be useful for more than this. If people want mastodon style handles, for example, it's easy enough to create a mapping that can leverage DNS for example to let you query for a matching pubkey in a cacheable and easily scalable way and without the need for that to be built into the messaging protocol.

webmaven 5y ago
> That's true, but you can disconnect those requirements on the server side. > E.g. a "name/profile to key/value" service would be useful for more than this. At which point you've reintroduced a global namespace SPOF that is vulnerable to censorship, etc. You can push the complexity around like food on a plate, but getting rid of it is another matter entirely.
- fiatjaf 5y ago
  No, you don't. You can have DNS-based aliases to pubkeys, and then people will follow pubkeys and interact with pubkeys, not with the DNS aliases. So if these users are censored later from the DNS then they still keep their identity, their contacts, their followers etc.
  - pseudozach 5y ago
    You could even deterministically map pubkeys to handles with something like bip39. it won't be pretty but it will be unique, human-readable and uncensorable.
  - webmaven 5y ago
    That's kind of like saying that people don't interact with domain names, but with IP addresses. The point of having the mapping of a name to a key is for users to use it in place of the underlying key in their interactions with the system.
    - vidarh 5y ago
      Missing the point, which is that the lookup doesn't need to function or be available for anyone but the person composing the message at the time they compose it. It can be entirely private, entirely public, or a mix. What gets transmitted is the pubkey. Optionally the relay can provide a mapping, which may be globally consistent or entirely based in some private mapping. Users just need a catalog which includes the keys of people they care about. The relays can backfill this information. You have little reason to know mappings for users whose messages you're not seeing, and if the messages are not censored the mappings won't be either.
    - fiatjaf 5y ago
      The analogy would be valid if IP addresses were permanent and DNS was only consulted once -- and then communication between these two parties was done directly through the IP forever.
- vidarh 5y ago
  That's only true if you choose to introduce a global namespace. There's nothing requiring you to have just a single such catalog of users as long as the canonical reference is the pubkey any more than the contact list on my phone requires you to name people the same on your phone. (and in fact on reading the protocol specs, they do have a way for relays to publish mappings [1] . EDIT: and that would seem to make it possible for crawlers to crawl relays to assemble non-canonical catalogs fairly easily). There are downsides to having multiple namespaces, such as e.g. that there's no guarantee that your client will be able to map a given pubkey back to a human-readable name and/or dealing with collisions between mappings from different sources, of course, but this is reasonably well thread ground. [1] https://github.com/fiatjaf/nostr/blob/master/nips/02.md https://github.com/fiatjaf/nostr/blob/master/nips/02.md
  - webmaven 5y ago
    Sure, you can have multiple namespaces, and each would have to be censored, but that's about as difficult as playing whack-a-mole with multiple domains pointed at an IP address.
    - vidarh 5y ago
      If you can censor the catalogs you can censor the relays. Not least because the protocols allows the relays to serve up catalogs of name to pubkey mappings. Having this lookup functionality makes no difference at all to the ability to censor. If you have an issue with the censorship resistance of this you have an issue with the core concept of this project. That's fine. But it's entirely independent of whether or not you provide a lookup mechanism for names.

swalsh 5y ago

the eth guys have solved this with ENS, you could add your public key address in your ens record if this ever becomes a thing. Then you just tell people to add me <myname>.eth

upofadown 5y ago

YJCE identified a lack of usable concepts as the root problem. Human-memorable 'handles' actually make things worse in that they add in another concept that the user has to learn about and understand. The idea that the ridiculously large number represents a human identity is very easy to comprehend and the user can not avoid contact with that number in a system like this. The number is the identity. Usability and convenience are two different things. A system that is difficult to use might be easily understood by the user and vice versa.