If someone else thinks the logo looks familiar, it's because [Jami was previously named Ring](https://jami.net/ring-becomes-jami/) which I actually used years ago. Can't remember anything about it though.
Jami is more or less completely peer-to-peer. Other than initial bootstrapping all conversations are synced between participant devices without any central servers. I don't know much about Session, but Matrix requires a homeserver that is basically always running to operate which provides a single point of failure for any particular user (as opposed to Jami where each of a user's devices can sync independently) and is easier to use (you don't need to find and pick a homeserver, all you need is your device).
Jami has also been around a long time. It had other names in the past like SFLphone and Ring.
This. Jami is truly distributed, and there's no need to set up and manage any server(s) in the sense that one would do for Jitsi, Matrix, BigBlueButton, etc.
Also, thanks to Jami's distributed nature, it can also function in local networks without internet connectivity:
How does Jami work if I have multiple devices? For example, I want to connect on my work PC, my home PC, and my phone, share the same account, and see all the messages I sent/received on my work PC when I log into my home PC.
This is traditionally the worst UX problem with Signal / Session / Matrix etc. Manually handing keys back and forth is a disaster. Compare that to something like Telegram or WhatsApp where you can just log on and everything is there.
Jami has "Swarm" conversations, which are git-backed behind the scenes, and can be synchronized across multiple devices and/or participants seamlessly. Actually, thanks to the way Jami uses git, a subset of participants in a group conversation could enter a local network and continue chatting amongst themselves, and once they connect with the rest of the participants again their histories will automatically be synchronized and merged.
To add a new device, from account settings select 'Link another device'. This will create an encrypted archive of your account details and temporarily (for 10 minutes) put it on the OpenDHT network, and give you a PIN which you would use on your new device to have Jami retrieve and import your account. You could also do this manually and without going through OpenDHT, by having Jami create a local backup of your account on your current device, and then transfer the backup archive onto your new device yourself, and import it into Jami. After adding the new device, your Swarm conversations and their histories will begin synchronizing shortly.
I've recently tried Jami to chat with a friend using the new(?) Qt client, and it wasn't a very good experience. Scrolling feels terrible. When I scroll up, it keeps going for a moment even though I let go of the scroll wheel. When I scroll down, the view jumps around as images load in.
After we filled up the chat a bit, opening it again takes about six seconds. And sometimes, it starts using 60% CPU doing apparently nothing.
There is a "reply to message" function, but it's useless on images because it only shows the first part of the path to the image (you just see "/home/me/.local/share/jami/8fd7...") and clicking it doesn't bring you to the message in question.
I also tried the Android client, which was usable enough, but it could only receive messages if I had the desktop client too. But that might be because of my NAT.
Thanks a lot for the feedback, and sorry about the issues. Would you please report them on the Jami bug trackers per https://docs.jami.net/user/bug-report-guide.html if not already? This would help the team keep track, look further into them, and hopefully fix them.
This isn’t really a helpful response. It’s the project owner’s responsibility to maintain the project, not their users.
While it’s certainly nice if the user does this and removes burden from you, it’s a better practice (and engenders more good will from your users) to just ingest this into the bug tracker on the user’s behalf (and dedupe as needed / do a search and give them the link to existing bugs if it describes their issue).
Yes, the creators should be testing their app. But making bug reports is also a fundamental useful thing. Should I not report bugs in mac os or chrome or python3 because the project owner should have figured it out? No.
He's saying, and I agree, that a casual first time user making a low friction complaint somewhere like here should simply be digested immediately by a team member and ammended onto a perviously created bug in their system. Or a new bug should be created by a team member.
I do this at my job all the time because our Jira setup is fucking balls and I have all kinds of greesemonkey to make it usable and quick for me. Any casual user is going to bounce the fuck off our jira setup. Secondly I know if there is already a bug in our system covering this issue or not, less time for my team to do de-duping etc.
Yup. About the only two complaints that might reasonably warrant asking the user to create a ticket themselves is the NAT one and the CPU spike doing nothing. For both of those though, rather than having the user create a bug report just to go back and forth over it asynchronously over months until the end user gets discouraged and drops it, a better situation works be diagnostic tools that could monitor and collect data that the devs could then analyze, ideally baked into the code where you just click a button to submit feedback and your code can code to open a bug report or just ingest metrics or something.
It worked reliably for me when other video conference software didn't work properly (Jitsi, Skype, Gtalk…). Also, it was easy for my dad to install and use, after I told him about the unique identifier to keep around to use on another device. With a previous version though, I encountered a situation when my text messages wouldn't be received by my friend :/ (using the desktop version) Annoying. Hope this is fixed in the latest releases.
Thanks for trying/using Jami! And sorry to hear about the previous issues. If you do encounter them again, please do file a bug report so the team could investigate and hopefully fix them:
Here is my first experience with it.
I installed the app on iOS and Android. After account registration I added from Android my account in iOS. iOS get the invitation immediately then it shows a status that said waiting for Android to connect or something. It stayed like that for 10 minutes until I tried the voice call.
I don't think my voice in Android heard in may iOS phone, but after that we can chat each other.
If you register a username for your Jami account, your JamiID will be that username, otherwise it will just be the account's infohash (public key fingerprint). A Jami username is a mapping between a unique human-friendly name and an account infohash.
> Is this JamiID that I created forever mine?
With the default Jami name server, https://ns.jami.net, username registrations are permanent, and cannot be changed or deleted. Also, if you delete or lose your account without having backed it up earlier, you will lose that username and it cannot be recovered. This is one of the reasons why it's really important to back up your account.
> If my friends create their JamiID, will the search just list them?
Yes, you can search others by their JamiID, whether it's their username or the longer account infohash.
> Do I need to import any JamiID's? How does discovery work for these JamiID's?
You would search for their JamiID and add them as contacts, similarly to how you would with other messaging applications. When you search a username, Jami will query the name server to get the account infohash and send a contact request. For example, with the default name server, to look up 'bandali' Jami would make a request to https://ns.jami.net/name/bandali to get the associated account infohash.
You can read more about this on the Jami user FAQ and the 'name server protocol' section of the developer manual:
(For me, just now, `jami-gnome` installed and set up easily enough, including registering my username, but linking the account on the app from F-Droid seems to have left it halfway-done, without the username, and any kind of username lookup from the app from F-Droid hangs indefinitely.)
(I'm not going to try an older version, since I quickly found bug reports that suggest a pattern of breakage, and I already have to use way too much comms software that casually breaks. I might give it another chance later.)
Yes, Jami calls are p2p whenever possible, and TURN is used when not (e.g. due to overly restrictive firewalls).
Yes, Jami supports conferencing. One can add additional participants to a 1-on-1 call on the fly, effectively making it a conference. Alternatively, one can enable rendezvous mode from account settings, in which case incoming calls to that account will be added to a conference (similar to a Jisti room).
Amazing. Are there any optimizations for video conferencing in case one participant doesn't have upload bandwidth to stream his video to 10 different IP addresses at once?
I was fidgeting with the tought of something like a overlay multicast network on top of unicast IP, since RFC 1770 was deprecated/never implemented.
Right. In Jami by default only the host of a conference/rendezvous-point will stream to/from all peers and mix their streams, and other peers normally only stream to/from the conference host. Also Jami can automatically adjust the call's bitrate on the fly depending on the link quality:
I tested Jami briefly before swarm and was impressed / surprised at how far it flew under the radar. Will have to give it a spin again with the new architecture. Meanwhile, curious about who the developers are behind the project and what the business model, if any, is?
I wonder how a service like this would look like over IPFS. Or if one could somehow merge the distributive power of IPFS with sharing of end-to-end encrypted information. Or perhaps there's already one? Or perhaps Jami is already superior?
I tried this a couple of times but the main problem I encountered was: on Android, it doesn't seem to be possible to delete a conversation without also deleting the contact.
With p2p projects I’m always interested to see how they are solving ‘Signaling’, ie. the initial peer to peer matching.
I was unable to find anything on the Jami page or FAQ.
Is the above language chosen carefully for “relaying data” while likely using a central jami server for signaling?