Hacker News Reader

I dug into Nostr this week. IMHO, these are some of my engineering concerns.

- User accounts are tightly coupled to a single key. There's currently no account abstraction.

- Nostr is tightly coupled to a specific crypto primitive and doesn't attempt any sort of crypto agility.

- The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md)

> - The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md)

DNS is not centralized, it is distributed. A name server can delegate authority to other servers. Every nation has their own, which I consider sufficient decentralization. (Although it does rely on IANA to list addresses of root name servers, which is perhaps the centralization you refer to)

Do you propose another naming system?

DNS is centrally controlled by ICANN.

There are alternatives like ENS. I don't mind Nostr just simply having its own system.

DNS is both.

There are the universally accepted root servers, ICANN, national registrars, etc.

But nothing prevents you from trusting additional root servers, with TLDs if your choice, delegation of subdomains from them, etc. All the standard mechanisms will just work. Your router likely supports the .lan TLD out if the box.

DNS tne protocol supports alternate root servers.

DNS the system that we all depend on depends on the assumption that we all use the ICANN root servers.

ENS can definitely be used. The DNS thing is just one hacky way to put meaningful names on keys, but other hacky ways are not excluded.

At the top, sure, but our machines have their own DNS so we could get around the ICANN DNS servers if we told our machines to do so. Is that what ENS is?

One of the first applications of blockchains was DNS. (Namecoin) ENS is a modern form. (https://ens.domains)

I would say there's still some degree of centrality for ENS, but it is more decentralized than DNS.

I’ve built a Nostr relay from scratch to learn the protocol and while there are some odd quirks, the fact that it’s maximally simple and the core spec can be understood in 5-10 minutes has way more value than you may immediately realize. It lowers the barrier to entry for builders substantially.

I also had a similar experience. I’ve built a handful of little things that speak nostr over the past month just to get a feel for it.

Time-to-grok is fast and then you’re off to the races building.

I never even bothered to build anything on ActivityPub because the minimum bar is much higher.

> The protocol doesn't define a transport but seem to use WebSockets.

The protocol transport is over WebSockets.

> How does it handle poor/dropping connections?

The way HTTP underneath it handles poor/dropping connections. It is request-response like HTTP, there isn't state to recover, just try again.

> Does it allow usage of alternate transport protocols?

If you think it is useful, write a NIP for it.

> Messages are defined as JSON but doesn't use much of its structure anyway. Some fields are just arrays of values. And even then some parts are just strings with some other arbitrary syntax. Seems like a poor choice.

Being readable is helpful for debugging. I agree there is less structure than could be used, but it is well-defined and libraries can more strongly type the data and name the fields, for example. One thing you can't easily do is go back and change the protocol, that would create far too much complexity.

> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?

The part that is signed is defined well enough that at least dozens (probably near a hundred now) coding implementations are inter-operating on this without issue. Is the definition formal and rigid enough to ensure nobody misinterprets it? Probably not. I've had to ask for clarification and when I got it, I put in a PR to change the NIP. It was accepted right away.

It is not XMPP. Have you read the XMPP RFCs? I couldn't even get through the table of contents of the first one. The guiding principle of nostr is that it is the simplest protocol that has a chance of working.

> It's unclear how to preserve/port data. A relay is supposed to keep (or not) messages and the client is supposed to send messages to multiple relays. But what happens when a relay goes down? Can a client send messages to a new relay? Should the client keep all messages just for such a case?

https://www.nostr.how/relays "If all the relays that you have used in the past go offline, all your posts will be unretrievable. This is one reason that Nostr allows users to connect to many relays – this ensures some degree of backup. That said, if you're really interested in being uncensorable, you can run your own personal relay."

So clearly, relays are retaining copies of your data. The question is really storage capacity: if nostr becomes popular, will individual relays have enough storage capacity for all of its users?

I’m really confused as to why they’re called relays. As it is now they’re not relaying anything. They’re just a default server/client.

I think relays should scale horizontally, meaning relays should become topic-based, geography-based, etc.

Also, I also don’t think relays are under the obligation to store notes forever. Part of scaling horizontally is hosting your own long term storage (or pay a provider to do that for you).

If a relay needs to scale vertically, they could start charging for access or do data mining+ad injection, all kinds of stuff to monetize.

One of the writers of the NIPs posted this earlier today:

> Other relay ideas (not very good, just to sparkle your imagination):

- a relay only for people with top-level domain names (no "@" at the NIP-05)

- a relay that only stores the most recent post of people

- a relay that only stores posts that have received at least 10 replies from other people (big threads)

- a relay that only serves posts to people having $X tag on their profile metadata

How does client decide which relay to send a message to?

Those relay ideas seem like the whole new level of screaming into the void. It doesn’t sit well with me that not only there’s no promise of saving my data but rather ideas of not keeping my data for me are floated around as a normal thing.

For this to happen clients will have to build this into the UI. I’ve got a work in progress concept for one client [0]. Basically let a user create arbitrary relay groups. When posting the user can choose which groups to post to. Users can then filter their feeds to specific relay groups.

[0] https://github.com/monlovesmango/astral/pull/93

> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?

Systems I've seen (and written) that do this use deterministic serialization algorithms that sort keys and do other things standard, general-purpose implementations don't. The implementations in core libraries, browsers, and the like tend to be faster, but the payloads being signed in the apps usually aren't that large.

Taking a look at NIP-01, the serialized data that gets hashed and signed is a flat array, not an object. So no sorting of keys here. I don’t think any json serializer would change the order of items in an array, right?

https://github.com/nostr-protocol/nips/blob/master/01.md

That's true but there's still plenty of room for incompatibility. JSON doesn't put any requirements on floats precision, for instance. Another example is that any character may be escaped (that's in the RFC, literally, verbatim) so while it's recommended to use UTF-8 for serialization a random lib can decide that ASCII is the way and escape all your emojis. To be fair, NIP-01 specifies that it has to be UTF-8 but no mention of float precision can be found. I'm almost certain these two are not the only ways a JSON can be divergent while still being valid.

And I have to point out that we're doomed to repeat our mistakes. XML is also very flexible. And people wanted to sign XML documents and they found this to be a problem. So they came up with Canonical XML form — a way to remove some of that flexibility to make sure it's possible to reliably derive a stable variant that can be signed and verified. Unfortunately, we haven't came up with Canonical JSON yet. But maybe we will soon.

Canonical JSON has a IETF RFC: https://datatracker.ietf.org/doc/rfc8785/

> Can a client send messages to a new relay?

Yes, a user can transmit a previously created note to a new relay at any time.