Replies (53)
Don't delay outbox. You will regret it later.
agree
perfect is the enemy of good, this solution seems good frankly
Outbox solves finding users, especially those who use their own relays, but it doesn't solve relay selection/decentralisation.
Elaborate?
The architectural design and the caching system will change so much that the more you delay the more you will have to rewrite later on.
*relayed - not delayed ( fat fingers )
Why should we use outbox for this use case? Can you explain it like I'm a noob?
Because:
1. centralizing is bad. The main relay set can moderate everything.
2. the fixed set of relays will know the location of each one of your users.
3. You want people to choose relays that are physically closer to them for performance.
4. If I follow people on Nostr and they are using bitchat, I don't want to have to move to their location to talk to them, I just send to their relays.
5. Relays can become topical communities within locations.
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.
I don't get it. How does this apply to bitchat? The channels are literally location-based. Users have no persistent identities, you can't follow them.
What's brute force about it?
I don't want to find specific users, I want to talk to a location-based channel.
I don't want to find users, I want to talk to everyone in a location-based channel.
The problem were trying to solve isn't following users or finding the relays rhey post on. We're doing location-based channels. What you list applies to Twitter like feeds but I don't see how it applies to bitchat.
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.
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
Then just do it because a decentralized list is better than a fixed one. Otherwise, you don't even need nostr for fixed servers.
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
I don't know what a decentralized list is but it will be generated from nostr.
This could work wonder to have more secure and minimize black log from overlapping relay .
I mean the g tag :)
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?
time to get back into swift I guess
Will it be useful though? Imagine wasting time on manually blocking tons of bots
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.
How can relays opt to be included in that list?
What about a DHT for updating the list instead of app updates?
Agreed. Outbox doesn’t fit the ephemeral chat model imo.
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.
@ hodlbod 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.
I used IRC some years back. Found it interesting to talk to people all over the world.
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
@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.
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
Rizful: Lightning Services
Free Lightning vaults, and instant, disposable Lightning Nodes.
... then pls reply here and we will do a test zap.
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!
3 MB!
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:
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.
Enjoy! 🧐
@jack
