Firstly: Yes, I like Synapse / Cinny / Element too…don’t hate me…but needs must when the devil drives…
For reasons that are too complex to get into (TL;DR: hodge podge of equipment from the dawn of time, from intransigent family members, complexity over HTTP vs HTTPS…they usual nonsense when you volunteer to become the family sysadmin) I’ve been looking at different methods for a persistent, family chat experience that I can “self host”.
Does anyone know much about Jami?
From what I can see, it has the following worthwhile features:
- FOSS/GPL
- Android, Windows, Linux, macOS and iOS.
- Text messaging ,group chats, video calls
- File sharing, E2EE etc etc
- It apparently works over a LAN with no Internet connection at all, which is particularly interesting to me.
- Federation not required.
- CA not required
- Transparent handoff with Tailscale
From what I can see, there’s a headless jami-daemon for Linux. Jami’s own docs specifically suggest putting an existing account on an always-online server to facilitate message exchange, with multiple servers possible for redundancy.
So…that’s…good.
OTOH, there isn’t a Synapse-equivalent central Jami server holding everyone’s accounts and rooms. Accounts and conversations are distributed across the participating devices, though as I said above, it looks like Jami does support an always-online daemon/device to improve message availability.
I dunno what to make of it. It seems…too good to be true.
Has anyone use it? Particularly, is the always-online jami-daemon actually dependable for store-and-forward behavior in practice?
I’ve been hammering it hard rn and it definitely is the Unified Push / DHT proxy. The instant those are disabled, it works reliably. So I may need to revise my position.
The thing that really caught my attention is the jami daemon
https://docs.jami.net/en_US/user/jami-for-servers.html
If I’m reading that right, it’s sort of like a headless instance that can store and forward. Additionally, it doesn’t require tail-scale / head-scale to do so (as jami has its own protocol). So no nonsense with domains, reverse proxy, certificate infrastructure or public chat service.
The only issue is “it’s not self hosted”, which was part of the brief.