Has anyone thought about using Syncthing as the engine for a decentralized messaging system? There has been a lot of excitement recently about BitTorrent Bleep, but that excitement is dampened by the fact that it is closed source. It seems like all the necessary functions are readily available in Syncthing; if you can synchronize arbitrary files, certainly you can synchronize text messages and file attachments. There is even an Android app published and in use already!
The clients of such a messaging system would need to create/destroy temporary Folder IDs as users begin/end “conversations” with groups of two or more people. Linking Device IDs to user identities would be straightforward, especially since the “Introducer” feature has already been implemented, as well as the “push” notification of offered shares. You can imagine that when you add someone to your contact list (i.e., the client app adds their Device ID to your list), that you also enable/disable the ability for your contact to introduce you to others. For example, Alice adds her friend Bob as a contact, and sets him as an introducer. All of Bob’s contacts that have enabled introduction to Bob’s friends (or possibly even to his friends-of-friends or to the public, etc) are offered to Alice as contacts that she can add to her list. This system would make connecting to your network of contacts a rapid and effortless process, because it would get easier as more people use the system and begin introducing others.
There would be other enhancements required, such as notifications when new messages are received (i.e. when folder changes occur), but there are probably minor additions. Thoughts?
Interesting idea. I think anyone wanting to try this would be best off implementing BEP directly, rather than trying to make something work using Syncthing.exe…
I have played with Tox from time to time, and it works pretty well. It just seems like the text messaging and file sharing capabilities are a subset of what Syncthing already does. In other words, all the Syncthing mobile app is really missing is the concept of human contacts (or at least, their mobile client apps) as a flavor of “device”; it could easily become much more social.
It has been six years since I started this topic; so long that I forgot I wrote it and recreated the idea as if it were new My apparent old age and senility aside, what motivated the rediscovery of the concept was my recent experimentation with p2p messaging apps, specifically Jami, Tox and Briar. Once or twice per year, I wonder how these decentralized apps are doing and convince a friend or two to try the latest versions in real-world use. Each year they have advanced in various ways, but they always fail to be adequate. This does not mean I am not still excited about these projects and appreciative of the technology and basic functionality they provide, but I continue to be disappointed by the snail’s pace of progress in the p2p communications sector. (And yes, I understand the lack of economic incentives and various other reasons why this continues to be the case.) Thus, once again my gears started turning, imagining how relatively straightforward it would be to build a messaging application on top of Syncthing.
Here are two examples of essential capabilities that fail in these p2p apps:
Sharing a photo/file when one or both peers are temporarily offline. This morning I download the latest Tox app on Android and Linux, connected the two new accounts and started sending messages between the two. I sent a photo from my phone, and on the desktop app it prompted to accept the photo. I put my phone in airplane mode, pressed “accept” on the desktop client, and the share failed. Intermittent connectivity must be tolerated by a p2p messaging system.
Seamless transitions between multiple devices. When I was testing Jami a week ago, I was able to use the same identity on multiple devices, which is great; however, messages sent or received on one device did not appear on the other device. The recipient received messages from both devices, but their responses only appeared on one device. Clearly this is non-ideal, and Jami is currently introducing their new “swarm” messaging feature which might address this problem. This feels a lot like reinventing the wheel to me.
Obviously Syncthing could accomplish both of these essential functions immediately, in addition to several other features as I mentioned in the original post years ago, like bootstrapping your social network by easily connecting friends and associates using automatic introductions.
I wouldn’t hold my breath waiting for me to actually build anything, but it’s fun to think about. And who knows? Perhaps someone will be inspired by this discussion and start working on it
I remember when Syncthing was almost merged with Pulse…“heartbeat” is run by the same group, but every time that looked also never really understood what their end goal was.
What a coincidence! I only just discovered that yet another feature is being implemented in Syncthing that would be a perfect fit for a feature I was considering for the messaging platform: encryption for untrusted devices. One of the major disadvantages of a truly p2p, serverless platform is the risk of data loss if all your devices are lost. This risk could be mitigated by a user-friendly backup system among willing participants. Such a backup system would naturally treat the backup hosts as untrusted (even though the human beings involved would typically trust each other) and encrypt the contents prior to syncing the critical user identity and device key pair data for storage on the backup devices.
Maybe you should take a look at the features of [matrix], if you want a decentralised instant messaging system with e2e encryption and trusted counterparts.
I’m a big Matrix fan; have been running a server for my family for years now, but Matrix is not peer-to-peer. It is very exciting how close they are to making it p2p.
I agree in principle, but then the question would be how many features you would have to reimplement. For example, introductions are something Syncthing already does natively. The “chat client” would only have to hit the relevant API endpoints related to marking devices as introducers on its internal Syncthing instance. Syncthing already handles all the logic associated with connecting peers to one another and managing the shares between them.
My apparent old age and senility aside, what motivated the rediscovery of the concept was my recent experimentation with p2p messaging apps, specifically Jami, Tox and Briar. Once or twice per year, I wonder how these decentralized apps are doing and convince a friend or two to try the latest versions in real-world use. Each year they have advanced in various ways, but they always fail to be adequate. This does not mean I am not still excited about these projects and appreciative of the technology and basic functionality they provide, but I continue to be disappointed by the snail’s pace of progress in the p2p communications sector. (And yes, I understand the lack of economic incentives and various other reasons why this continues to be the case.) Thus, once again my gears started turning, imagining how relatively straightforward it would be to build a messaging application on top of Syncthing.
I’m a big Matrix fan; have been running a server for my family for years now, but Matrix is not peer-to-peer. It is very exciting