You can find my pubring on my bio after following me. There's no ability to discover others at this time!
Nostr relay registry hosted here (https://nostr-registry.netlify.app) by fiatjaf.
Exciting times!
You can find my pubring on my bio after following me. There's no ability to discover others at this time!
Nostr relay registry hosted here (https://nostr-registry.netlify.app) by fiatjaf.
Exciting times!
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/whitt...
[1] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22...
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.
> 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.
(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.
That's fine. But it's entirely independent of whether or not you provide a lookup mechanism for names.
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.
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.
Usability and convenience are two different things. A system that is difficult to use might be easily understood by the user and vice versa.
it's not obvious to me though how you find people to follow.