Nostr Web Client

why haven’t more clients implemented the gossip model? nostr:note19hm09s5dzf0dfmdtt2atlkp22mfz234xh3t3qkz7fx6n2st3fcysspwpht

Colby Serpa 1y ago

Putting one or two relays in a note that’s stored on a ton of other relays is nice for discovery (this is the gossip model), but it’s imperfect…

It’d really be wonderful if you could put your list of relays on-chain, so everyone could easily lookup what relays your notes are currently on.

It wouldn’t be as expensive as paying a transaction fee for every new post, since it’d just be a fee each time you update your relay list… but block space is still the limiting bottleneck.

Nevertheless, it’s either blocks or a DHT for finding what relays belong to a given npub. But DHTs have their own set of trade-offs…

What I’d really like… and am putting off until GitNestr is ready… is a way for a relay to signify all the users/npubs it hosts data for & compact that into a ZKP that the relay puts on-chain.

This way anyone could scroll through these ZKPs on-chain to see if a given npub’s posts are stored on any of those relays — it offsets the transaction fees to the relays.

Trade-offs everywhere, but I know we’ll find new ways… the more options the better.

Reply to this note

Please Login to reply.

Discussion

Colby Serpa 1y ago

All of these methods have something in common — they flip the discovery model on its head, similar to gossip:

Read posts from the relays other users write to, instead of only reading from the list of relays you write to. 👀

petri 1y ago

You got to store your NIP-05 data somewhere. Why not put the relay list there, too?

Colby Serpa 1y ago

True, though that’s a bit more centralized albeit possible.

Mazin 1y ago

Actually in the original/current NIP-05 spec but was ditched. https://github.com/nostr-protocol/nips/blob/master/05.md

petri 1y ago

Can be improved like you can have alt DNS servers. Just a matter of definition. Could be just file-hash pointers but there needs to be some point of entry to start the query.

Colby Serpa 1y ago

Hmm what about NIP-05 with decentralized DNS? I think ZeroSync will enable that on bitcoin without needing to be a full-node, but we could test it with namecoin in the meantime.

The relay IP hosting the NIP-05 data can be updated on-chain. When you connect to it, you download the user’s list of currently selected relays.

A user could put this decentralized DNS in all their notes. Could even have two or three decentralized DNSes and put all of them in every note you post.

Downside is the user has to buy the domain and pay to update the IP when needed, but it does feel more intuitive at least.

DanConwayDev 1y ago

What's wrong with using blaster for relay list replacable events per the gossip model? Why the need for on-chain data?

Colby Serpa 1y ago

The issue is relying on relays to propagate your NIP-65 note to ALL other relays. It might not propagate to ALL of them if you’re just trusting it to propagate. Negentropy with interval-based syncing will help though, which were coding in Go.

The blockchain OTOH is the ultimate central repository (that’s ultimately decentralized) that any relay can use to check which relays you’re committed to.

I think Gossip is a great start that doesn’t use on-chain data. Just saying, if we want to take it farther there’s a way to do it without needing to pay on-chain fees everytime you post. The blockchain is valuable if it can be made cheap for users.

Ronin 1y ago

It should be with dvms, a client would request to find an npub and it's relays. A client could also post a specific kind of note to a group of relays asking to find an npub, and a dvm or relays could answer that note with a answer, a bit like nsec bunker.