Briar: Peer to Peer Encrypted Messaging

What's the use case? I'm assuming one is trying to send a message to someone far away so it seems like the alternatives wouldn't necessarily help.

It is very much in the bingo cards that internet gets shut off in America as an extension of strong-arm policies.

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.

[1] https://developer.apple.com/forums/thread/685525

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.

> 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:

  markqvist/Reticulum: Apr 4, 2018
  briar/briar: Nov 9, 2015

Kind of funny that you think running python on your smartphone is easier than the "reinvented" app. (Also, briar is older and had several audits)

> Reticulum network

https://reticulum.network/index.html

https://github.com/markqvist/reticulum

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

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 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.

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.

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.

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.

Yes, Session seems nice. For hard-core privacy people, use Ricochet Refresh, other than that, Briar and Session are great.

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.

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.