the sad state of nostr
we must do better than this or we're fucked
Discussion
I don’t understand what about this is sad, genuinely wondering
it's incredibly centralizing. Continuing that status quo would mean a guaranteed failure for nostr
To prevent this users would have to not be connected to these relays, correct?
Then their notes would not make it into the relay?
I don’t necessarily think it’s a “guaranteed failure”, it’s a free market, if relays perform a service well then more users will add them. If they start to do things like censoring users, etc, people will drop them and search for alternatives quickly.
It's centralized
there's reasons why he's on my block list. a lot of very active users are just having a case of chronic textual diarrhea. i use plenty of other nodes and i certainly don't use a mobile app, at all. he is also completely ignoring the fact that if everyone uses them and the load gets beyond their budget those are gonna have to find a way to fund them, and suddenly, oh, they aren'et the supernodes anymore.
also it just shows how small the network is at this point.
Just remember that our current "big" relays are incredibly small if nostr succeeds. Relay hints being signed also help heal the network. Even if everyone uses the hubs, outliers can still force hubs to route to them, if hubs want any content with inbox-model-generated hints.
do any gossip implementations post replies to the relay hint from the note it's replying to?
Coracle doesn't, but I do publish replies to the user's NIP 65 inbox relays. The reason being there's not really a mechanism to self-hint that I'm aware of. I suppose `r` tags could be used, but those are frequently used for other things.
there really needs to be a DHT keeping track of notes by content hash, then choosing relays would be irrelevant, and getting traffic would happen by aggressively caching and advertising the cache content hashes and updates.
it will be interesting to watch how the self-healing p2p stuff will develop. there's a big puzzle in the matter of spam resistant indexing.
DHTs do not scale well with small pieces of content. The hash map ends up occupying almost as much space as the content itself.
i love when people tell the stark reality, it makes me so bullish! let's go nostr
nostr:note17wv36uvzzxxm86p7cvrxdklc3ceskyakyzdqr9xvj08swtjd0a5s0ajwva
FOREST baby! https://hornetstorage.com/forest/
Sync relays with request sizes smaller than Negentropy’s. 🌲
Relays just need to be setup to sync with other larger relays. Having to have all the clients use the same Gossip is a lot harder than just having new relays find and sync with others. Bitcoin nodes already go this. Relays should work the same. Then clients can just start with a few large relays and users can add their own.
No. That’s how you end up with a single huge relay called relay.x.com.
This is the equivalent of bcash.
Bitcoin nodes must jeep state in sync and the limited blocksize is the compromise we make to make that possible. Nostr can’t limit the amount of data it produces.
NIP-65 is important (tho imperfect as I described earlier) but saying “relay syncing is bcash” is overblown FUD. We need relay syncing, especially for paid relays. nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc
Strfry has syncing. I don’t see you calling it Bcash. What’s with all this hate?
Relays use FOREST to retrieve missing notes from other relays — but this functionality can be extended — relays can examine the NIP65 metadata (list of relays) inside a note and contact those relays to retrieve the note content…
This way the user doesn’t have to establish new connections to get the benefits of NIP65.
Still doesn’t solve NIP65’s other problem, but I have a solution for that too. Saying syncing is bcash is idiotic non-sense Pablo.
User checks where the note is stored with NIP65, relay grabs note from other relay (using the same NIP65 list) and delivers it to user.
This removes burden from the client and places it back on the server/relay. If the server/relay doesn’t grab the note for the client, the client can resort to grabbing it how they do today.
STOP THE FUD 🛑🙏
nostr:note1hdwwegfed7hmwvwxnznwefknhxxcn9yxzg56muz7vkta0yn08maq4fxa6q
nostr:note1zmll2uuknztn5f50feevxwxk5hqwmkjd4h82swj97cjthxzf3nlsgydcay
Decentralized GitHub social layer (notes reflecting commits etc) can use NIP65, but the repo itself is stored in relays and must be syncable otherwise it’d be centralized to one relay.
You can’t turn a repo into nostr notes, that’s why we use Merkle DAGs for the repo. See the bigger picture… 🖼️