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 (17)
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 :)
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
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
How about publishing the list a s a Nostr post from a publisher who only posts the relay list so that latest list is available everywhere.
Nice, but heads up that if Cloudflareβd the relayβs location will not be accurate
@calle you are literally building the backbone of a new society, pls continue
I think geo hash is the way we differentiate human key pairs from ai ley pairs on nostr. Proof of human (cringe) but it is required.
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.
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!
Wow? Can each repeater be understood as a node in the blockchain? It's also pretty cool for each repeater to exist as a node in the blockchain.
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! π§
@npub1sg6p...f63m
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.