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.
iOS doesn't allow apps to stay active in the background to listen for messages like Android can. And since Briar very much does not rely on the vendor push services that is a showstopper.
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.
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.
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.
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
Briar runs a Tor Onion Service on your device. I'm unsure how well Tor supports having multiple devices acting as the server. One option could be to have a main program that's always on, to which your messages are received, and other clients can then use the Onion Service to fetch a copy of the conversation. It would add another link in the chain and increase latency so I'm not surprised if that's not being done.
The BT MAC is shared with peers so they can find you (as well as a list of your IP addresses) but I don't think identity is tied to it. Identity seems entirely tied to a public certificate. But I could be wrong.
The last time I checked, a lot of the nodes are just run in Hetzner's data centers meaning there's not too many actors. I can't even find that list anymore so if anyone has one, I'd like to update my knowledge.
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.
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)
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.
Even now, when I see Briar's name anywhere, I think of this as "ah, that Android only app" and that imho is saying something for a privacy messaging app. I am not saying it has not reason (Apple's unsound, unfair, and consumer hostile tight control is the reason! [1]) to be Android only, I am just saying - it's very unfortunate and unfortunately defeating.
[1] In the name of privacy theatre which they have actually been able to defend by spending both on PR and lawyers.
iOS vs Android is a bit like ChromeOS vs Windows/MacOS/most Linux distros.
There are benefits to more restrictive operating systems. For example, iOS not allowing apps to run in the background essentially stops any apps with malware from doing stuff in the background, but it also stops apps like Briar, Syncthing, etc, from working well.
I assume Android isn't a problem for most Briar's users. They're likely running a deGoogled Android version (GrapheneOS, LineageOS, etc) and downloading/updating the app via F-Droid or something like that. They don't rely on Google (or Apple) to run anything.
Yup, from what I hear, the problem is Apple doesn't allow process forking which means Tor would have to run inside the same process as the messaging app which is ridiculous.
Briar is a nice idea, but last time I used it I couldn't find peers, if memory serves. I tried adding a friend who was interested and we sat and waited for our messages. They never arrived.
The idea is great, but the adoption rate is way to low for any P2P thing to actually work (unless with agreed upon meetings).
Meshtastic is a better option, because it uses LoRa (thus requires additional hardware), but with a good location, many kilometers can be covered and mesh networking extends this a lot further. Meshcore is supposedly the next "generation" of meshtastic, but not popular enough over here to actually test it.
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.
> If the Internet’s down, Briar can sync via Bluetooth, Wi-Fi or memory cards
I'd like to see more "peer to peer" projects take things this seriously.
Briar was funded by the CIA. Partly.
Not immediately apparent to me: does Briar use a double-ratchet these days?
The main rason for me to like vriar over other stuff is its insane privscy focus, and the bluetooth relay stuff for fully offlibe communication
Are the typos on purpose for opsec reasons?
this seems interesting and I (very briefly) installed to check it out but never actually used.
I just noticed there is no IOS version? bit strange no?
also no update on their blog since 2023?
would be interested to read whats going on recently, is there another place to look?
They explain the iOS situation here: https://code.briarproject.org/briar/briar/-/wikis/FAQ#will-t...
People looking for insanely secure messaging to run on a proprietary backdored devices.
I noted that as well.
Honestly given the target audience and the limited dev resources I (as an iOS user) do think focusing on Android is probably the right choice here.
iOS doesn't allow apps to stay active in the background to listen for messages like Android can. And since Briar very much does not rely on the vendor push services that is a showstopper.
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" ?
> Why reinvent the wheel when we already have Reticulum network
Assuming README is among the first files created in a project, here's the date of the first commit for each:
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.
- [0] https://github.com/markqvist/Reticulum/graphs/contributors
> Reticulum network
https://reticulum.network/index.html
https://github.com/markqvist/reticulum
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.
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.
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
I built my own p2p software back in 2014 (https://firestr.com) and briar came out in 2015. Reticulum started in 2018.
Timing is the reason.
"Can I use the same account with several devices?"[1]
[1]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#can-i-...
Briar runs a Tor Onion Service on your device. I'm unsure how well Tor supports having multiple devices acting as the server. One option could be to have a main program that's always on, to which your messages are received, and other clients can then use the Onion Service to fetch a copy of the conversation. It would add another link in the chain and increase latency so I'm not surprised if that's not being done.
SimpleX has the same limitation. I hate how all those apps with modern networking or modern crypto can't get those important usability things right.
Identity is tied to the physical Bluetooth MAC if I recall correctly.
The BT MAC is shared with peers so they can find you (as well as a list of your IP addresses) but I don't think identity is tied to it. Identity seems entirely tied to a public certificate. But I could be wrong.
can't that be spoofed/overwritten?
Anyone tried https://getsession.org/ seriously?
- desktop and mobile clients, cross-platform (with an AppImage that installs on old systems)
- end to end encryption
- onion routing, based on the Oxen Service Nodes [0], which also propels Lokinet that allows to anonymously browse the web
- no phone number or email required
- group chats, voice messages, voice and video calls (webRTC), attachments, emojis
https://docs.oxen.io/oxen-docs/about-the-oxen-blockchain/oxe...
https://lokinet.org/
No forward secrecy in 2025.
Lokinet is tiny compared to Tor's 9229 nodes https://nusenu.github.io/OrNetStats/w/misc/all.html
The last time I checked, a lot of the nodes are just run in Hetzner's data centers meaning there's not too many actors. I can't even find that list anymore so if anyone has one, I'd like to update my knowledge.
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.
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!
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)
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.
Even now, when I see Briar's name anywhere, I think of this as "ah, that Android only app" and that imho is saying something for a privacy messaging app. I am not saying it has not reason (Apple's unsound, unfair, and consumer hostile tight control is the reason! [1]) to be Android only, I am just saying - it's very unfortunate and unfortunately defeating.
[1] In the name of privacy theatre which they have actually been able to defend by spending both on PR and lawyers.
iOS vs Android is a bit like ChromeOS vs Windows/MacOS/most Linux distros.
There are benefits to more restrictive operating systems. For example, iOS not allowing apps to run in the background essentially stops any apps with malware from doing stuff in the background, but it also stops apps like Briar, Syncthing, etc, from working well.
I assume Android isn't a problem for most Briar's users. They're likely running a deGoogled Android version (GrapheneOS, LineageOS, etc) and downloading/updating the app via F-Droid or something like that. They don't rely on Google (or Apple) to run anything.
The simple fact that you generally need to have Apple hardware to make iOS apps is a reason enough
Looks like a lot of it is JVM based, which makes it hard for iOS since they disallow running JITs.
I always think "Ah, that one E2EE chat app that made a cameo on Mr. Robot"
Yup, from what I hear, the problem is Apple doesn't allow process forking which means Tor would have to run inside the same process as the messaging app which is ridiculous.
Briar is a nice idea, but last time I used it I couldn't find peers, if memory serves. I tried adding a friend who was interested and we sat and waited for our messages. They never arrived.
In the end, we went back to using DeltaChat.
The idea is great, but the adoption rate is way to low for any P2P thing to actually work (unless with agreed upon meetings).
Meshtastic is a better option, because it uses LoRa (thus requires additional hardware), but with a good location, many kilometers can be covered and mesh networking extends this a lot further. Meshcore is supposedly the next "generation" of meshtastic, but not popular enough over here to actually test it.