[HN Gopher] Briar: Peer to Peer Encrypted Messaging
       ___________________________________________________________________
        
       Briar: Peer to Peer Encrypted Messaging
        
       Author : CobaltFire
       Score  : 150 points
       Date   : 2025-03-14 14:36 UTC (8 hours ago)
        
 (HTM) web link (briarproject.org)
 (TXT) w3m dump (briarproject.org)
        
       | ajr0 wrote:
       | 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?
        
         | CobaltFire wrote:
         | 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.
        
         | unethical_ban wrote:
         | 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.
        
         | tredre3 wrote:
         | They explain the iOS situation here:
         | https://code.briarproject.org/briar/briar/-/wikis/FAQ#will-t...
        
           | throwawayq3423 wrote:
           | Is there an iOS alternative?
        
         | ploum wrote:
         | People looking for insanely secure messaging to run on a
         | proprietary backdored devices.
        
           | VertanaNinjai wrote:
           | I'm not sure where you're pulling "backdoored" from, but if
           | Apple markets their devices as private then it seems
           | reasonable that end users expect a private device.
        
             | johnisgood wrote:
             | > if Apple markets their devices as private then it seems
             | reasonable
             | 
             | Not really.
        
       | hkt wrote:
       | 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.
        
       | Calwestjobs wrote:
       | 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" ?
        
         | pona-a wrote:
         | > 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
        
         | genpfault wrote:
         | > Reticulum network
         | 
         | https://reticulum.network/index.html
         | 
         | https://github.com/markqvist/reticulum
        
         | mempko wrote:
         | 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.
        
         | notepad0x90 wrote:
         | 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.
        
         | jeroenhd wrote:
         | 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.
        
           | Erethon wrote:
           | 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
        
         | Karrot_Kream wrote:
         | 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.
        
         | sunshine-o wrote:
         | 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
        
         | h4ck_th3_pl4n3t wrote:
         | 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)
        
       | genpfault wrote:
       | "Can I use the same account with several devices?"[1]
       | 
       | [1]:
       | https://code.briarproject.org/briar/briar/-/wikis/FAQ#can-i-...
        
         | remram wrote:
         | 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.
        
         | HeatrayEnjoyer wrote:
         | Identity is tied to the physical Bluetooth MAC if I recall
         | correctly.
        
           | taskforcegemini wrote:
           | can't that be spoofed/overwritten?
        
           | tredre3 wrote:
           | 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.
        
         | maqp wrote:
         | 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.
        
       | crossroadsguy wrote:
       | 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.
        
         | forty wrote:
         | The simple fact that you generally need to have Apple hardware
         | to make iOS apps is a reason enough
        
           | vips7L wrote:
           | Looks like a lot of it is JVM based, which makes it hard for
           | iOS since they disallow running JITs.
        
         | maqp wrote:
         | 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.
        
         | jszymborski wrote:
         | I always think "Ah, that one E2EE chat app that made a cameo on
         | Mr. Robot"
        
         | celsoazevedo wrote:
         | 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.
        
       | mempko wrote:
       | 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!
        
       | vindarel wrote:
       | 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/
        
         | maqp wrote:
         | 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.
        
         | johnisgood wrote:
         | Yes, Session seems nice. For hard-core privacy people, use
         | Ricochet Refresh, other than that, Briar and Session are great.
        
       | LWIRVoltage wrote:
       | 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)
        
         | Karrot_Kream wrote:
         | 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.
        
       | maqp wrote:
       | 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.
        
       | gunalx wrote:
       | 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
        
         | aryan14 wrote:
         | Are the typos on purpose for opsec reasons?
        
       | ajsnigrutin wrote:
       | 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.
        
       | apitman wrote:
       | > 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.
        
         | DonsDiscountGas wrote:
         | 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.
        
           | rsolva wrote:
           | 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
           | :)
        
         | bloomingkales wrote:
         | It is very much in the bingo cards that internet gets shut off
         | in America as an extension of strong-arm policies.
        
       | jszymborski wrote:
       | Not immediately apparent to me: does Briar use a double-ratchet
       | these days?
        
       | fdb345 wrote:
       | Briar was funded by the CIA. Partly.
        
         | johnisgood wrote:
         | Source?
        
       | dang wrote:
       | Related:
       | 
       |  _Confronting Briar with Disasters_ -
       | https://news.ycombinator.com/item?id=39174518 - Jan 2024 (2
       | comments)
       | 
       |  _Briar Mailbox released to improve connectivity_ -
       | https://news.ycombinator.com/item?id=36541798 - June 2023 (11
       | comments)
       | 
       |  _Indian government bans 14 messenger apps including Element,
       | Briar and Threema_ -
       | https://news.ycombinator.com/item?id=35769203 - May 2023 (78
       | comments)
       | 
       |  _Briar: Peer-to-Peer Encrypted Messaging_ -
       | https://news.ycombinator.com/item?id=33686094 - Nov 2022 (141
       | comments)
       | 
       |  _Briar Project - Secure messaging, everywhere_ -
       | https://news.ycombinator.com/item?id=33412171 - Oct 2022 (7
       | comments)
       | 
       |  _Briar has been removed from Google Play_ -
       | https://news.ycombinator.com/item?id=30498924 - Feb 2022 (85
       | comments)
       | 
       |  _Briar Desktop for Linux_ -
       | https://news.ycombinator.com/item?id=30023169 - Jan 2022 (84
       | comments)
       | 
       |  _Briar 1.4 - Offline sharing, message transfer via SD cards and
       | USB sticks_ - https://news.ycombinator.com/item?id=29227754 - Nov
       | 2021 (110 comments)
       | 
       |  _Briar Project_ - https://news.ycombinator.com/item?id=24031885
       | - Aug 2020 (185 comments)
       | 
       |  _Briar and Bramble: A Vision for Decentralized Infrastructure_ -
       | https://news.ycombinator.com/item?id=18027949 - Sept 2018 (11
       | comments)
       | 
       |  _Briar Project_ - https://news.ycombinator.com/item?id=17888920
       | - Aug 2018 (10 comments)
       | 
       |  _Darknet Messenger Briar Releases Beta, Passes Security Audit_ -
       | https://news.ycombinator.com/item?id=14825019 - July 2017 (85
       | comments)
       | 
       |  _Is Briar really the next step of the crypto messenger
       | evolution?_ - https://news.ycombinator.com/item?id=11690607 - May
       | 2016 (1 comment)
        
       | dang wrote:
       | I guess the current thread and this other ongoing one are duals:
       | 
       |  _Cwtch - Privacy Preserving Messaging_ -
       | https://news.ycombinator.com/item?id=43367012 - March 2025 (21
       | comments)
        
       ___________________________________________________________________
       (page generated 2025-03-14 23:00 UTC)