[HN Gopher] Briar: Peer to Peer Encrypted Messaging
       ___________________________________________________________________
        
       Briar: Peer to Peer Encrypted Messaging
        
       Author : CobaltFire
       Score  : 393 points
       Date   : 2025-03-14 14:36 UTC (1 days 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.
        
           | mmwelt wrote:
           | Indeed, this is very much a limitation for _all_ apps on iOS
           | that don 't want to rely on centralised services, such as a
           | push notification server other than Apple's.
           | 
           | See also: https://developer.apple.com/forums/thread/685525
        
         | 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?
        
       | 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.
        
         | maqp wrote:
         | PGP stopped being the recommendation in 2004 when OTR became a
         | thing with its forward secrecy. I really do not get the charm
         | of repackaging PGP as a messenger, especially when it still has
         | no forward secrecy: https://delta.chat/en/help#pfs
         | 
         | I mean, if you're not using Tor, your IP and thus identity will
         | leak to the server anyway. So you should probably just use
         | Signal that has double ratchet giving you forward secrecy and
         | break-in key recovery.
         | 
         | Today, PGP's safest use-cases are digital signatures and
         | airgapped comms. But, you'd probably do the latter with TFC as
         | it has much better key/pt exfiltration guarantee.
        
       | 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
        
           | SubzeroCarnage wrote:
           | Briar is actually even older than that!
           | 
           | 2011:
           | https://sourceforge.net/p/briar/mailman/message/27393146/
        
         | 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.
        
           | SubzeroCarnage wrote:
           | Briar started in 2011:
           | https://sourceforge.net/p/briar/mailman/message/27393146/
        
         | 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
        
             | maqp wrote:
             | None of the given descriptions have been too clear about
             | what it is, though.
             | 
             | It appears to not be a drop-in solution for communication
             | like Briar, so why make a comparison here in the first
             | place?
             | 
             | Instead, it appears to be physical layer-agnostic (it
             | doesn't care if it's run over internet or HAM-radio)
             | infrastructure to build tools on top of. So,
             | 
             | * Is it an end-to-end encrypted overlay network like
             | corporate VPN/Tailscale/Hamachi?
             | 
             | * Is it an end-to-end encrypted protocol between two or
             | more endpoints like SSH?
             | 
             | * Is it an end-to-end encrypted messaging protocol between
             | two or more users like OTRv3?
             | 
             | The entire documentation returned zero results for "Tor" or
             | "onion" (routing), so what's the improvement over
             | Briar+Tor?
        
         | 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)
        
           | juunpp wrote:
           | 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).
        
       | 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.
        
           | 0xDEFACED wrote:
           | Briar offers a companion "mailbox" app for the exact reason
           | you describe (i assume)
           | 
           | where did you read that it hosts an onion service? i guessed
           | that's how it worked but couldn't find anything in their docs
           | that said so.
        
       | 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.
        
           | mmwelt wrote:
           | The problem is the networking effect. Since so many people
           | use iOS, even Android users often have to contact people on
           | iOS devices, resulting in Briar likely remaining very niche.
        
             | kragen wrote:
             | Very few people in my country use iOS devices. Maybe 5%.
        
       | 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.
        
         | tasuki wrote:
         | Not _seriously_ , no. But I was completely amazed by the UX:
         | get the app, create an account by clicking a button: no
         | email/phone nor any other "verification". Back up the seed
         | phrase so as not to lose your account. It just works!
        
       | 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.
        
           | LWIRVoltage wrote:
           | 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
        
         | mmwelt wrote:
         | 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
        
           | tough wrote:
           | There's AltStore sideloading, would that enable it?
        
             | ivanmontillam wrote:
             | It's not an issue of sideloading or censorship in iOS. It's
             | a product decision related to background apps (they kill
             | the running process with no recourse to bring it up again
             | on its own).
        
               | dlenski wrote:
               | As I understand it, only Apple's own apps get the magical
               | blessing to run in the background whenever they want.
        
               | gkbrk wrote:
               | Hmm, seems anti-competitive.
        
               | actionfromafar wrote:
               | Anti trust enforcement was tried briefly at the turn of
               | the century but was deemed unprofitable for oligarchs, so
               | it is no longer in fashion.
        
               | Georgelemental wrote:
               | Eh, it has seen a mini resurgence recently
        
               | mikepurvis wrote:
               | This affects other Bluetooth-using apps too, like the
               | Fitbit app needs to be periodically restarted in order to
               | get data synced from a tracker.
        
           | lostmsu wrote:
           | I actually have an app in iOS store that completely executes
           | in the background:
           | https://itunes.apple.com/app/id6737482921?mt=8
           | 
           | Never had it stopped by iOS. So not only there's no
           | fundamental restriction, the App Store itself allows some
           | apps to do that.
        
             | monocularvision wrote:
             | What API are you using to keep running in the background?
             | Most likely you are misusing it on some manner and have yet
             | to get caught by App Review.
        
               | idle_zealot wrote:
               | I've seen this bypassed via background audio and
               | background location.
        
               | lostmsu wrote:
               | The app does background audio, and its use is legitimate.
               | It is an audio app.
               | 
               | But the point is - there's no fundamental restriction
               | from the OS itself.
        
           | Zambyte wrote:
           | People have the power to not use iPhones, and should exercise
           | it.
        
             | doublerabbit wrote:
             | Okay, buy me an Android then.
        
               | ParetoOptimal wrote:
               | If you bought an iPhone you could buy an Android.
        
               | doublerabbit wrote:
               | But I don't want an Android. So if you desire for me to
               | use Android, buy me an Android.
        
             | ctm92 wrote:
             | Switching ecosystems is a huge pain, I started with iPhone
             | and eventually moved to Android and back again to iPhone.
             | When you use a lot of the Apple/Google Services, it's not
             | really easy to just switch over
        
         | lhamil64 wrote:
         | 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.
        
           | myself248 wrote:
           | 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...
        
         | stevenwalton wrote:
         | >  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.
         | 
         | https://community.signalusers.org/t/signal-airdrop/37402
        
       | 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.
        
         | 9dev wrote:
         | 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.
        
           | maqp wrote:
           | Oh Cwtch is like Cutch, and like the project says, the word
           | rhymes with "butch".
        
         | zelphirkalt wrote:
         | 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.
        
       | 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
           | :)
        
             | N2yhWNXQN3k9 wrote:
             | > Other phones with Briar installed can carry your
             | (encrypted) messages
             | 
             | Sounds like an excellent target for DoS
        
               | AnthonyMouse wrote:
               | DoS by local users on local networks? This is that thing
               | where you solve the cryptography problem with the $5
               | wrench but only slightly different, right?
        
             | 7373737373 wrote:
             | > This works best if enough people between you and the
             | recipient had [...] installed ... but most people don't.
             | 
             | Which is why it would be nice if operating systems already
             | included such functionality
        
             | Velocifyer wrote:
             | This is not true, unless you are all in one big fourm or
             | you have a chain of shared blogs. I think they are woried
             | about metadata privacy or people using this to do a DoS.
        
           | beefnugs wrote:
           | 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"
           | 
           | Coming to a country near you soon
        
             | DonsDiscountGas wrote:
             | Right but Bluetooth and local Wi-Fi are very short range so
             | it doesn't actually solve that problem
        
               | Charon77 wrote:
               | It does if you consider that everyone can act as a relay.
               | 
               | This is also how apple airtags can be find anywhere
               | there's an iphone users nearby.
        
               | idiotsecant wrote:
               | I haven't studied the protocol but that seems like it has
               | some...obvious routing issues.
               | 
               | Airtags have a totally different architecture than what
               | this protocol is describing, I think.
        
               | dlenski wrote:
               | > I haven't studied the protocol but that seems like it
               | has some...obvious routing issues.
               | 
               | Yes indeed. I don't understand how the peer-to-peer
               | relaying can possibly scale without some directed routing
               | algorithm.
               | 
               | If my phone running Briar is literally handing off every
               | as-yet-undelivered message to every other phone running
               | Briar, we're going to pretty quickly become overwhelmed.
               | 
               | It'll have all the routing issues of a Wi-Fi mesh
               | network, except at a vast scale. https://en.wikipedia.org
               | /wiki/Wireless_ad_hoc_network#Briar
        
               | dlenski wrote:
               | > It does if you consider that everyone can act as a
               | relay.
               | 
               | Let's think this through. Imagine civil war breaks out in
               | Australia, and communications infrastructure is destroyed
               | or shut off. I'm in Sydney and want to transmit a message
               | to a friend in Perth.
               | 
               | How exactly is "everyone acts as a relay" going to work?
               | In particular, how is it going to _scale_ when everyone
               | in the country is trying to do the same things?
               | 
               | > This is also how apple airtags can be find anywhere
               | there's an iphone users nearby.
               | 
               | This is incorrect. Airtags (and the Google version)
               | communicate with nearby _Internet-connected_ devices, via
               | Bluetooth and NFC I think. Those nearby _Internet-
               | connected_ devices send the airtag 's location to a
               | server.
               | 
               | Nothing about this would work without the Internet.
        
               | traceroute66 wrote:
               | > Airtags (and the Google version) communicate with
               | nearby Internet-connected devices, via Bluetooth and NFC
               | I think
               | 
               | Yes, exactly (BLE, UWB, NFC).
               | 
               | First, Airtags only have a coin-cell battery. It is not
               | remotely viable for them to be doing any sort of serious
               | "communicating" because the battery would die in seconds.
               | 
               | Second, making the Airtag effectively a dumb device means
               | you gain the various security and privacy benefits, and
               | means everything needed to make the magic happen can be
               | transmitted in a single BLE/UWB/NFC packet (bringing us
               | back to the battery life aspect already mentioned).
               | 
               | 30,000ft view of how it works:
               | https://support.apple.com/en-
               | gb/guide/security/sece994d0126/...
        
               | LikeBeans wrote:
               | Yeah, I think current tech assumes a server relay.
               | However imo, and if I were to imagine a solution, in this
               | case I think a message would need a ttl, say 24 hours. In
               | a local mesh/hive everyone would store a copy of the
               | undelivered messages. When people move between hives they
               | would sync these undelivered messages where ttl didn't
               | expire. With perhaps a storage limit of say 1k
               | undelivered messages. Undelivered means a destination
               | user that didn't show in a hive. Wdyt?
        
         | bloomingkales wrote:
         | It is very much in the bingo cards that internet gets shut off
         | in America as an extension of strong-arm policies.
        
           | cannonpalms wrote:
           | You mean the substrate of our entire economic engine? I think
           | that's a bit dramatic.
        
             | kragen wrote:
             | What, like free trade?
        
             | jazzyjackson wrote:
             | Parent didn't say all the internet at once, it could just
             | be a matter of telling telecoms to block connections within
             | certain geofences when protests start to flare up, Egypt
             | 2011 style.
             | 
             | Could even bring down 4G services while whitelisting POS
             | terminals, keep the Starbuckses up and running.
        
           | dlenski wrote:
           | I dunno why you're getting downvoted so much.
           | 
           | 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.
        
         | stevenwalton wrote:
         | 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.
         | 
         | [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.
        
           | kragen wrote:
           | > _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_
           | 
           | Sideloading an .apk is supported in all Android versions,
           | right? Even without internet access? Is something more needed
           | to install Briar?
        
             | stevenwalton wrote:
             | Sure, but this doesn't really scale very well. Distributing
             | those APKs without internet access is pretty hard.
        
               | ruined wrote:
               | you can distribute it via the same mechanism which
               | distributes your messages
        
               | eredengrin wrote:
               | Briar already has this built in via the "Share this app
               | offline" feature. It starts a wifi hotspot from which
               | people can download the apk.
        
               | folmar wrote:
               | Also Fdroid has support for local distribution and
               | discovery for offline scenarios.
        
         | miohtama wrote:
         | Firechat did meshed WiFi during 2014 Hong Kong protests
         | 
         | https://www.theguardian.com/world/2014/sep/29/firechat-messa...
         | 
         | China went to hard mode to kill the app.
        
         | myself248 wrote:
         | 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.
        
           | pferde wrote:
           | 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.
        
             | myself248 wrote:
             | Nope, same issue myself.
             | 
             | I find it fascinating to read about, but it seems to have a
             | steep and very slippery social hill to climb before the
             | technical parts of the network do anything.
        
       | jszymborski wrote:
       | Not immediately apparent to me: does Briar use a double-ratchet
       | these days?
        
         | makeworld wrote:
         | I'm not sure, a quick search of the specs don't mention
         | "ratchet". But it does claim to have forward secrecy so it
         | should be good anyway.
        
       | fdb345 wrote:
       | Briar was funded by the CIA. Partly.
        
         | johnisgood wrote:
         | Source?
        
           | jazzyjackson wrote:
           | I haven't heard this particular rumor, not like they have In-
           | Q-Tel connections a la Wickr, but they do take funding from
           | the Open Technology Fund [0] which some of the more
           | righteously paranoid take issue with, being US State
           | Department and all. Same parent as Radio Free Asia, Radio
           | Free Europe, Voice of America [1].
           | 
           | [0] https://briarproject.org/news/2018-1.0-released-new-
           | funding/
           | 
           | [1]
           | https://en.m.wikipedia.org/wiki/U.S._Agency_for_Global_Media
        
             | johnisgood wrote:
             | Do we have any reasons for concern?
             | 
             | The source code is available here:
             | https://code.briarproject.org/briar/briar/tree/master
        
         | dustyharddrive wrote:
         | If this is about OTF, do you also distrust Let's Encrypt,
         | Quad9, Tails, F-Droid, Signal, and Tor?
        
       | 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)
        
       | jumploops wrote:
       | I once built a version of this that strictly allowed you to add
       | contacts via QR code only.
       | 
       | The idea was simple: you can only exchange keys in person,
       | therefore no central server involvement at all.
        
         | jazzyjackson wrote:
         | Tin Foil Chat is in this variety - mailboxes are tor hidden
         | services identified by their public key.
         | 
         | https://github.com/maqp/tfc
        
           | maqp wrote:
           | Well not quite :) Wrt what upper post said:
           | 
           | It used to be the case you could only exchange keys in
           | person, but X25519 was introduced in 2016, and it was bumped
           | to X448 in 2019. You can of course still exchange PSKs as
           | it's currently the only post-quantum key exchange it can
           | offer. QR-codes are not used, instead, imported strings are
           | split into small segments that are typed manually. The
           | program then does what it can do, to help the user identify
           | typos.
        
         | thomasdeleeuw wrote:
         | I did something similar, share contact via QR code, offline,
         | but with a dedicated encryption/decryption device to realize
         | the airgap: www.qryptr.com
        
       | 2Gkashmiri wrote:
       | Does this still require signup to their server before using p2p
       | app ? Meaning it cant be shared offline and used ?
        
         | ivanmontillam wrote:
         | As per their website, the account is local to the phone.
         | 
         | It just cannot be backed up, unfortunately.
        
       | reffaelwallen wrote:
       | Logo reminds me of the old slack logo
        
       | keepamovin wrote:
       | The threat model is excellent, except: "The adversary can't break
       | standard cryptographic primitives"
       | 
       | Let's assume they can and you can swap in non standard crypto
       | models to frustrate and vex 'the adversary.' (Lol: "the
       | adversary"... religious)
       | 
       | More info, the threat model:                 All long-range
       | communication channels (internet, phone network, etc) are
       | comprehensively monitored by the adversary.            The
       | adversary can block, delay, replay and modify traffic on long-
       | range communication channels.            The adversary has a
       | limited ability to monitor short-range communication channels
       | (Bluetooth, WiFi, etc).            The adversary has a limited
       | ability to block, delay, replay and modify traffic on short-range
       | communication channels.            The adversary can deploy an
       | unlimited number of devices running Briar.            There are
       | some users who can keep their devices secure - those who can't
       | are considered, for the purposes of the threat model, to be
       | controlled by the adversary.            The adversary has a
       | limited ability to persuade users to trust the adversary's agents
       | - thus the number of social connections between the adversary's
       | agents and the rest of the network is limited.            The
       | adversary can't break standard cryptographic primitives
        
         | schoen wrote:
         | "The adversary" is standard terminology in analyzing
         | cryptographic security.
         | 
         | It would be interesting to figure out who introduced it. I
         | looked briefly on Google Scholar, and I see it's used in the
         | modern sense as early as Yao (1982), but it might have been
         | used much earlier. It doesn't appear in the Diffie-Hellman
         | (1976) or RSA (1977) papers.
        
           | keepamovin wrote:
           | Well either way it's an appropriate name, lol!
        
         | maqp wrote:
         | >The threat model is excellent, except: "The adversary can't
         | break standard cryptographic primitives"
         | 
         | >Let's assume they can
         | 
         | Let's not.
         | 
         | The weak key sizes (<90 bits), broken primitives (SHA-1, MD5,
         | DES), and weak modes of operation (ECB, unauthenticated CBC)
         | are all known.
         | 
         | We know the Grover cuts symmetric key sizes in roughly half,
         | and we know Shor will break classical asymmetric algorithms, so
         | the industry is upping key sizes and moving into hybrid schemes
         | that add post-quantum algorithms.
         | 
         | >non standard crypto models
         | 
         | Here's a thought: Submit your primitive (the rainstorm hash
         | function) into the SHA-4 competition whenever it's due, and win
         | it, or at least become a finalist. Then you don't have to sell
         | it to serious projects as security through obscurity.
         | 
         | Surely you realize Briar is open source so the implementation
         | of your hash function will be available to the attacker, and
         | they can perform cryptanalysis on it to their heart's content?
         | So you can't really get over the fact it needs attention from
         | the professionals.
         | 
         | If you want to be taken seriously, maybe start by improving on
         | attacks over existing algorithms? That distinguishes you from
         | the random cranks who think they've come up with improved
         | schemes.
        
           | keepamovin wrote:
           | It seems insufficiently secure to just trust that the people
           | who designed the ciphers you use, and who also are
           | responsible for breaking ciphers at state-level, would tell
           | you if they could break those ciphers. Hahaha :)
        
             | maqp wrote:
             | Ok so you have no idea who's vetting the algorithms at
             | competitions. It's the other participants. That's going to
             | be you among others. You get to break apart all the
             | competing algorithms that claim to be better than yours.
             | And they get to show you if yours is the weaker one, as
             | they also want to win the competition.
             | 
             | Sure, you can't put fox to guard the henhouse that's how
             | you get stuff like DUAL_EC. But that's not the case in
             | modern competitions. They are open to the public, and
             | academic in nature. Everyone gets to analyze them.
             | 
             | We don't know who you are, what are your credentials, and
             | we don't have any proof of you showing you have what it
             | takes to analyze current standards, let alone create new
             | primitives resistant to cryptanalysis. Until you decide go
             | the long way, you'll find yourself treated as yet another
             | Crown Sterling.
        
               | keepamovin wrote:
               | I love your enthusiasm for this, have a good weekend!
        
       | kragen wrote:
       | It's on F-Droid. I hadn't realized it supported message-passing
       | over Bluetooth like FireChat! Not just Tor.
        
       | dav wrote:
       | I spent a little time ~2012 trying to think how to create a
       | system like this that would work with iPhones at burning man.
       | Never really got anywhere with the idea, but I'm excited to try
       | this!
        
       | jeffparsons wrote:
       | Serious question for whoever actually understands this: what is
       | the legal status of true, peer-to-peer, attack-resistant
       | encrypted messaging in the "western" world? I'm particularly
       | interested in the USA, the UK, Australia, New Zealand, and
       | whatever European countries you care to throw into the mix.
       | 
       | I've occasionally tinkered with building software (but never
       | released said software) that uses encrypted peer-to-peer
       | connections as the _sole_ way of communicating, because it seemed
       | like the most natural way to build said software _and_ the most
       | interesting technically. (And I have zero interest in hosting
       | servers for FOSS side projects.) If I were to actually release
       | one of these projects and it were to become popular, should I
       | expect to be shut down by law enforcement on the grounds that
       | it's already unambiguously illegal? Or would I likely receive a
       | "Technical Assistance Notice" at some point, effectively
       | requiring me to sneak a back door into the software? Or is it
       | actually fine?
       | 
       | I seem to recall all sorts of stories about law enforcement and
       | "TLA agencies" pressuring vendors of secure messaging software to
       | make the software unavailable or to add back doors, including at
       | least one who chose to shut down their business rather than lying
       | to their users about the security of the product. But somehow in
       | all this I failed to glean whether or not it's actually meant to
       | be legal, even on paper.
        
         | WorldPeas wrote:
         | I would look into wassenar if I were you, an artifact of the
         | cold war, encryption can be treated like a munition. Nothing
         | stricter than that from what I've seen. Yet.
        
         | gardnr wrote:
         | In the Five-eyes jurisdiction, it is legally allowed to use
         | strong end-to-end encryption. Any potential laws that are
         | contrary to that would come up against some serious 4th
         | amendment issues. The idea of cryptography as a munitions was
         | largely set aside in the name of capitalism.
         | 
         | Tor was funded by the U.S. Department of State. Signal and
         | WhatsApp are end to end encrypted.
         | 
         | Sign up for EFF's mailing list and donate money to them. Check
         | out their Secure Messaging Scorecard:
         | https://www.eff.org/pages/secure-messaging-scorecard
         | 
         | We, as a society, are under constant attacks on our ability to
         | maintain our privacy. As we've seen in large political and
         | technological shifts, it only becomes more important to
         | maintain your privacy. Deep fakes used in scamming relatives is
         | one good example.
         | 
         | Please do release your software and ideas that make information
         | more secure.
        
         | GoblinSlayer wrote:
         | Encryption for end users is de facto legal almost everywhere
         | except for UK. For vendors it's illegal almost everywhere maybe
         | except for USA, but that's just how the law works in USA: you
         | receive a subpoena, then it's up to your luck.
        
           | flimflamm wrote:
           | Not illegal in Finland at least.
        
             | GoblinSlayer wrote:
             | Oh and proton mail brags that Swiss allows it too.
        
             | miohtama wrote:
             | Mullvad is Swedish and they run no logs VPN so not illegal
             | there
        
               | anonym29 wrote:
               | Curious as to whether Mullvad will respond the same way
               | Signal did to Sweden's assault on E2EE.
               | 
               | https://www.theregister.com/2025/02/26/signal_will_withdr
               | aw_...
        
           | cornholio wrote:
           | It's not illegal for vendors, they just have to colaborare
           | with law enforcement when a subpoena is received, and this
           | collaboration can entail attacking their own users as long as
           | a technical capability to do so exists.
           | 
           | If you think about it, it's more or less the only way this
           | could work in any democratic society.
        
           | traceroute66 wrote:
           | > Encryption for end users is de facto legal almost
           | everywhere except for UK.
           | 
           | Encryption is legal in the UK.
           | 
           | But if the government turns up asking for your decryption
           | keys, "you can't have them" is not an option unless you wish
           | to enjoy the luxurious surrounds of a prison cell until you
           | change your mind.
           | 
           | Which, to be fair, is basically the case worldwide, as per
           | the famous XKCD cartoon[1].
           | 
           | [1] https://xkcd.com/538/
        
             | actionfromafar wrote:
             | That's a huge simplification.
             | 
             | If you don't have they keys, you can't hand them over, for
             | one thing.
             | 
             | Also, the wrench treatment is extremely unlikely in most
             | democracies. Now, deplatforming such as seizure of DNS
             | names and such, is another matter and varies, often
             | orthogonally to the risk of wrench treatment.
        
               | traceroute66 wrote:
               | > the wrench treatment is extremely unlikely in most
               | democracies
               | 
               | If you prefer ... substitute "wrench treatment" for the
               | democratic wording: "jail time and the associated
               | criminal prosecution process"
        
               | actionfromafar wrote:
               | Where has this happened? For using encryption? Or what
               | are we talking about here?
        
             | woctordho wrote:
             | There's deniable encryption to counter the wrench attack
        
               | traceroute66 wrote:
               | > There's deniable encryption to counter the wrench
               | attack
               | 
               | The trouble with deniable encryption is its viable use-
               | case is very narrow.
               | 
               | It is, for example, not viable to use deniable encryption
               | when exchanging messages with others.
               | 
               | If the authorities, through whatever means, get the a
               | copy of an encrypted message you sent, and they have done
               | sufficient metadata homework to link it back to you, find
               | your address and come knock on your door, then you are
               | going to seriously struggle with a deniable encryption
               | defence.
        
         | IlikeKitties wrote:
         | I know of no law here in Germany that would make it illegal,
         | heck, Germany allows me to sign my PGP Key with my National ID.
         | There has been some conservative resistance over the years but
         | it's still legal and in practice for the normal user simply not
         | an issue. Unless you are using things like Anom or other
         | messengers that are like exlusively used by criminals and even
         | it's not illegal in itself you might at worst get caught up in
         | a sting operation when they take down the central servers.
         | 
         | Fun fact most Tor exit nodes are in Germany. Hosting those is
         | more risky.
        
           | GoblinSlayer wrote:
           | I heard tutanota collaborates with German law enforcement for
           | decryption.
        
             | EGG_CREAM wrote:
             | Heard from where? How would they do that? Tutanota doesn't
             | have the key, the end user does. I keep hearing weird
             | things about Turanota that sound like the types of rumors
             | intelligences agencies who really don't want people to use
             | the service would start.
        
         | bboygravity wrote:
         | end-to-end encrypted messagess, when the end-points (Android,
         | iOS, Windows, etc) are basically spyware?
         | 
         | On top of that it runs through servers running who knows what,
         | closed source stuff. So who knows if they're somehow decrypting
         | everything on there before forwarding re-encrypted stuff?
        
           | WorldPeas wrote:
           | fair point, when someone's using google push notification
           | service and gboard, that's both ends of the pipe, for the
           | most part
        
       | ein0p wrote:
       | 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.
        
       | rmac wrote:
       | love briar!!! please add p2p discovery / pairing without qr-code
        
       ___________________________________________________________________
       (page generated 2025-03-15 23:00 UTC)