Fetching relay lists just once is a fine idea, maybe doing it again after 24 hours or something. People don't change relays often.
Also, IMHO, rather than building a smartphone or web app, use a server as the protocol client, and the smartphone or web app just as a frontend to the server. Servers can aggregate far more efficiently, and don't have restrictions that webapps do.
I've come to believe the best solution is
- Replace nostr so we can fix these problems far better.
- Define in the standard that only 3 outbox relays will be honored, so people don't have incentives to publish to dozens.
- Use the Bittorrent DHT to bootstrap, instead of relying on a purplepag.es single-point-of-failure
- Give relays keypairs, so we don't have to depend on the DNS name, DNS lookups, or certificates from CAs issued by nobody companies. Technically, that means using TLS certificates with keypairs that we recognize the key of... which means they can't be secp256k1 since TLS doesn't support that cryptosystem.
- Switch to QUIC whenever IP privacy isn't needed (else use TCP over Tor), which doesn't have any connection limits and can recover connections even when endpoints switch IP addresses (e.g. moving from WiFi to 4G)
- A bunch of other stuff too.
I'm (slowly) working on this (called Mosaic) but my life has become complicated recently and I haven't had much time to devote to it.
Replies (4)
Sounds interesting!
Hope you can get back to this idea and showcase how it improves on nostr.
The secp curve is a big tradeoff in retrospect, mainline DHT compatibility would be huge but requires ed curve. I think pubky does this better.
In theory even adapter signatures can be implemented for the ed-curve. Only the bitcoin compatibility would suffer, however, I don't see too many use cases for signing onchain tx-es with nostr keys. We have LN addresses in profile data and cashu compatibility which does not rely strictly on schnorr either (wallet event can contain any pubkey).
Ultimately I think there are some things where nostr could improve but we must not forget that network effects are real, and they are hard to create. Although nostr has not built up a network effect among end-users, it has done it among developers and for me it is hard to imagine switching at this point, even with some theoretical problems.
To me right now it seems enough to have standardized signed events. I don't see the distribution aspect as much of a problem because anyone can back up and republish, and we have to make this easy on the app level.
I appreciate your efforts though and perhaps with time, you will be proven right.
Why the need to replace it entirely then?
What's the case against just giving :relay: Relays keypairs and let them specify #pubky (or similar) addresses that go beyond DNS (if they want)? This already seems good enough to me. Especially from a :community: Community lens.
Mainline DHT records are verified using ed curve instead of secp (nostr and btc).
This means I cannot sign a record pointing to my relay list using my nostr pubkey that is also verifiable on the DHT.
Bridging requires extra trust.
That extra trust might be good enough for communities as you mention, but it's not ideal and this could have been avoided.
The case against is that such relay endpoints won't work with clients that don't upgrade to support such a thing, so deploying such things forks nostr internally anyway. Most software won't be able to use such relays as their SSL will appear borked. But it can certainly be done. Not sure how to specify such relays in a way that doesn't cause existing software to try and fail to connect.
