Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 9
Generated: 15:46:07
Dev story time: How SatShoot ended up using partial #outbox model: Using NIP65 relay lists to decentralize discovery looks like a fantastic concept at first... And then you realize that most things taken to extremes ends up in the complete opposite way you intended. This is true for the outbox model. You want decentralization. Maybe you convinced a lot of people to publish outbox relay lists (BIG maybe), so far so good. Still, you ended up with an app that connects to hundreds of relays **and keeps those connections alive**. Problems: - app uses a lot of data - app will make your phone run flat in no time - app likely gets heavily resource constrained by the OS when user switches away, relay conns are killed - app code has tremendous added complexity (perhaps the worst of all!) So what this effectively ends up doing is: - only native apps will be able to handle this kind of load, maybe only desktop apps - only people with close-to unlimited data plans will be able to use your app - very few people will be able to understand your code, if any (including you) So you ended up introducing all these centralizing dynamics, while users don't even understand or appreciate why you did it. And of course it all still relies on purplepages to fetch the initial lists, right? ;) I had a better idea (communities are even better but until they come online this is my approach): 1. Use explicit relays by default, let normal users set explicit relays, and superusers set outbox too 2. Publishing is simple since it is targeted: you just publish to explicit relays + outbox (or inbox of target if it's a reaction to sth or mentioning someone) 3. You calculate optimal relays and fetch all relevant events ONE time, on a user-triggered "Decentralized Discovery". This should explain what's happening and why it's super cool. 4. Show the progress and at the end, add top relays to the pool for that session 5. User thinks "This is cool, I'm doing the Decentralized Discovery, Nostr Rocks!" and you did not have to keep all those connections and constantly keep score and all that. Just do it once. This is now implemented in SatShoot: https://v.nostr.build/8bZAOIjVjsCf41pm.mp4 Opinions?
2025-10-20 16:30:34 from 1 relay(s) 2 replies ↓
Login to reply

Replies (9)

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.
2025-10-20 18:39:18 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
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.
2025-10-21 06:16:28 from 1 relay(s) ↑ Parent Reply
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.
2025-10-21 08:37:01 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
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.
2025-10-21 17:01:21 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
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.
2025-10-21 22:26:28 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
You are right that all software needs to update to take advantage, but that doesn't mean you can't make it incremental... For example Pkarr TLS certificates don't work in browser, so any Pkarr based server needs to also have an endpoint accessible by ICANN and their certificates... But that is already the baseline for Nostr relays... So now you only need to add an endpoint using Pkarr TLS and clients capable of understanding that uses that, in they very unlikely chance of being censored at DNS level.. The main problem is that there are no users anyways so despite all that being possible already a year ago, no one gives a shit ... And both wisdom and happiness is to smile while saying that :) 😊
2025-10-22 06:48:52 from 1 relay(s) ↑ Parent Reply
Nah this is not a problem the problem is that no one cares. If you reeeeally wanted to sign the certificate with secp for some reason you can, all you need ed for to use Mainline DHT is to identify the server with that key... But guess what you can identify things multiple ways and you can put your secp in Pkarr records to use for the handshake Hell you can just inscripe your ed curve on Bitcoin with a signature from your nsec ... You can do whatever... But you won't because again, no one wants any of this :)
2025-10-22 06:52:10 from 1 relay(s) ↑ Parent 1 replies ↓ Reply