> Be resilient against mass surveillance by minimizing metadata leakage
While that's an admirable goal, it's also a really difficult-to-solve problem in the context of P2P, so simply mentioning a goal says nothing about the actual state of security of Berty or about whether it's achievable in the first place.
By default (i.e. without any countermeasures like onion routing), a p2p network will expose more metadata to the 3-letter agencies than a centralized app with Sealed Sender[0] like Signal. The people at GNUnet have spent more several man decades trying to solve this issue and last time I checked they were still not happy with their solution.
I've pondered p2p apps that are secure from traffic analysis, sniffing, and leaking metadata. Chat being the easiest. Chat is low bandwidth and tolerates latencies well, much more so than audio or video streaming.
Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging.
However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT.
Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion.
So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary.
Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work.
So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.
I have never understood how that works in practice. The server knows the IP addresses (and source ports) of where they are sending and receiving things. How can the server not know who is talking to who?
Also, Signal Messenger Protocol requires a server to store and forward prekeys. Why can't that server just record who shows up to pick up who's prekeys?
Is there not a "One ticket West" algorithm for distributed networks?
The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination.
I'm not sure how one would apply the concept of "direction" to a communications graph.
Also some means of discerning arrival would need to be provided for.
What if that server were under the control of the NSA?
In any case, your description
> The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination.
pretty much matches the idea of the IP protocol built on top of point-to-point connections. The problem is that you still need to specify a direction and that helps an attacker identify and track messages from sender to receiver.
Look at it from a different angle:
The most extreme version of a "one ticket west" algorithm would be one where your message would get broadcast to (or eventually pass by) all participants of the network and all of them would check whether the message is meant for them (e.g. by trying to decrypt it). Needless to say, this doesn't scale well at all, especially not for sending anything bigger than pure text. OTOH this is certainly the broadest sense of direction one could possibly think of and there would be no possible way for Eve to discern to whom Alice is sending her message.
Contrast this with direct 1-to-1 connections between Alice and Bob. Any eavesdropper would immediately see Alice's and Bob's IP address.
Now in between these two extremes lie "semi-direct" messages where the path that the message takes is – at the word says – not direct but instead gets obfuscated by some algorithm. (Your idea being one version of that.) Unfortunately, coming up with a good algorithm is anything but simple and the danger is that a nation state actor with sufficient power would still be able to "hack" the algorithm and undo the obfuscation. This is precisely what the people at Tor and GNUnet are concerned with.
> Just like blockchain technologies, Berty doesn’t pass your data through central servers - the place where internet service providers, hackers, and governments can intercept your data. Instead, Berty’s network is distributed, based on P2P direct messaging.
I know it's just marketing spiel, but kind of funny to read, as if "just like blockchain technologies" actually means anything to 99% of google play store users beyond "uhh bitcoin?" (or really means anything in this context too).
Maybe it does incorporate some shared ledger, but sounds like its just plain old P2P (which is fine!).
It's also funny considering that blockchain absolutely uses central servers. The bulk of mining is still done on big datacenter farms and you can't really be part of the game without joining a pool.
This is half-true. If your concern is contributing to network security, running your own miner is actually a fairly direct way to contribute (even on a Pool). If your goal is maximizing profits, then crypto mining turns into a completely different game.
Even discounting the exchanging of coins in person, what is your definition of "centralized"? Exchanges are independent from each other, and they pop in and out of existence as the wind blows. I would call them as centralized as email servers are.
Exactly, email servers like Gmail, Yahoo, hotmail are extremely centralized. Even if the protocol is open and anyone can technically speak on the same level, being big gives way more leverage over where the network is going.
Being centralized is not just being unique, it's being so powerful you get to decide your users' experience, instead of users being in control.
As others have stated matrix and XMPP are good options. I myself am an admitted matrix fan boy, so i lean heavy that way....but the choice is yours. For matrix, i know that beyond the mobile and web browser clients, there are several regular, (non-browser), good ol' fashion desktop style applications (scroll down on this url: https://matrix.org/clients/) for linux, windows and Mac operating systems. The story is likely similar on XMPP side, but i have not used xmpp in many years.
On computer is generally a _much_ easier case to design for since it can be assumed that the computer is available most of the time to receive messages. Mobile is significantly harder because most of the time it's not available to receive. This ends up in a situation where caching servers are a required necessity, but have to be built to be private. From that, computers become a derivative case for an increasingly niche minority of users/use cases
My family uses Matrix. The default Element interface works in the browser, on desktop, and on mobile app. It was chosen as it's pretty much the only solution that is open-source, supports all devices, has E2EE, supports text/voice/video, and can be selfhosted.
Clunkier story, but XMPP checks all those boxes as well, but there are better clients (sadly also crappier clients which is part of the issue) and it's far older.
I mean you can use SIP too, but the fact about Matrix and Element is that it's a seamless experience. Point users to the app, issue accounts, provide the server address, and they're good to go. The interface and experience is just like a commercial chat app so there's little resistance.
I keep wanting to like Tox, but it requires you to setup a server at a minimum in order to use it in the primary messaging/chat use case of a mobile device. Realistically this is an insurmountable hurdle to an average user and the network effect can't be overcome. Outside that use case they're entering an already heavily saturated market with little value add relative to competitors.
This looks really interesting. If cryptography holds up, this could be a great alternative to Signal, especially considering the unwarranted and opinionated design choices they have started forcing upon their users lately (dropping SMS, cryptocurrency integration, stories, and cloud backups). The removal of deanonymizing verification process is also to be applauded. Using a decentralized transport is a good idea in theory, however, remembering the P2P-induced asynchronicity of Tox, I will definitely remain a sceptic until I see it working at a comparable rate to Signal.
On the subject of rendezvous, some years ago I came across a personal P2P project where the author provided an unusual, additional, alternative method for a peer to succinctly and confidentially provide another peer with their address via any arbitrary web page, e.g., a pastebin. Unfortunately I cannot seem to find this project again. Running one's own rendezvous server that only serves up peer addresses and passes no traffic between peers is relatively easy and inexpensive, but it does involve some maintenance. This author had thought about other possible means of exchanging addresses over the public internet. IME that is unusual in P2P projects.
Anyone who wants to meet secretly having Bluetooth on leaves massive digital trail behind, every major city has Bluetooth scanners all over to record those MACs. Additionally covid made evey cell searching for bluetooth MACs....
Which argues that clients should randomly change their MACs, and you could share your PRNG with friends so they could recognize you, even if it changes often.
Adoption and change is a major problem exacerbated by the many protocol options. Once you get people on Signal, it will be more difficult to get many to change again to something anonymous and decentralized when situations or threat models change.
This. If your primary source of information and development is Discord, and you're a secure chat app, I'm done looking. In most cases in fact if your sole source of information is _a chat app_, I'm done looking because you've declared you don't have anything but real time support, which is on par with me calling you on the phone (it ain't happening). Chat isn't feasibly searchable in a support context, even when archived, and is completely useless for anything but real time communication. I don't get how everyone keeps complaining about it and having the problem shoved in their face daily ("too many messages, can someone summarize?") yet insist on it as a historical record and asynchronous communication medium. Using chat as your only support is a clear declaration you would rather answer the same questions repeatedly rather than work on your project at all.
As I noted to another commenter, they have a go CLI client ( that I haven't tested ) [1] and their site says they're going to be available also for Mac, Windows and Linux.
I am working on iroh, a rust implementation of ipfs.
I have to say that while this dismissal is shallow, it is ...not entirely incorrect... . There is certainly a lot of room for improvement in the current state of ipfs.
We would love to change your mind about ipfs performance and reliability. Once we got a version of iroh that is ready for production, we would be quite happy to let you try it out and get your feedback.
As far as I can see there is no fundamental reason why a set of protocols for content-addressed storage like ipfs can not be fast and reliable.
I agree, I think IPFS-the-idea is fantastic, but IPFS-the-implementation is terrible. I created https://www.eternum.io (the first IPFS pinning service) a while ago, and it has been an endless slog to run. Even basic UX things (like managing pins like a torrent client, ie asynchronously/listing pin progress/etc) haven't had any progress for YEARS.
I really hope your project can improve things, I'd be glad to try it out.
It is peer-to-peer. If someone keeps spamming you from the same IP address, then you can block that address. If you're getting spammed from multiple IP addresses, then you're essentially getting DDOS'd and there's nothing you can do aside from blocking unknown senders.
Probably because it's one of the few positive signals you get back as an OSS contributor. Seems to me most other feedback they get is complaining and whining, often about things that are extremely peripheral to the core work they're putting out into the world.
I was glad to note that this is available on iOS too, but it seems like it needs more time to mature and be trustworthy.
The site clearly states that a security audit hasn’t been done and that it’s planned in the future. The makers caution people not to trust it completely at this point, especially in war situations.
What kills each of these occasionally popping up alternative messengers for me is the lack of usage by my actual social network. As long as people use WhatsApp, I will have to use it, too. And since I got everyone there, why install another app? I have too many apps already.
It wasn't an easy decision to delete my WhatsApp account because I feared losing access to several friends.
Here's what I did. I checked who my friends were that I couldn't find on Signal or Telegram. I had sent them a message explaining that I would stop using WhatsApp and the reasons why I preferred to avoid using it. I also mentioned on which other platforms I was available and if they would consider being available there too. To my great surprise, most of these people made the move. (Particularly the ones I had often contact with.) For the rest, I'd sent another message in a few weeks saying that I'm uninstalling the app and asking them to send me an email to my email address so that I'd have their addresses.
I find that it's our responsibility to help non tech-savvy people understand their digital choices and set a good example through our very own choices.
I understood that P2P is delivered by the Pinecone overlay network which is in the makings and none of the available clients yet provide P2P communication?
How is photo/video sharing handled? I am looking for an e2e encryption channel to share family photos in a group chat style messager with grandparents and groups of friends.
Here's what they write about BLE (Bluetooth Low Energy) that they use for connection:
> BLE has the advantage of being compatible between different platforms, but it is extremely slow. It may be suitable for sending small text messages, but it is totally unsuitable for exchanging photos, let alone videos. However, alternatives exist. We will develop this point below.
bigegst single feature that makes this realy attractive:
You can create quick adhock private communicator betweenynlimited # of people without anytrace:
Node on VM with VPN server let cliens conenct communicate then kill it and there would be no trace of anyhting, and it all takes literally no time.
Matrix is not decentralized, but merely federated. As far as I understand it, you still need a home server, that has access to a lot of metadata, which implies that you have to trust the network operator not to log and share all that sensitive information.
It's still an awesome alternative to say, Discord and Slack.
I don't believe so. But please find a source that says that cryptography is at risk in France. It's easier to prove that laws are undermining than not.
old info, france used to restrict it somehow until 2004/2011 (idk what to make of this data) but it seems only exporting and importing is somehow regulated/special nowadays
All these applications are useless. If it is on your phone it is not private. It is more private, yes.
Maybe we need to change our behavior, like not needing to talk to each other all the time, or saving our personal conversations for times when we are sitting next to the other in person.
Is this a solution in search of a problem? Or even a solution that is causing a problem?
Unfortunately homophonic with Ireland's former PM who (during corruption investigations) claimed that he did not have a bank account. (To be fair, he was merely the minister for finance at the time)
> Be resilient against mass surveillance by minimizing metadata leakage
While that's an admirable goal, it's also a really difficult-to-solve problem in the context of P2P, so simply mentioning a goal says nothing about the actual state of security of Berty or about whether it's achievable in the first place.
By default (i.e. without any countermeasures like onion routing), a p2p network will expose more metadata to the 3-letter agencies than a centralized app with Sealed Sender[0] like Signal. The people at GNUnet have spent more several man decades trying to solve this issue and last time I checked they were still not happy with their solution.
[0]: https://signal.org/blog/sealed-sender/