Currently we're using a fixed set of relays in bitchat which is only a temporary solution. We could let users edit their own relays but 1) users don't know what relays are and 2) if users have no overlapping relays they can't talk to each other.
Here's a solution that we came up with. I'd like to know your thoughts. We're going to crawl a long list of relay URLs every 24 hours. This list will also include their estimated geo locations, also updated every 24 hours. This could be done in an automated GitHub runner.
That list of URLs plus their geo locations will be embedded and shipped with the bitchat app. Users who join a geohash channel will use the five closest relays based on the geohash location of interest.
This solves multiple problems at once:
1) relay centralization
2) privacy
3) speed
4) maybe censorship resistance?
What do you think?
Thread
Login to reply
Replies (38)
perfect is the enemy of good, this solution seems good frankly
Waiting to set my own relay , then all data get delayed via satellite for a cross continent bridge


Nikos
$BTC & Nostr Tech Nerd Army ! Nostr Cross continent satellite relay DEMO transmissions. π‘ Below is the chain of notes sent by...
*relayed - not delayed ( fat fingers )
This is a brute force solution. Every event needs relay selection heuristics so it can be found. I actually use geohashes as an example in my book. Read the chapter on relays, maybe it'll help you think about this.
Building Nostr - A Guide for Developers
Sorry, I didn't fully understand on the first read. This is actually interesting, maybe NIP 66 would help? Trust is an issue though, seems weird to trust a relay based purely on geographical proximity. You would also have to probe them to know they would accept events.
What's brute force about it?
I don't want to find specific users, I want to talk to a location-based channel.
Yes for gathering the first step where we gather a relay list it seems like a good option.
Do you have a script that can crawl for relay lists?
Yes and I would probe them to see if they accept kind 20000s. If they do, they can be on the list. Ideally it would be hundreds of relays, and each channel would live on say 5 relays. Persistence isn't important right now.
I've written a few but they are all terrible. I do think maybe self-attested nip 66 would be better here. That way you're not hijacking random personal relays, instead relying on volunteers who want to serve a particular geography. You would only need the usual 2-5 per region, and a few geo "hubs" could do a lot of the lifting.
I used IRC some years back. Found it interesting to talk to people all over the world.
Looks like a use case for nip66 and the g tag
I don't wanna trust that, we can figure it ourselves from the IP, that's good enough
I mean the g tag :)
Yes, thatβs probably the right idea, in the sense that the authorities are less likely to block their own servers than those located abroad, but we shouldnβt forget that in some locations there arenβt many Nostr relays (in Russia you wonβt even find five), and at first this will put a heavy load on the few that do exist there.
off topic: there is a bad spam situation where some bot spams every room with ;;;;;;;;;;;;;;;;;; millions of semicolons. We cannot block him.
Next iOS version fixes the block feature
time to get back into swift I guess
This could work wonder to have more secure and minimize black log from overlapping relay .
How easy would be for a bad actor to set a relay and use it as a honeypot to locate the bitchatters IP for certain locations??
π
Tor support would be nice to boost privacy...
Maybe could use NIP-66 to find public relays close to the users location?
How can relays opt to be included in that list?
What about a DHT for updating the list instead of app updates?
Does this mean that youβd have to make another release to update the list?
Also would this also cause users far away from each other to possibly not be able to chat with each other since theyβd likely be on different relays?
Iβd prefer some UI to manage relays and check if they overlap, then connect to whatever I want
oshit it works. crazy, I teleported with bitchat to thailand and it connects to yokihonne, a vietnamese relay, and a bunch of others from the region.
it also makes the lives of spammers a lot harder.
View quoted note β
github is a centralized piece of the puzzle, but I like the idea
It might be nice if Relays stored the updated relay lists.
@npub1jlrs...ynqn werenβt we talking about this a long time ago?
Nice, but heads up that if Cloudflareβd the relayβs location will not be accurate
If this is being used for protests and the geohash channels will use local relays, wouldnβt it be easier for authorities to crackdown on it?
Make the regional users be the relay, with multiple redundant relay users ready to handoff to.
The bitchat info screen needs to be updated. It says no servers and no data collection. Relays are serversβ¦


This is a good idea because this is what I do manually on nostr
Is 5 going to be enough without some sort of premium relay though
Maybe Iβm confused but relays donβt always stay persistentβ¦ maybe thatβs why you are saying a 24 hr turnover though
Things should run persistent for 24 hrs reliably
would consider storing and crawling the list of the relays in the app.
user can select from interface locations that are translated in background to relays.
hey -- we want to send you a test zap, but couldnβt find a NIP-05 or β‘ lightning address on your profile. u can set one up for free on rizful
... then pls reply here and we will do a test zap.

Rizful: Lightning Services
Free Lightning vaults, and instant, disposable Lightning Nodes.
Seems like Gitlab runner would be a better choice if you need that kind of functionality. Gitlab has good self-hosting support.
Keep up the great work and be careful of feature creep. I love that the apps under 10MB right now!
i see many WoT relays in the list. i don't think those are a good idea to include as new / emphemeral users can't write to them.
You can make this deterministic and completely client side:
1. Query bootstrap relays for kind 10002 and 3 events. Extract a list of 100s of relays from these. Takes a second or two when I tested it.
2. Hash every relay URL.
3. Hash the user's npub.
4. Use Kademlia XOR-distance to find the 5 relays "closest" to the npub.
5. Use those relays as inboxes for the npub.
6. (Can update this periodically as the global relay set changes.)
An advantage of the deterministic relay set is you can find the inbox relays with just the npub. Solves one of the issues you appear to have with geo-relays.
PoC:
Enjoy! π§
@jack
GitHub
GitHub - chr15m/nostr-relay-hash-table: Nostr client DHT for relay sets
Nostr client DHT for relay sets. Contribute to chr15m/nostr-relay-hash-table development by creating an account on GitHub.