demo relay set

so many spammers man.. its lowkey annoying

they won't be able to follow everyone when we have hundreds of relays for bitchat

makes sense nice

this is excellent. View quoted note →

#smij #zapd

Dope

semikolon guy bye bye

LFG

I can't help but feel that something's been unlocked and I'm not just talking about this from Calle. This is much larger than we can imagine and it will take imagination to put all this to good, effective, and positive use. But the potential? We're not even close to seeing the first scratches on the surface. View quoted note →

Brainstorming with Grok on bitchat geohash DHT relay hopping: Bitchat Relay Selection and Hopping Architecture Proposal Objective: Enhance Bitchat’s relay selection for geohash channels with a deterministic, decentralized, and secure system that supports multi-level geohash granularity, time-slotted relay hopping, and DHT-based relay discovery. This improves privacy, reliability, fairness, and censorship resistance while ensuring seamless channel communication. Architecture Overview: 1 DHT-Based Relay Discovery: ◦ Source: A Kademlia-based DHT (e.g., inspired by Fabric or HyperDHT) stores relay metadata (URL, IP, lat/long, uptime, NIP support). Relays announce signed entries (Nostr npub, PoW nonce for sybil resistance) under keys like hash("nostr-relay" + region). Clients query for geo-proximate relays dynamically. ◦ Anti-Spam: Normalize by IP+port+fingerprint (TLS cert hash); limit one entry per npub/day; require low-difficulty PoW (e.g., 16-bit SHA-256). Deduplicate by IP and flag multi-region claims via client-side filters (e.g., geo-mismatch with IP lookup via MaxMind GeoLite2). ◦ Fallback: Seed with a daily crawled list (from nostr.watch, hosted on IPFS/GitHub) for offline/bootstrap, updated in-app via DHT queries. 2 Geohash Granularity and Teleport Mechanism: ◦ Granularity: Support geohash levels: L=6 (neighborhood, ~150m), L=5 (city, ~5km), L=4 (region, ~150km), L=3 (state, ~5000km), L=2 (country, ~15,000km). Decode geohash to center lat/long (using geohash-js or equivalent). ◦ Selection Logic: For channel #bc_G (length L): ▪ Query DHT for relays; compute Haversine distance to G’s center. ▪ Filter viable relays within max distance (e.g., 1000km * (6-L+1)). If <5 viable, teleport: Truncate G to L-1, recompute center, retry up to L=2. ▪ Sort by distance, tiebreak by hash(URL). Pick top M=10 for hopping ring. ◦ Determinism: All clients converge on same M relays via shared geohash and DHT data. 3 Time-Slotted Relay Hopping: ◦ Mechanism: Rotate through M relays in 15-minute slots. Compute slot index: i = floor(unix_time / 900) % M. Select relay: ring[(hash(G) + i) % M]. Hash ensures per-channel uniqueness; modulo cycles fairly. ◦ Seamless Transition: At slot end, pre-verify next relay (ping, subscribe to #g-tagged events, check 90% event sync). Overlap subscriptions (1 min), publish to both, drop old post-sync. Fallback to next ring relay if verification fails. ◦ Fairness: Evenly distributes load (each relay ~1/M usage). Exclude overloaded relays (DHT-reported load>80%). 4 Implementation Details: ◦ Libraries: geohash-tools for decoding, Haversine for distance, Kademlia/HyperDHT for P2P discovery, Nostr client for event sync checks. ◦ Verification: Pre-hop, ping relay (WebSocket) and test NIP-01 subscription for recent #g events. Use Nostr event IDs for deduplication during overlap. ◦ Security: Signed DHT entries (Nostr npub) prevent spoofing. PoW and IP dedup thwart sybil attacks. Optional Bitcoin block height as slot seed enhances determinism. ◦ Performance: Cache relay lists per geohash (refresh every 6h). Limit M=10 for mobile efficiency. Battery-friendly: Hop only on active channel use. Benefits: • Privacy/Security: Hopping limits relay surveillance; ephemeral IDs stay intact; DHT avoids central points. • Reliability: Teleport ensures sparse regions connect; verification skips bad relays. • Fairness/Censorship Resistance: Even load distribution; fallback to broader regions bypasses local failures. • Seamlessness: Overlap prevents event loss; deterministic logic ensures channel consistency. Next Steps: • Prototype: Simulate 100 relays, 10 geohashes (L=6 to 2), test hop success rate and sync. • Beta: Integrate with existing selection; start with static list, add DHT incrementally. • Community Input: Open-source DHT crawler (GitHub) for relay list contributions. Effort: Extends existing geohash logic; ~2-3 weeks for DHT integration, 1 week for hopping. Minimal UI impact. This proposal aligns with Nostr’s decentralized ethos and Bitchat’s ephemeral, geo-aware design, ready for dev evaluation and iterative rollout.

this is a fun idea.

this could be actually pretty nice

Will we one day be able to follow our friends to different chats?

maybe, for now everything is consciously ephemeral

It’s a bit too ephemeral. I’m losing all the favorites I collect meeting people with every update.

That’s the fun! Gotta vibe to find your tribe

Haha maybe. Every time I see my friends we need to “gotta catch em all”

There’s a whole world out there people!! Not just the latest from an echo chamber!! Most of these fools ain’t even financially adept their devs!!

Well I can’t wait till blocking works

Excited for this update

Why is it harder for spammers in this case? Some sort of control set by the local relay?

hang on, does this mean you can use bitchat to communicate with someone on the other side of the world? how is that even possible if its over Bluetooth? Sorry for the noobie question but I'm not that technically literate.

I asked Gemini: You've asked a very good question that highlights an important point in the development of Bitchat. The white paper you linked to describes the original functionality of Bitchat as a pure Bluetooth mesh network designed for offline communication over short distances. The ‘teleport’ feature is a newer development based on a different technology. Here is an explanation of how it all fits together: What is geohashing? A geohash is a method of converting geographical coordinates (i.e. longitude and latitude) into a short string of letters and numbers. You can think of the world as a grid. The longer the geohash string, the smaller and more accurate the grid section on the map. Bitchat uses these geohashes to divide the world into different chat regions – these can be neighbourhoods, entire cities or even countries. Each of these geohashes basically functions as its own location-based chat room. How does ‘teleporting’ work? Your confusion is understandable, because a pure Bluetooth network could never establish a connection from Germany to Thailand. The ‘teleport’ function is part of an extension of Bitchat that runs over the internet and does not rely on the Bluetooth mesh network. Internet-based chat rooms: When you ‘teleport’ to another location via geohash, your app does not connect via Bluetooth, but via the internet to the chat rooms associated with that geohash. Nostr relays: Technically speaking, so-called Nostr relays are used for this. These are decentralised servers that forward messages. Your message is sent via the internet to a relay and from there distributed to all other users in the same geohash chat room, no matter where in the world they are located. You can think of it this way: Bitchat has two separate modes: Offline mode (Bluetooth mesh): For direct communication with people in your immediate vicinity (up to approx. 300 metres), completely without the internet. Online mode (location chat): For worldwide communication in location-based chat rooms that you can enter via geohashes. This mode requires an internet connection. The ability to ‘teleport’ is a clever way of saying that you can simply join a chat room that is assigned to any location in the world.

Is xterm still a thing? 👀

Great question . Great answer . Clarifying Bitchat without internet . Designed for small communities .Needs bluetooth mesh network . And Bitchat teleporting with internet . Designed for chat across the globe. Doesn't use bluetooth. It uses geohashes.