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?
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
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.
Yes, a user can transmit a previously created note to a new relay at any time.
- 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)
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?
There are alternatives like ENS. I don't mind Nostr just simply having its own system.
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 the system that we all depend on depends on the assumption that we all use the ICANN root servers.
I would say there's still some degree of centrality for ENS, but it is more decentralized than DNS.
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.
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.
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.
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.
- 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.