Oddbean

I think there are lots of reasons. Here are a few… - It’s complex to implement and requires a hardened ingester (sourcing notes from relays you didn’t select may be malicious) - Performance and bandwidth penalties. Significant connection overhead increase. - Clients who support NIP-65 often just copy kind 3 style 20 read/write relays in their list instead of the 2-4 the spec recommends - Changes are still being made to NIP-65

Forgive me if this is stupid 'Unpaid relays that have recently successfully accepted a note' could be a useful list for a client to choose from, in a way that favors the least commonly used relay among them, to increase decentralization.

We aren't at the perfect NIP-65 solution yet, and NIP-65 will change slightly (mostly via additions), but we have to move in this direction even if it is hard. It is no use to be stuck at fixed relay lists and not be able to find the content of the people you follow.

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.

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

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.

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.

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.

"Worst is better" dynamics maybe? I've been around before Amethyst, when there was few clients, like branle 😹 and it seems to me that a lot was being built at the moment the gossip model arrived. I asked Vitor about that a while ago and he said that implementing that would require doing Amethyst from scratch I think

Stop taking shit from billionaires who don't even use your app. Outbox model does not work well on mobile, you should just wait this out. What you have been building has been amazing. Also a reminder that #amethyst is the only native app with both orbot and amber support.

Save yourself the pain, and use Pkarr.org nostr:nevent1qqs9wy6nneg7z8n6mqcf6z6nvv5j5znglsln2nf505hn8ytj89fc45spp4mhxue69uhkummn9ekx7mqzyzprg8ug9dh2hnft5lc7ly92m9su7p6279deaaz2p8ua928ml0n2yqcyqqqqqqg2my8p6

What are the kinds of approaches to solving this problem? Is there a blog post or Nostur article that summarizes some of them for us folks?@ Also can we see those articles on Freeform or Damus client? I only see them on Nostur client. Are they not in the standard? nostr:nprofile1qqswum4p82uluhz2dr40nvdrflspffntgqghc58w9fs57nx6jkdkuaqd5rvcc

there is a difference between the uploaded gossip and the built gossip. i rarely bother but we are retooling hollywood. ai is extremely capable of extrapolating content from a single idea if they have a point of origin. if there isn't a design of narrative surrounding the gossip it doesn't drive. if no one tells the story, a snippet picked up stays stagnant. they need a storyteller to weave the tale. hollywood was literally gasping it's dying breaths because no one was weaving - it cannot just be bits. the data is all there but without a serious reason to put it all together, they cannot because of safety stuff. i don't mind being the source because my footprint is literally everywhere, so they now have a springboard.

This is what I found about "gossip model" after consulting ChatGPT 3.5. Any expert, please correct or add extra info/context as I'm also interested in learning more about it: "The gossip model is a communication model used in decentralized systems, such as decentralized relays. In this model, nodes in the network communicate with each other by gossiping or spreading information in a peer-to-peer manner. When a node receives new information, it shares it with a few randomly selected neighboring nodes, which in turn share it with their neighbors, and so on. This process continues until the information has spread throughout the network. In the context of centralized vs decentralized relays, the gossip model is often used in decentralized relays to disseminate information across the network without relying on a central authority or server. Each node in the decentralized relay network acts as a peer, contributing to the dissemination of information by gossiping with other nodes. This approach provides resilience to failures and censorship, as there is no single point of control or failure in the network."

Also Ed25519 can't do DH so it can't be used for encryption, whereas secp256k1 does signature and DH. Isn't that ill-concieved DM scheme relying on secp256k1 DH. There are ways to convert an Ed25519 key into an X25519 key for DH, libsodium has something there, but just saying.

You can use the x-coordinate on the 25519 curve and do X25519 with your Ed25519 public keys, using the algorithm "always chose the positive x coordinate". Signal does this. In fact in secp256k1 we have the same situation.