-
berty
Berty is a secure peer-to-peer messaging app that works with or without internet access, cellular data or trust in the network
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
OnionShare
Securely and anonymously share files, host websites, and chat with friends using the Tor network
-
-
simplex-chat
SimpleX - the first messaging network operating without user identifiers of any kind - 100% private by design! iOS, Android and desktop apps 📱!
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
yosemite-phone-home
Corpus of data automatically shared with Apple by a standard installation of OS X Yosemite.
Check out https://berty.tech for direct off network communications.
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.
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.
Note: There's also a desktop client if that's easier to keep online https://briarproject.org/download-briar-desktop/
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.
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:
1) major global adversaries may have access to that information (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).
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.
Briar is pretty clear about this in it's FAQ, but it's still not very well known although it definitely should be.
---
That being said, if you want similar Onion Service based communication with no such linkability, there's https://cwtch.im/ which is a fantastic project.
There's also https://www.ricochetrefresh.net/
Both are spiritual successors to John Brooks' `Ricochet` application.
You can also chat and share files (among other things) with https://onionshare.org/
(And finally, you can get remote exfiltration security for keys/plaintexts with TFC https://github.com/maqp/tfc (my personal work), at the cost of losing some features like message forwarding etc that the architecture prevents you from doing.)
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.
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.
Note: There's also a desktop client if that's easier to keep online https://briarproject.org/download-briar-desktop/
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.
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:
1) major global adversaries may have access to that information (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).
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.
Briar is pretty clear about this in it's FAQ, but it's still not very well known although it definitely should be.
---
That being said, if you want similar Onion Service based communication with no such linkability, there's https://cwtch.im/ which is a fantastic project.
There's also https://www.ricochetrefresh.net/
Both are spiritual successors to John Brooks' `Ricochet` application.
You can also chat and share files (among other things) with https://onionshare.org/
(And finally, you can get remote exfiltration security for keys/plaintexts with TFC https://github.com/maqp/tfc (my personal work), at the cost of losing some features like message forwarding etc that the architecture prevents you from doing.)
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.
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.
Note: There's also a desktop client if that's easier to keep online https://briarproject.org/download-briar-desktop/
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.
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:
1) major global adversaries may have access to that information (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).
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.
Briar is pretty clear about this in it's FAQ, but it's still not very well known although it definitely should be.
---
That being said, if you want similar Onion Service based communication with no such linkability, there's https://cwtch.im/ which is a fantastic project.
There's also https://www.ricochetrefresh.net/
Both are spiritual successors to John Brooks' `Ricochet` application.
You can also chat and share files (among other things) with https://onionshare.org/
(And finally, you can get remote exfiltration security for keys/plaintexts with TFC https://github.com/maqp/tfc (my personal work), at the cost of losing some features like message forwarding etc that the architecture prevents you from doing.)
Since the protocol appears to use adhoc synchronization, the authors might be interested in https://github.com/sipa/minisketch/ 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.
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.
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?
I found this https://github.com/status-im/bigbrother-specs/blob/master/da... but it is several years old and doesn't contain much info on peer discovery.
Well... P2P isn't the best when it comes to messaging https://github.com/simplex-chat/simplex-chat/blob/stable/doc...
It's not hard for IRC-style chats, but it gets harder if you want to handle:
* Asynchronous messaging: what if the two devices are not online at the same time, or on disjointed networks? Store the message on a server somewhere? Secure Scuttlebutt[1] relies on devices pulling encrypted data that does not belong to them.
* NAT or firewall hole-punching, though it can be remediated by leveraging other nodes. Some implementations use a DHT[2], but you're often relying on other servers of some sort.
* What you call contact discovery is also typically handled through a DHT of some kind. Yggdrasil-like (or hyperboria, cjdns, .onion) overlay networks are usually able to route to a public key, regardless of how it moves around on the network.
* Push notifications. Either you accept the use of an external server (like the Tox client TRIfA, which has an add-on[3])
[1] https://scuttlebutt.nz/docs/introduction/detailed-start/#mor...
[2] https://blog.ipfs.tech/2022-01-20-libp2p-hole-punching/
[3] https://github.com/zoff99/tox_push_msg_app
- Here's a great analysis of all the snooping Apple did on Yosemite with all privacy features enabled (https://github.com/fix-macosx/yosemite-phone-home)