I recently took a flight with family- on a budget airline that did not have Wifi, so we could not hop on WiFi and message each other using Signal. I wondered what other options there would be in the air- and remembered Bluetooth Communication apps- and had everyone install Briar- it came in haandy!
I like the built in Bridge option as well, (when the app communicates over the internet) to help avoid revealing the traffic is Tor traffic.
I have been impressed by the range of Briar- with a clear line of site, easily hundreds and hundreds of feet- i tested it to well over 500 outside- and on the plane , my family was scattered, but that was no issue at all. (More recently though i've detected my own Bluetooth MotoTag trackers from my luggage in Cargo holds while on planes, so Bluetooth indeed works well on planes.)
-I have heard of but have never used BridgeFy, which I know was a well known famous Bluetooth app that competed with Briar in the past. To my understanding it isn't quite as secure or open source.
There is a informative post here
https://old.reddit.com/r/Briar/comments/gxiffy/what_exactly_...
where a developer noted Briar's capabilities at that time- it seems due to some changes on the OS/phone Hardware end, and whatnot- and due to the phones only passing messages to contact nearby - Briar is not a true mesh networking app. It is a shame- i feel a true Bluetooth mesh networking app would be unstoppable in availability -though it might be a bit of a battery drain.
It is a shame Briar isn't on iOS also -
I also wish Signal would eventually consider communicating over any medium accessible- they would probably run into similar issue Briar has.
What will it take to get a Peer-to-Peer capable Bluetooth/Wifi/Celluar network using/(more possibly in the future)- proper optional mesh networking, Tor capable, VPN friendly, wholly end to end encrypted ,perfect forward secrecy including, fully open source App providing messaging (with the 'accounts' that Briar uses?), for Android and ios?(And Let's throw in PC Mac and Linux, so laptops could have a extremely user friendly user accessible way of doing this as well.)
Better yet, add Calling capability- i don't know how rough doing video calls would be over some methods like modern day Bluetooth- but even a rough capability would be used a little and be worth adding to the collection of things one could do(Briar is only Messaging at the time of this post- which is something notable for sure,as very few apps let you transmit solely thru Bluetooth<I have not heavily looked into the shared Wifi communication abilities of Briar at this point in time> - but more could be added in some form...I observe apps do exist that allow for Bluetooth calling or act like "Bluetooth" Walkie Talkies)
Unfortunately, iOS simply does not allow apps like Briar to run reliably in the background[1]. Unless Apple changes its thinking about iOS, Briar or other similar apps would never work reliably.
> so we could not hop on WiFi and message each other using Signal.
I have a feature request for this actually. I think if it got a harder push they would consider it. It's not full decentralization but does still prevent the concerns that Moxie and Meredith have stated.
It is like you say: I too wish Signal would allow for communication over any available medium.
Have you seen Meshtastic (https://meshtastic.org/)? It seems like a similar concept but using dedicated devices and unlicensed ISM frequencies, and it's a proper mesh network (so you can even setup repeaters to provide better coverage for an area). I guess they wouldn't work too well if you're travelling to another country since you'd have to get the right radios for the country but it's a neat idea.
Furthermore, the latest build of Meshtastic mentioned some LAN networking, so nodes that don't have radios can still exchange messages if they're connected by some other means.
That seems just a hop skip and a jump from having a Bluetooth WPAN/WLAN that lets many phones share one or zero Meshtastic radios but still be able to talk to each other...
How was your actual UX with Briar? I tried to get family to use Briar during a flight and it was pretty poor. Messages wouldn't show up and we were worried about disconnecting from personal Bluetooth headphones while keeping using Briar. It worked okay and at one point my partner and I chatted about landing plans when the person next to us was asleep. But we found that just passing the phone around with typing worked just as well. It worked okay for the other family but again, was a pain.
It worked well! Most messages did go through! The caveat- I don't think anyone was also using Bluetooth headphones
500 feet outside was the test i did with a clear sightline- the inside of the plane was not quite as far, but the messages did go through - and we couldn't have passed the phone around when one family member was 5 seats behind me, the next was about 20 rows in front of me
I've really been trying to get Signal to get some decentralization[0] but unfortunately I pissed off some mods. I do understand their reasoning for staying away from full decentralization, both Moxie and Meredith have made good arguments. But I think this is something where there's a really good middle ground. Where both parties highly benefit.
Users get a lot of added utility, "fun", and not to mention a huge upgrade in privacy and security (under local settings), while Signal gets to reduce a lot of data transfer over the network. There's a lot of use cases for local message and file sharing (see thread) and if the goal is to capture as little data as possible about the users, well let's not capture any network traffic when users are in close proximity, right? It's got to be a lot harder to pick up signals that only are available within a local proximity than signals traveling across the internet. The option of expanding to a mesh network can be implemented later[1] but I don't understand how an idea like this doesn't further the stated goals.
The big problem with things like Briar is that you can't install it after the internet has been turned off AND it is already unpopular. But if an existing app with an existing userbase implements even some meshing then this benefits all those users when an event like that happens. Not to mention there's clear utility in day-to-day life.
[1] I think a mesh network maintains the constraints both Moxie and Meredith have discussed, concerns about ensuring servers are up to data. But then again I'm not sure why that can't be resolved in the same way it is already done where if you let Signal fall too far behind in updates then it will no longer communicate with the servers.
Secure Scuttlebutt can do similarly. A wandering node can ferry messages to another cluster of nodes; it's used by sailboats where someone visits shore to run errands and exchanges messages as they go.
Do you know of any documentation to get SSB bootstrapped? I tried several times, but I hit a wall of not being able to find any active communities, plus there were old-style, technically obsolete communities and new-style communities, and half the available documentation referred to each, so it was impossible to figure out what to do.
Other phones with Briar installed can carry your (encrypted) messages, as in a game of whisper. This works best if enough people between you and the recipient had Briar installed ... but most people don't.
But I see how this feature could be very helpful if a state shuts down internet connectivity or during war or a natural catastrophe. The nifty thing is that the app can be shared from one device to another, so you are not dependent on having the app in advance of an emergency.
Ideally, everyone should have this installed as an insurance :)
A bunch of countries turn off the internet at the first sign of protests, hell sometimes they just turn it off to stop "a bunch of college kids from cheating during test week"
It's kind of interesting to see P2P coming back! I'm happy to see more P2P projects popping up. When the Snowden leaks came out, there was a brief interest in P2P encrypted messaging. I wonder if the political climate now is bringing interest back.
Back in 2014 (I believe briar started in 2015) I wrote a realtime P2P application platform. Not only could you send encrypted messages between people, but you can also send files, play games, and write and share programs together, all within the application. The use case for mine is different than briar's.
Briar is really interesting from the PoV of its forum and blog features, that try to use the messaging platform as infrastructure to build private services.
There's a lot of discussion about alternatives here so I'm going to drop one more: https://cwtch.im
It has wider range of clients and some unique features, like the ability to run multiple, password protected identities trivially, to appear online selectively.
I just wish one could delete or edit on briar's forums. Without that, I feel like I have to be super careful not to make a mistake, if I want an orderly forum. Also in latest versions the ability to fold forum threads is gone? Makes forums annoying to read. The indentation for a sublevel being sooo thin also doesn't help at all.
Sounds like a cool project, but the name is such a bad idea, despite the cleverness of word choice. An app for a niche use case has it hard enough, doesn’t help that nobody can spell correctly even when reading it.
Why invent wheel when we already have Reticulum network which provides integrity and confidentiality on OSI Layer 2 ? So for every packet. It is not better to build "apps" on top of a secure network? That way even if "app" does accidental bad thing, your private content is not exposed to anyone who listens to your network traffic. By default not by "just use another VPN with exit nodes full of network inspection tools, dns redirection services etc" ?
Reticulum seems to be by far the most interesting project in this space.
I would invite anybody to explore it for a few hours at least, it is fascinating.
Now the only thing that scare me about it is that it is really a "one man" project [0].
I am not sure why, I do not know if anybody else look or understand what he is doing, but hell it doesn't make me feel confident to rely on it.
I thought this was sarcasm, but it isn't. Seems like a very weird choice to me to build network infra on top of Python. C/Rust would have been the more obvious choice since you can then bind to that from any language (at least with C).
you mean how everyone built on top of ipv4 and can't abandon it now, even after 3 decades of it's replacement being available and more secure? Or how everyone uses TLS now, not because it's the best way but because like 'Reticulum' it became the best bloated compromise?
General purpose systems aren't always ideal, they're just ideal to gain mass adaption. For applications who target smaller sets of users and prioritize security guarantees, being able to fix bugs at any 'layer' and not depend on external entities is crucial. How I'd wish they'd even use their own Layer 2/3 stack if it were practical.
As someone familiar with networking and Reticulum, I felt confused by reading this thread. I felt the need to explain Reticulum in the networking stack. So here goes.
You can think of Reticulum as a mix of the internet layer and a message-semantics oriented transport layer. Reticulum is focused on trustless, encrypted data transfer with message-oriented semantics suitable for devices with small MTUs.
In current IP-based stacks these are separated at great compromise. First of all, the internet layer is unencrypted. Any actor listening to internet layer traffic can intercept and track or modify IP packets (and indeed this is used for things like NAT.) Secondly, link layers are disparate and fragmentation is used to make sure that IP packets can run atop the link layer. Most modern networking stacks are (UDP|TCP)/(IPv4|IPv6)/(Ethernet|802.11). Ethernet and 802.11 ("WiFi") frames are large enough to comfortably deliver IP packets with minimal fragmentation.
Applications on the internet often send/receive messages but do this at a level above TCP. TCP fragments data atop IP but has stream-oriented semantics. UDP can be used for message-oriented semantics if used very carefully, but UDP packets are delivered with best-effort and UDP packets are often delivered out-of-order or dropped due to congestion and other reasons. There have been several attempts to add message-oriented semantics onto the net. SCTP is in heavy telecom use but seems to be mostly dead in the consumer space. (I recently ran iperf on a recent Linux kernel build and was able to get 8 Gbps on loopback TCP but only 600 Mbits on loopback SCTP. Unsure if I needed to do something different than what iperf does.)
TLS can be layered atop TCP to add security, but that security is only available at the TLS layer and involves trusting Certificate Authorities. QUIC goes atop UDP but also uses the same CA style trust model of TLS. Both QUIC and TLS+TCP are stream-oriented. QUIC has unreliable datagrams which allow message-oriented semantics but this is unreliable. Moreover, all of these protocols rely on delegated authority. Your ISP will give you an IP address that it will route packets for and often this address lives as long as your ISP connection does and will reset when your connection does. If there's NAT involved on IPv4 then you don't even get end-to-end connectivity with your address. Your ISP also has a block of IPs and there's a huge governance structure involved in deciding which entities have which IPs and announcement protocols which announce IP routing tables. Reticulum doesn't rely on delegated authority or governance as much.
Then the other side of the problem is MTUs. Ethernet and 802.11 frames are large enough that IP and TCP can sit atop them well with minimal fragmentation. Fragmentation adds header overhead. However when you get to links like LoRa or TNCs, your MTUs are much smaller. Running IP on these links may be doable but TCP will probably be flooding the link with mostly fragmentation overheat. Reticulum is designed to work better with low MTUs allowing you to bring in links that are associated usually with much higher latency or lower bandwidth such as LoRa or TNC.
For our wold as-it-is, the current state of TCP/IP works fine. ISPs are built out with this model, the governance remains robust, and we rely on utilities to build out the high-MTU links that our comms infrastructure rely on. But if you find yourself dealing with situations with low-MTU, smaller links or low-trust situations, then Reticulum could be of interest. Ad hoc networks are great deployments for Reticulum, for example. There's a lot of innovation going on in this space. See Yggdrassil for a solution with stable-addressing based on key-derived IPv6 addresses and P2P routing which works well when you don't have low-MTU links.
I just read through the documentation for Reticulum but I'm not sure what the point of it is. It looks like a Tor like network written in Python? As far as I can tell the entire thing runs virtually over TCP.
The manual says something about physical networks (is this intended to replace ethernet?) but it also mentions a current throughput of 40mbps so surely that's not what you're supposed to use it for.
Reticulum supports multiple interfaces to transport data, TCP is just one of them. Other are ethernet, packet radio TNCs (think ham radio), LoRa, stdio/pipes, I2p, etc. More details on some of the supported interfaces http://reticulum.network/manual/interfaces.html
Those "journalists" they claim to protect could get into serious trouble for merely using Tor. From there it's a trivial matter of rubber hose cryptanalysis to defeat the rest of the "protection". The danger with such tools is someone without proper training thinks they're a super spy, and then they draw attention of the people who actually understand such things, and can put a bag over their head and deliver them to a black site.
Readit News
I like the built in Bridge option as well, (when the app communicates over the internet) to help avoid revealing the traffic is Tor traffic.
I have been impressed by the range of Briar- with a clear line of site, easily hundreds and hundreds of feet- i tested it to well over 500 outside- and on the plane , my family was scattered, but that was no issue at all. (More recently though i've detected my own Bluetooth MotoTag trackers from my luggage in Cargo holds while on planes, so Bluetooth indeed works well on planes.)
-I have heard of but have never used BridgeFy, which I know was a well known famous Bluetooth app that competed with Briar in the past. To my understanding it isn't quite as secure or open source.
There is a informative post here https://old.reddit.com/r/Briar/comments/gxiffy/what_exactly_... where a developer noted Briar's capabilities at that time- it seems due to some changes on the OS/phone Hardware end, and whatnot- and due to the phones only passing messages to contact nearby - Briar is not a true mesh networking app. It is a shame- i feel a true Bluetooth mesh networking app would be unstoppable in availability -though it might be a bit of a battery drain.
It is a shame Briar isn't on iOS also -
I also wish Signal would eventually consider communicating over any medium accessible- they would probably run into similar issue Briar has.
What will it take to get a Peer-to-Peer capable Bluetooth/Wifi/Celluar network using/(more possibly in the future)- proper optional mesh networking, Tor capable, VPN friendly, wholly end to end encrypted ,perfect forward secrecy including, fully open source App providing messaging (with the 'accounts' that Briar uses?), for Android and ios?(And Let's throw in PC Mac and Linux, so laptops could have a extremely user friendly user accessible way of doing this as well.)
Better yet, add Calling capability- i don't know how rough doing video calls would be over some methods like modern day Bluetooth- but even a rough capability would be used a little and be worth adding to the collection of things one could do(Briar is only Messaging at the time of this post- which is something notable for sure,as very few apps let you transmit solely thru Bluetooth<I have not heavily looked into the shared Wifi communication abilities of Briar at this point in time> - but more could be added in some form...I observe apps do exist that allow for Bluetooth calling or act like "Bluetooth" Walkie Talkies)
[1] https://developer.apple.com/forums/thread/685525
Never had it stopped by iOS. So not only there's no fundamental restriction, the App Store itself allows some apps to do that.
It is like you say: I too wish Signal would allow for communication over any available medium.
https://community.signalusers.org/t/signal-airdrop/37402
That seems just a hop skip and a jump from having a Bluetooth WPAN/WLAN that lets many phones share one or zero Meshtastic radios but still be able to talk to each other...
500 feet outside was the test i did with a clear sightline- the inside of the plane was not quite as far, but the messages did go through - and we couldn't have passed the phone around when one family member was 5 seats behind me, the next was about 20 rows in front of me
I'd like to see more "peer to peer" projects take things this seriously.
Users get a lot of added utility, "fun", and not to mention a huge upgrade in privacy and security (under local settings), while Signal gets to reduce a lot of data transfer over the network. There's a lot of use cases for local message and file sharing (see thread) and if the goal is to capture as little data as possible about the users, well let's not capture any network traffic when users are in close proximity, right? It's got to be a lot harder to pick up signals that only are available within a local proximity than signals traveling across the internet. The option of expanding to a mesh network can be implemented later[1] but I don't understand how an idea like this doesn't further the stated goals.
The big problem with things like Briar is that you can't install it after the internet has been turned off AND it is already unpopular. But if an existing app with an existing userbase implements even some meshing then this benefits all those users when an event like that happens. Not to mention there's clear utility in day-to-day life.
[0] https://community.signalusers.org/t/signal-airdrop/37402
[1] I think a mesh network maintains the constraints both Moxie and Meredith have discussed, concerns about ensuring servers are up to data. But then again I'm not sure why that can't be resolved in the same way it is already done where if you let Signal fall too far behind in updates then it will no longer communicate with the servers.
Sideloading an .apk is supported in all Android versions, right? Even without internet access? Is something more needed to install Briar?
https://www.theguardian.com/world/2014/sep/29/firechat-messa...
China went to hard mode to kill the app.
But I see how this feature could be very helpful if a state shuts down internet connectivity or during war or a natural catastrophe. The nifty thing is that the app can be shared from one device to another, so you are not dependent on having the app in advance of an emergency.
Ideally, everyone should have this installed as an insurance :)
Coming to a country near you soon
This sort of thing seemed unthinkable a decade ago, or even in the first Trump admin, but definitely doesn't now.
Other similarly-inclined regimes like Modi in India have proven the effectiveness of targeted Internet shutdowns.
Back in 2014 (I believe briar started in 2015) I wrote a realtime P2P application platform. Not only could you send encrypted messages between people, but you can also send files, play games, and write and share programs together, all within the application. The use case for mine is different than briar's.
https://firestr.com/
https://github.com/mempko/firestr
P2P is really fun but also important and I'm happy to see interest in P2P apps coming back!
https://peergos.org
There's a lot of discussion about alternatives here so I'm going to drop one more: https://cwtch.im
It has wider range of clients and some unique features, like the ability to run multiple, password protected identities trivially, to appear online selectively.
Cwtch – Privacy Preserving Messaging - https://news.ycombinator.com/item?id=43367012 - March 2025 (21 comments)
Assuming README is among the first files created in a project, here's the date of the first commit for each:
2011: https://sourceforge.net/p/briar/mailman/message/27393146/
I would invite anybody to explore it for a few hours at least, it is fascinating.
Now the only thing that scare me about it is that it is really a "one man" project [0]. I am not sure why, I do not know if anybody else look or understand what he is doing, but hell it doesn't make me feel confident to rely on it.
- [0] https://github.com/markqvist/Reticulum/graphs/contributors
Timing is the reason.
https://reticulum.network/index.html
https://github.com/markqvist/reticulum
General purpose systems aren't always ideal, they're just ideal to gain mass adaption. For applications who target smaller sets of users and prioritize security guarantees, being able to fix bugs at any 'layer' and not depend on external entities is crucial. How I'd wish they'd even use their own Layer 2/3 stack if it were practical.
You can think of Reticulum as a mix of the internet layer and a message-semantics oriented transport layer. Reticulum is focused on trustless, encrypted data transfer with message-oriented semantics suitable for devices with small MTUs.
In current IP-based stacks these are separated at great compromise. First of all, the internet layer is unencrypted. Any actor listening to internet layer traffic can intercept and track or modify IP packets (and indeed this is used for things like NAT.) Secondly, link layers are disparate and fragmentation is used to make sure that IP packets can run atop the link layer. Most modern networking stacks are (UDP|TCP)/(IPv4|IPv6)/(Ethernet|802.11). Ethernet and 802.11 ("WiFi") frames are large enough to comfortably deliver IP packets with minimal fragmentation.
Applications on the internet often send/receive messages but do this at a level above TCP. TCP fragments data atop IP but has stream-oriented semantics. UDP can be used for message-oriented semantics if used very carefully, but UDP packets are delivered with best-effort and UDP packets are often delivered out-of-order or dropped due to congestion and other reasons. There have been several attempts to add message-oriented semantics onto the net. SCTP is in heavy telecom use but seems to be mostly dead in the consumer space. (I recently ran iperf on a recent Linux kernel build and was able to get 8 Gbps on loopback TCP but only 600 Mbits on loopback SCTP. Unsure if I needed to do something different than what iperf does.)
TLS can be layered atop TCP to add security, but that security is only available at the TLS layer and involves trusting Certificate Authorities. QUIC goes atop UDP but also uses the same CA style trust model of TLS. Both QUIC and TLS+TCP are stream-oriented. QUIC has unreliable datagrams which allow message-oriented semantics but this is unreliable. Moreover, all of these protocols rely on delegated authority. Your ISP will give you an IP address that it will route packets for and often this address lives as long as your ISP connection does and will reset when your connection does. If there's NAT involved on IPv4 then you don't even get end-to-end connectivity with your address. Your ISP also has a block of IPs and there's a huge governance structure involved in deciding which entities have which IPs and announcement protocols which announce IP routing tables. Reticulum doesn't rely on delegated authority or governance as much.
Then the other side of the problem is MTUs. Ethernet and 802.11 frames are large enough that IP and TCP can sit atop them well with minimal fragmentation. Fragmentation adds header overhead. However when you get to links like LoRa or TNCs, your MTUs are much smaller. Running IP on these links may be doable but TCP will probably be flooding the link with mostly fragmentation overheat. Reticulum is designed to work better with low MTUs allowing you to bring in links that are associated usually with much higher latency or lower bandwidth such as LoRa or TNC.
For our wold as-it-is, the current state of TCP/IP works fine. ISPs are built out with this model, the governance remains robust, and we rely on utilities to build out the high-MTU links that our comms infrastructure rely on. But if you find yourself dealing with situations with low-MTU, smaller links or low-trust situations, then Reticulum could be of interest. Ad hoc networks are great deployments for Reticulum, for example. There's a lot of innovation going on in this space. See Yggdrassil for a solution with stable-addressing based on key-derived IPv6 addresses and P2P routing which works well when you don't have low-MTU links.
The manual says something about physical networks (is this intended to replace ethernet?) but it also mentions a current throughput of 40mbps so surely that's not what you're supposed to use it for.
Deleted Comment
Deleted Comment