My wife and I use Briar for household communication because of subsidiarity rather than any direct privacy concerns. Out of all the messenger projects that we've tried, Briar actually <i>works</i> for local communication. It's <i>actually</i> instant messaging without any client hiccups or latency (looking at you, Signal). We've tried a ton of other options, but we keep ending up back at Briar.<p>There <i>are</i> points of UX friction in the name of good opsec that are inconvenient but totally understandable given the project goals. The big ones being that you have to manually login after any reboots and notifications are intentionally sparse, so good luck using a smartwatch for reading or replying. Otherwise, the forums and blogs are great for managing household projects, IM is a dream, and as a bonus, anyone willing to install and use it probably has a large enough values overlap that we can use it as a social pre-filter for close friends.<p>The only other option that has come even remotely close to being as functional as Briar is DeltaChat. The only issue that stops us from using DeltaChat (or email in general) is that we both have email hosting in Europe while we live in the US, so neither of us, being frugal in principal, wants to send information to Europe and back in order to tell the person 100 ft away to come help bring in the groceries.
Just wanna say this app saved my family and I when we went on a cruise. Normally, we would had had to pay to use the chat service via the ship's paid-only Wi-Fi (since we get no phone reception on the seas). Without needing to pay for the Wi-Fi, we were all able to use Briar to communicate whilst connected to the network, which made coordinating and finding each other on the ship way easier. It was great and worked really well. So thanks, Briar!
Briar's "F-Droid" installation option wants you to add a new package distribution repo to the F-Droid app.<p>Rather than the usual way, which is to have F-Droid verify the source build of each version, and distribute through the official F-Droid repo.<p>(And normally that "Get it on F-Droid" button links to F-Droid's page for the app, rather than to another page of the project.)
I am waiting for Matrix's P2P support, once its out, its going to crush everything else.<p>Supposedly its should come out with the improved mobile apps too, which are sorely needed.
Building a completely p2p (no servers) e2ee messaging app is not hard except one big problem: contacts discovery. I looked through briar website and it seems the solution is to constantly ping all contacts and hope that everyone is online plus at least one of IPs stays the same between pings. Did I miss something more interesting?
The biggest privacy problem of Briar is it requires iOS or Android to use.<p>If you cannot control your endpoint, you cannot control your keys or your privacy.<p>Briar will become useful to me when it can run on open platforms like a Pinephone, Librem 5, Precursor, etc.
Briar is one of the most important secure messaging projects currently. Not only does it remove the need to trust the vendor about content (like with all E2EE messaging apps), you also get to keep the metadata about communication to yourself as data transits from one Tor Onion Service to another.<p>The downside is of course, you need to keep the endpoint powered on when you want to be reachable so it will increase the battery drain on your phone.<p>Note: There's also a desktop client if that's easier to keep online <a href="https://briarproject.org/download-briar-desktop/" rel="nofollow">https://briarproject.org/download-briar-desktop/</a><p>One extremely important thing Briar is doing, is it's using the P2P as means to host alternative social interaction formats, like forums and blogs. Similar to Signal/WhatsApp stories (which is somewhat similar to microblogs/FB wall), it's a way to indirectly share information. You could pretty much emulate any social media platform on top of E2EE protocol with ~zero infrastructure cost and without having to worry about data mining. I'd argue what Briar's innovating on here is one of the most important aspects in what's left for secure messaging.<p>Finally a small caveat: Briar will share your Bluetooth MAC address with all peers so it can automatically use that when you're in close proximity with your peer. Thus sharing your Briar ID publicly is not a good idea for two reasons:<p>1) major global adversaries may have access to the leaking Bluetooth MAC (e.g. if Google aggregates it) which can deanonymize your account. This also allows slightly technical person to confirm identity of briar account if they suspect it's you (a bit wonky threat model but still).<p>2) it ties everything you do across your accounts on same device together, so there's strong linkability even if you rotate the identity key by reinstalling the app.<p>Briar is pretty clear about this in it's FAQ, but it's still not very well known although it definitely should be.<p>---<p>That being said, if you want similar Onion Service based communication with no such linkability, there's <a href="https://cwtch.im/" rel="nofollow">https://cwtch.im/</a> which is a fantastic project.<p>There's also <a href="https://www.ricochetrefresh.net/" rel="nofollow">https://www.ricochetrefresh.net/</a><p>Both are spiritual successors to John Brooks' `Ricochet` application which pioneered the whole Onion Service based instant messaging in 2014.<p>You can also chat and share files (among other things) with <a href="https://onionshare.org/" rel="nofollow">https://onionshare.org/</a><p>(And finally, you can get remote exfiltration security for keys/plaintexts with TFC <a href="https://github.com/maqp/tfc" rel="nofollow">https://github.com/maqp/tfc</a> (my personal work), at the cost of losing some features like message forwarding etc that the architecture prevents you from doing.)
Note: on iOS's App Store searching for Briar shows Signal for me.<p><a href="https://i.imgur.com/5YiR1Xk.jpg" rel="nofollow">https://i.imgur.com/5YiR1Xk.jpg</a>
Since the protocol appears to use adhoc synchronization, the authors might be interested in <a href="https://github.com/sipa/minisketch/" rel="nofollow">https://github.com/sipa/minisketch/</a> which is a library that implements a data structure (pinsketch) that allows two parties to synchronize their sets of m b-bit elements which differ by c entries using only b*c bits. A naive protocol would use m*b bits instead, which is potentially much larger.<p>I'd guess that under normal usage the message densities probably don't justify such efficient means-- we developed this library for use in bitcoin targeting rates on the order of a dozen new messages per second and where every participant has many peers with potentially differing sets--, but it's still probably worth being aware of. The pinsketch is always equal or more efficient than a naive approach, but may not be worth the complexity.<p>The somewhat better known IBLT data structure has constant overheads that make it less efficient than even naive synchronization until the set differences are fairly large (particular when the element hashes are small); so some applications that evaluated and eschewed IBLT might find pinsketch applicable.
Related: Are there any standards, APIs, best practices for p2p peer discovery?<p>I found this <a href="https://github.com/status-im/bigbrother-specs/blob/master/data_sync/p2p-data-sync-comparison.md" rel="nofollow">https://github.com/status-im/bigbrother-specs/blob/master/da...</a> (mentions Gossip and Kademlia) but it is several years old and doesn't contain much info on peer discovery.
Keet (still in Alpha) is also doing P2P encrypted messaging (and video calls).<p><a href="https://keet.io/" rel="nofollow">https://keet.io/</a>
Well... P2P isn't the best when it comes to messaging <a href="https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SIMPLEX.md#comparison-with-p2p-messaging-protocols" rel="nofollow">https://github.com/simplex-chat/simplex-chat/blob/stable/doc...</a>
> The adversary has a limited ability to monitor short-range communication channels (Bluetooth, WiFi, etc).<p>That seems like a pretty big assumption. From what i understand there already exists deployment of wifi hot spots to track people (both for advertising purposes and for spying purposes) to the extent that phone providers started radomizing MAC addresses.
You can verify identities in person by scanning a QR code. That's completely solid. Otherwise you can send someone a link. It should be made clearer in the documentation that that link might end up with someone other than who you expect and the potential downside of that.
What I find interesting is that such p2p comms applications return with a certain recurrence. I think one of the first was Nokia Sensor (2005?), and there was one that was famous during the Arab Spring/Hong Kong protests.