Hello,
sorry about the post title, but Jami is unusable! In groups, posts get lost, they don’t synchronise. Members find themselves deleted from the group without knowing why. It is no longer possible to invite them again. We found ourselves excluded from a group we had created. Our posts appear to be published, but then (on leaving and re-entering) they are deleted and no one receives them! But do you really think Jami can outperform its rivals such as Session or Element-Matrix (even though we know this is conceptually different)?
Excuse our frankness, but this is really frustrating! Either you call it a beta-test product, or if you sell it for production it is underperforming, almost unusable!
Sorry for this post, but after more than two months of use and having seen group video calls drop after only 5’, messages deleted without doing anything, and struggling to synchronise the history of messages in a paltry group of 4 people, we feel it is honest to tell you what we think: it’s not good!
Thanks for listening.
Sorry to hear of your unfortunate experience. We have previously experienced this, with the cause and solution being listed below.
-
Are all members in your Jami group using supported and fully updated operating systems?
-
Are all members in your Jami group using the latest version of Jami? The latest version is currently March, 14 2025.
-
Please ask all members in your group to click “About Jami,” and a screenshot like the following should appear:
-
We have had experiences where members in a Jami group have the Windows operating system, and it incorrectly advised that Jami was up-to-date. The discovery and solution to this problem was:
-
If any member in your group has their operating systems saying that Jami is up-to-date but the “Jami version” is not “Εἰρήνη” and the “Build ID” is not something like “202503142130” (yyyymmddHHmm), please ask them to download and reinstall Jami from https://jami.net/.
Hello Ovari,
thank you very much for your reply and sorry for the delay in the feedback.
I specify from the outset that we got a Mac with new installation of macOS 15.4 and vpn Mullvad.
We downloaded and installed Jami as you indicated. We started it up and whatever we choose (create new account, use account present in other device, import account from backup, etc), Jami crashes.
After choosing one of the options on the start screen, Jami stops and does nothing. In order to get the home screen back for selecting one of the available options, we need to delete the Jami folder in the MacOS Library dir.
This is our experience.
The point is that none of us are technicians, so this is frustrating. We know Linux and we know its active and knowledgeable community, but those who choose the Mac - as we do - is because they want a product that is as stable as Linux and as easy as Windows. Testing, looking at logs, etc. is not something that is desirable for those who choose Apple. That is why we said it is not ready for production. Other similar tools work the first time, without having to struggle too much.
I hope I have offered our situation as best I can.
Thanks again for your time and have a nice day.
Hi, just in case it might help for solving the problem that arises on your Mac: did you give a try at the beta version of JAMI ? https://dl.jami.net/mac_osx/qt_client/beta/jami-beta.dmg
Hi,
the beta version no, I will try it. The point, after several tests, is not the VPN (in fact with ProtonVPN we had no problems, but we do with MullvardVPN), but the DNS.
By closing the VPN, but setting the DNS of Mullvard, Jami doesn’t even start. Same thing if you set OpenDNS. So the point lies ni DNS (try it yourself), and, if this is also confirmed by you, it is a matter of the resolution of the server names used by Jami, not of the programme itself.
You try it too.
If it is the DNS resolver, I suggest you input turn.jami.net in DNS Lookup Tool - DNS Tools - MxToolbox. Then, try replacing turn.jami.net with the IP you get to see if it solves the problem (in the Jami Advanced settings → Connectivity). I had been given this suggestion here on the French Jami forum: Problème de connectivité intermittent - #11 by pmetras
I also suggest that you read this thread: Problème de connectivité intermittent - #25 by Jami. I translated the following content from the original that was recently written in French by a Jami admin (the original message is more detailed - you can use an online translator if needed).
[…] Jami is a distributed communication software, so by definition it cannot work in a very restricted network environment. At the very least, the following ports must be open: FAQ - Jami documentation
If this is not possible, the only way to use Jami on a very restricted network will be to deploy DHT proxy and TURN servers inside the organizational network (or on a DMZ).
[…]
As you can see, this is not something that the team of Jami developers or a simple user of the restrictive organizational network can do. This is an infra/network architecture project that the organization’s IT managers must carry out if they decide to use Jami.
I have this problem on my institutional network where most UDP ports are blocked and where Jami is therefore unable to connect to peers. I checked with my laptop (dual boot Win11 and Linux Zorin 17.3 OS): no problem on my home network, but alas 
impossible to use on my work network. If you have a laptop, I suggest you try if the problem applies to you. I suspect that several users who have problems with Jami on work networks might also be confronted to the same issue.
UPDATE 2025-04-16: There is a way to overcome the problem by using a VPN like Mullvad, see Problème de connectivité intermittent - #27 by mmms
A good idea would be to add a procedure in the Jami documentation on how to diagnose the problems that can occur and show how to use tools to investigate. For example:
- Check network connectivity to Jami essential servers: bootstrap node; name server; TURN server; DHT proxy.
- Check protocols and ports that can be used: TCP, UDP
- How to use wireshark to check traffic.
- Try connection to name server.
- How to bypass name resolution.
- Try setting TURN session to TURN server.
- etc.
I think that if the Jami developers had a better understanding of the various network configurations, particularly in professional environment, Jami would improve and everyone would benefit.
I had significant problems on Android 7 and am wondering if the DHT scheme is more trouble than it’s worth. I haven’t yet tried to understand what benefit the DHT is supposed to bring, as opposed to a conventional (maybe replicated) database.
The DHT is in itself a distributed database. That’s the way I understand it. Every node (Jami instance) has a copy of a part of that database, of course with a lot of redundancy as Jami instances can go off and on on the network at any time. The trick is that a node can discover its neighbors and query them if they know a record in their copy of the database. And if that’s not the case, those nodes can query their own neighbors.
The way Jami uses the DHT is to record the network address of a Jami instance when a user connects. That way, this user has a record in the distributed database and can be reached directly by querying her address, and then establishing a direct connection.
When the user disconnects from the DHT, her record has to be deleted. In fact, when the network address is added to the DHT, it is put with a time to live (TTL), usually of 10 minutes. If the Jami client doesn’t refresh this record, it will expire and the user is considered unreachable. This 10 minutes TTL is of a few hours in case you use a DHT proxy: it has the consequences that you appear to be reachable even if your off the network after some hours.
Thanks, I’ve been looking for a while at the developer docs and this thread and I have to say it is all pretty confusing. It’s night here and I’ll look some more tomorrow. It seems to me that Jami is technically interesting but it maybe tries to do too many things and invent too many of its own solutions? The version of the code I downloaded (from debian server) is quite old, so I should look at a newer version. But I looked at the current docs, and that is perplexing too. I did find the client side log files, though the timestamps are in seconds-since-epoch so I’ll have to write some kind of filter to match them up with datetime timestamps.
You can access up-to-date sources from Savoir-Faire Linux Gitlab.
Yes, there are group members who find themselves leaving the group without doing anything, and oddly enough, they sometimes return to the group in complex synchronization situations between multiple devices. I can only recommend making sure you have a good internet connection with what sent you invitations before entering the group to avoid a bad data transfer process.