Comment by nicois
5 hours ago
One missing feature: deferred message propagation. As far as I understand, while messages will be rebroadcast until a TTL is exhausted, there is no mechanism to retain in-transit messages and retransmit them to future peers. While this adds overheads, it's table stakes for real-life usage.
You should be able to write a message and not rely on the recipient being available when you press send. You should also be able to run nodes to cache messages for longer, and opt in to holding messages for a greater time period. This would among other things allow couriers between disjoint groups of users.
that is a super good callout.
this is prob the 100th time ive read about bitchat here, and the comments are largely the same (use briarchat, none of these really work that well, i dont like jack dorsey, etc) every time.
but this is interesting. and i agree strongly with this: "While this adds overheads, it's table stakes for real-life usage."
i suppose events like iran are really making me wonder if this stuff is possible it feels like anyone who's under the chokehold of regimes has completely run out of options, but even in America I'm getting the sweats wondering if there's going to be a time where such techs are needed. from what i gather none of these decentralized p2p messengers work well at all, but I also haven't truly tried. I can think of some moments that would've been viable test grounds though. Was at Outsidelands festival in San Fran and cell service was pretty much DOA due to the volume of people trying to hit the same tower(s). Even airtags which everyone in the group had on their beltloop weren't working.
It's funny how 3 or 4 similar BLE systems each are slightly different, and yet no one wants to just merge all the features for an obviously superior product. Everyone seems fine squabbling about which incomplete app/system is better.
Just take what's there and include the obvious next steps:
- Meshtastic and Meshcore ability to use relay nodes for long range BLE networks (Briar doesn't allow)
- Store and hold encrypted messages, as noted above.
- Ability to route through the internet, prioritize routing methods, disable internet routing, etc.
- Ability to self-host server for online relays (similar to Matrix)
Lack of retention can actually be a feature in these types of situations. It should be opt-in. The government would actually need to infiltrate the network in order to read the conversations, instead of just retrieving the messages from the cache on a confiscated phone
I'd consider end-to-end encryption to also be table-stakes, at least opportunistically after the first message in each direction. With encryption cached messages are far less harmful (though still leaking very useful metadata), without encryption it seems almost trivial to spy on any communications
1 reply →
> instead of just retrieving the messages from the cache on a confiscated phone
why wouldn't encryption be a part of recipe here rendering government acquisition of such a cache moot?
2 replies →
> The government would actually need to infiltrate the network in order to read the conversations
If I understand correctly, this would still be true if the recipient is connected.
What you are talking about is called “store and forward” [1]
1. https://en.wikipedia.org/wiki/Store_and_forward
Is the issue with this that mobile OSs - iOS in particular are rather aggressive about shutting down apps in the background after a while?
iOS definitely made a name for itself to the ire of many for this many moons ago, but it's a fairly ubiquitous default behavior for mobile phone operating systems now (because battery life) even on android