The protocol isn't really an issue for the use-case you talk about. I founded the Snikket project, which aims squarely at the family-and-friends use case you mention (after all, it was made to scratch my own itch - my family's excessive use of WhatsApp for communicating with each other). I can tell you that my family don't care a bit whether Snikket uses IRC, XMPP or Matrix or some real-time Gemini equivalent.
There may be some scalability differences between different protocols/implementations for the admin of the service, but Snikket fits comfortably on even low-end Raspberry Pi devices, and literally over half of the typical resource usage is by the web dashboard (yay Python).
So what difference does the protocol make? It can make a difference to the developer experience. If all you want to do is exchange text messages, then yeah, XMPP and Matrix are absolutely overkill. But - especially for a family-and-friends use case - people also want file sharing, audio/video calls, and all that stuff. It very quickly gets quite complex to support all this stuff, especially in a way that allows you to evolve the protocol over time (trust me, what you think of as core messaging features today, were not a thing 10+ years ago, and messaging in 10+ years will also involve a new set of features).
There will always be a set of users for whom plain text messaging is enough (90% of my own daily communication is via messaging in a terminal app). However that set does not intersect significantly with the general population, and practically none of my family members would accept such a solution as a replacement for WhatsApp.
Hey, your project looks interesting, thanks for building and sharing it.
One question: are you aware of Jami[1], f.k.a. Ring? If so, how does it compare to Snikket?
I see that Snikket requires a server, whereas Jami is P2P. The benefit of a server is probably that messages can be stored centrally and not on each device. But I can see pros and cons of either approach.
Hey, thanks! I've been into messaging for quite a long time - network protocols and particularly those involving online communication are among my favourite tech topics :) So yeah, I follow various projects.
You're right that there are pros and cons. Obviously, not having to run a server is a big pro for many. However, the first thing to remember when researching messaging solutions - no matter what anyone tells you - there are always servers! What differs between projects/platforms is what the servers do, and who runs them.
Jami uses a network of public servers that form a distributed hash table (see https://github.com/savoirfairelinux/opendht ). It's a neat design, and they have done a good job tackling the challenges of P2P messaging. Last time I looked in, it still required both users to be connected at the same time for message delivery/sync to work (the devices use the DHT to discover each other, and then exchange messages). This is a fairly common issue for P2P systems, and can be frustrating in a mobile-dominated world. Their DHT software does support push notifications, which helps with that though.
With Snikket, instead of using existing publicly shared infrastructure, you just run your own server (e.g. VPS or Raspberry Pi or whatever) which is responsible just for your users, and your users connect directly to it, improving (meta)data locality. This makes the design very simple, reliable and efficient (e.g. with battery/bandwidth). It also enables some important (for our use case) convenience/UX features, such as the ability to add restrictions on certain accounts (e.g. for children), and server-managed contact lists so all your family members don't have to manually add each other as contacts one-by-one. Things like that.
No approach is universally better than every other, but I much prefer the Snikket model for the family-and-friends use case. Not that we don't have our own challenges. Our iOS app is probably the weakest part right now (in terms of UX and general polish). Something I'm working hard to get fixed in 2025.
Yeah, there are definite challenges of the P2P architecture. But like you say, Jami seems to have done a good job addressing them.
I looked at Briar, but it has a different focus and is more limited in functionality and less polished than Jami. My use case is text messaging and audio/video calls with a close group of contacts, so Jami and your project look like a better fit. I also considered Matrix/Element/FluffyChat, but the Matrix architecture is confusing, and the clients are underwhelming.
Anyway, good luck with Snikket! If Jami doesn't work out for me, I'll definitely give it a try.
There may be some scalability differences between different protocols/implementations for the admin of the service, but Snikket fits comfortably on even low-end Raspberry Pi devices, and literally over half of the typical resource usage is by the web dashboard (yay Python).
So what difference does the protocol make? It can make a difference to the developer experience. If all you want to do is exchange text messages, then yeah, XMPP and Matrix are absolutely overkill. But - especially for a family-and-friends use case - people also want file sharing, audio/video calls, and all that stuff. It very quickly gets quite complex to support all this stuff, especially in a way that allows you to evolve the protocol over time (trust me, what you think of as core messaging features today, were not a thing 10+ years ago, and messaging in 10+ years will also involve a new set of features).
There will always be a set of users for whom plain text messaging is enough (90% of my own daily communication is via messaging in a terminal app). However that set does not intersect significantly with the general population, and practically none of my family members would accept such a solution as a replacement for WhatsApp.