7 ms·

I read everything there and all NIPs (they look like underage RFCs, but also drunk) and I'm a little confused. - The protocol doesn't define a transport but se

I read everything there and all NIPs (they look like underage RFCs, but also drunk) and I'm a little confused. - The protocol doesn't define a transport but seem to use WebSockets. How does it handle poor/dropping connections? Does it allow usage of alternate transport protocols? - 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. - Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled? - Messages are just sent around without any delivery confirmation. There's a NIP to introduce delivery confirmation from the client to relay. And then there's another NIP to signal completion of messages retrieval from the relay. Both are optional. - 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? Overall feeling after reading all that is it's XMPP but worse. It's worse defined. It's not quite decentralised as there's a single point of failure: relay. And it's unspecified how to handle demise of a relay and port data to another relay. Signing and encryption is nice but message structure makes me feel dirty. XMPP wasn't inititally meant for a decentralised public messaging but there are a few XEPs that do exactly that, as well as signing and E2E encryption. And all other good stuff like BOSH (XMPP over HTTP), for example.

lapcat 4y ago
> 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 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?
- leesalminen 4y ago
  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
  - pointlessone 4y ago
    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.
    - leesalminen 4y ago
      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 https://github.com/monlovesmango/astral/pull/93
- Aeolun 4y ago
  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.
leesalminen 4y ago
> 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.
Zamicol 4y ago
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 https://github.com/nostr-protocol/nips/blob/master/05.md)
- evv 4y ago
  > - The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md 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?
  - Zamicol 4y ago
    DNS is centrally controlled by ICANN. There are alternatives like ENS. I don't mind Nostr just simply having its own system.
    - fiatjaf 4y ago
      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.
    - nine_k 4y ago
      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.
leishman 4y ago
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.
- leesalminen 4y ago
  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.
kemitchell 4y ago
> 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.
- leesalminen 4y ago
  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 https://github.com/nostr-protocol/nips/blob/master/01.md
  - pointlessone 4y ago
    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.
    - toomim 4y ago
      Canonical JSON has a IETF RFC: https://datatracker.ietf.org/doc/rfc8785/ https://datatracker.ietf.org/doc/rfc8785/
anothernostrich 4y ago
> 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.

lapcat 4y ago

> 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 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?

leesalminen 4y ago
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
- pointlessone 4y ago
  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.
  - leesalminen 4y ago
    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 https://github.com/monlovesmango/astral/pull/93
Aeolun 4y ago
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.

leesalminen 4y ago

> 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.

Zamicol 4y ago

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 https://github.com/nostr-protocol/nips/blob/master/05.md)

evv 4y ago
> - The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md 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?
- Zamicol 4y ago
  DNS is centrally controlled by ICANN. There are alternatives like ENS. I don't mind Nostr just simply having its own system.
  - fiatjaf 4y ago
    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.
  - nine_k 4y ago
    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.

leishman 4y ago

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.

leesalminen 4y ago
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.

kemitchell 4y ago

> 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.

leesalminen 4y ago
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 https://github.com/nostr-protocol/nips/blob/master/01.md
- pointlessone 4y ago
  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.
  - toomim 4y ago
    Canonical JSON has a IETF RFC: https://datatracker.ietf.org/doc/rfc8785/ https://datatracker.ietf.org/doc/rfc8785/

anothernostrich 4y ago

> 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.