Thread

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?

Replies (17)

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