[Retr0id]

I dipped my toes into nostr recently, and I was struck by the fact that content on nostr does not have a canonical location. IIUC, you have to know which relay(s) have what you're looking for, and if you don't, you just have to guess. Ostensibly this is a win for censorship-resistance, but it doesn't seem very practical to me.

Has this caused you any issues with your projects?

[treyd]

That's in-line with my general criticism of Nostr. It's a very simple protocol that imposes too little structure on downstream software so you get a kind of impedance mismatch (so to speak) at the messaging layer. There's not a lot provided for ensuring reliable delivery so the strategy will evolve to just broadcast to as many relays as possible and accept the duplicated effort (which will have to be paid for by somebody). It also doesn't have a good story with regard to identity management and key compromise. It's neat and useful for some applications but people think it's some amazing new advancement when it's not. Its something very simple that we could have easily invented in the 90s, but we didn't because it's kinda a shaky architecture to build applications on top of. It's too simple.

[ibz]

Indeed, too many people think Nostr will somehow magically solve everything... I think of it just like RSS on steroids - which is why I even mentioned it in this thread.

[ibz]

This is indeed one of the issues I still didn't fully wrap my head around!

Currently clients just use the same bunch of relays as defaults, and let you (maybe) customize the relays you want to connect to.

I think this is sub-optimal for another reason, besides the one you mentioned (discoverability?): you don't necessarily control where your data is stored, and these relays might disappear without notice. It is a great way to broadcast status updates, but not great for having an archive of your own data, that you can trust.

I assume this will change eventually, with paid relays, which will have the incentive to keep your data around, OR personal relays - which is what I am building as part of my CMS - basically I want all my data to have one "canonical" location (my domain) and be hosted on my VPS, which also serves my data as a web page with RSS... this helps me wrap my head around where my data is stored, and know that I always have a copy of it... but doesn't solve the discoverability issue, I guess, which ... IDK, it seems to be solved using just a "shotgun" approach: mostly publishing to well know relays.

[KoftaBob]

See my comment here explaining how Nostr aims to solve this: https://news.ycombinator.com/item?id=38346741

[janandonly]

I would love to read/hear more about this NOSTR based CMS. Do you have a website or nostr channel I can follow to hear about a alpha/beta launch date?

[ibz]

Just a GitHub. [1]

It's very early days still, but I use it myself.

The marketplace [2] is much more advanced! You can already use it to buy and sell stuff over Nostr!

[1] https://github.com/servuscms/servus [2] https://github.com/PlebeianTech/plebeian-market

[KoftaBob]

> IIUC, you have to know which relay(s) have what you're looking for, and if you don't, you just have to guess.

This problem is tackled by an improvement to the protocol that was recently introduced called "NIP-65": https://github.com/nostr-protocol/nips/blob/master/65.md

The TLDR is that when a Nostr client supports NIP-65, it broadcasts to all known relays (which is continually updated/expanded) the list of relays that User A posts their stuff to.

This means that as long as User B is connected to at least one of those "all known relays", their client now knows what relays User A posts their stuff to, and will specifically fetch things from those relays when it needs to load User A's things.

It's essentially the Nostr take on the Gossip protocol: https://en.wikipedia.org/wiki/Gossip_protocol