Just recently heard about Jami. I tried it out yesterday and am pretty impressed. It is really easy to use. Which is a major factor if you want broad adpation.
The P2P approach is very interesting as you don’t need any server in between. I need to read up on it a bit more to understand how it really works. For example am I wondering how censor prone it is, how the public usernaming works etc.
Compared to riot/matrix it makes a better first impression. However, a few basic features like group chat are missing. Which means it is not a full replacement (for me) yet. Additional bonus point it is part of the GNU Project.
Regarding the whole riot/matrix thing I have more and more the impression it is better suited for group chatting only and not for private chatting between a small number of people. Maybe Chatty will change my mind…
Jami is really interesting, especially from a technical standpoint. It isn’t the first to have this idea though. Bittorrent, I believe, released an app called Bleep that worked on a p2p basis as well. I thought then it was the ultimate solution, but it fizzled and died.
It is great to see Jami picking up in those tracks and flourishing. (as far as messaging and p2p is concerned) It really is a great solution!
I’m not Purism, but Rocket Chat and MatterMost are FOSS Slack replacements. Visit eithers’ website and you’ll see this on clear display in how they are marketed. Matrix is designed for general consumer consumption for things like 1:1 chats, group chats, bridge, and is federated. RC and MM assume a central entity (enterprise) hosts.
I personally love Matrix and use it daily as a permanent screen for FOSS IRC channels and encrypted 1:1’s. The Riot clients could use a decent amount of work on the UX side, but Riot’s key verification process IMO and others in the Monero community is better than other solutions like Wire. Find a Matrix client (or other messenger solution) you like and support it, be it filing UX issues, fixing UX issues, etc; it’s the only way to improve these FOSS messengers! For me, that’s currently Matrix/Riot/RiotX
I’m aware of this. I do run both. How riot works and how rc or mm work might be different but similar enough. Rc is working on federation as well but not just with other rc instances but actual federation with fediverse.
I mean I agree with you of course but I don’t think the 3 platforms are actually all that different.
I really like decentralized technologies, like Jami, qTox… but I have always wondered if the current model of hardware phone development is adapted to the kind of resources needed to do peer to peer.
Right now the model relies a lot on central servers and notifications. That allows to have the phone being asleep as much as possible and thus saves battery.
Going the peer to peer way, at least as it is now, would mean always on connection and big battery drainage. At least on my laptop it takes resources. I guess that needs to be solved first.
Then I dream of decentralizing the underlying levels as well, under the application level, and have a mesh network of mobile phones…
I have the same concern and didn’t understand, yet, how jami works if I don’t allow it to run in background on my mobile. The system is based on OpenDHT, but I didn’t understand how messages might get cached or gossiped.
Would be interesting to know if there is something for the jami network that is comparable to a pub in scuttlebuttle.
BTW: Yes, patchwork / scuttlebuttle is not intended to be an IM, but it can pass private messages also. So its mentioning here is slightly offtopic, but I wanted it to serve as an example that a messenger like jami based on dht would also be able to (or maybe already has) implement concepts to store and foreward messages without using federation to get the load off devices that do not have constant connections or sufficient ressources.
However, backlooping from the privacy breaching vectors plugged into the matrix protocol back to matrix UX issues, or matrix features that are loosing their edge as alternatives arise, does not disclose that matrix protocol vectors are getting further integrated into a privacy breaching policy?
Supporting a matrix fork to actually work on solving protocol issues could be another way to improve FOSS messengers, in particular privacy-respecting FOSS messengers.
Jami nodes (i.e. opendht) can be configured to function as a proxy for “mobile” nodes which can then sleep most of the time and only wait for wake-up interrupts coming from the connection to the proxy. The default proxy address of the android app is currently a central address, though, not your home node.
I admittedly have a hard time understanding your English, but there are currently not alternatives on the horizon to replace my using Matrix as a one stop shop as a screen for permanent IRC sessions on channels of FOSS projects or E2EE 1:1 chats. I don’t have major issues with Matrix’s policy either.
The issue therein though is said fork hasn’t got even a PoC to reference for those like myself who learn by hands on tinkering nor a website. Heck, there have been no commits for a month now. So even if I wanted to do localization work, there’s nothing to localize so naturally folk like myself are going to gravitate towards contributing to Chatty, Fractal, Matrix clients, etc since they have a client in the wild used by people. ¯\(ツ)/¯
I also planned to use fractal (as it also looks good in qemu already) - Does someone know which concerns would be away with using fractal? I am hosting my own synapse but still I always would have to use the matrix.org or vector.im identity server as I want to have the federation. I somehow fear that matrix has a general protocol problem? But this fear is not based on any code review or anything - maybe someone who actually knows could clarify?
But if for you the matrix vector behavior of knowingly implementing the protocol with centrally accessible data tracks is not questionable, and doesn’t make you look for alternatives, matrix is still not the only way to improve FOSS messengers, there are other alternatives to support for improving a privacy-respecting protocol for sure.
Ah yes, good old projection. I’ve actually spent time this week prior to this conversation helping work on a thatoneprivacysite color chart equivalent for messengers for our Monero community for reference for events like DEF CON, and have contributed to Chatty localization since Februrary but yes, please tell me more about how I don’t look for messenger alternatives because Matrix exists.
Yes, hence why I said:
Surely at least Chatty should be non-controversial given
The grand irony to me is that despite all of the messenger virtue signalling by pro-Grid folk here and on PTIO, the Grid project uses Telegram of all things in addition to Matrix so apparently the Grid project has no major issues with Matrix policy either.
I have no problem with Grid Protocol itself if only because there is quite literally no PoC to audit according to Grid’s taskboard. As I said before, if and when they get something that actually works then people can better contribute. Until then, people who contribute to FOSS are likely going to be focused on contributing to stuff that actually exists and is used in the wild such as privacy interested governments like France ¯\(ツ)/¯
At this point to distinguish myself from a broken record, I’ll disengage myself from any Grid virtual signalling conversation.
Sorry, don’t jump to projecting things. I didn’t want to, nor did I say, anybody isn’t looking for messenger alternatives, I just missed any trace of this in your preceding messages. So, everything is fine actually, if the if-clause sentence that I actually wrote above resolves to the false case, and you are looking and actually telling us about the alternatives you found.
Another fully-featured protocol alternative, with existing clients, may be http://goldbug.sourceforge.net/
(A simplified UI version seems missing, for example, the clients look as for power users, hackers, and academics.)
Interestingly, France taking interest in matrix was based on the knowledge and matrix pitch of 2017, and coincidentally or not, now the “1.0 seriously?” matrix research is coming out of libremonde.org (french language).
Matrix project lead here. I missed this thread at the time, but wanted to briefly respond to some of the themes raised:
Matrix has zero interest in tracking users (other than UX analytics in Riot for those who opt in), and you do not need any centralised service to use Matrix.
One of the main complaints that the libremonde paper raised is that the default config in Riot uses an Identity Server (used to discover other users on Matrix based on email/phone number) and Integration Manager run by New Vector, the company which develops Riot. However, these services are optional, and you can configure the app not to use them.
Subsequently, we’ve been going through rearchitecting Riot, Integration Managers & Identity Servers to only prompt to use these services on demand - making it abundantly clear to the user that they can opt out, or use an alternative, and to ensure they accept the service’s terms of use.
We’ve also been working through a load of other privacy improvements (e.g. garbage collecting deleted data properly; hashing contacts when doing discovery; letting users & admins specify data retention periods for rooms; prompting the user before using Google as a fallback TURN server; etc. etc).
^ is the main description of the work we’ve been doing here, and you can see a snapshot of the current progress (as of today; it doesn’t update so will already be stale) at https://matrix.org/~matthew/privacy-sprint.html.
It’s worth considering that the libremonde paper was written by a disaffected ex-contributor to Matrix, and while it contains some legitimate concerns which we’ve addressed (or are addressing), it makes no attempt to provide a balanced viewpoint.
Thanks a lot!
That’s about what I got from reading your updates, but it’s good to hear it from you directly in all clarity.
While we have you here, are you able to share the current state regarding Matrix on the Librem 5?
I’d love to point it out in the Promise Delivery Chart
Purism hasn’t really coordinated with the core Matrix team (or the Matrix.org Foundation) on shipping Matrix on the Librem5 beyond the initial press release. To the best of my knowledge, they are shipping a build of Fractal: a Gtk/Rust client built by the wider FOSS community. However, to get Fractal to do everything that’s needed for the Librem5 is a significant amount of work. Unfortunately the Matrix core team hasn’t received any funding to work on this, and we can’t donate time as building a mobile linux app for Purism’s usage would come at the expense of other much more core Matrix work (e.g. turning on E2E by default; addressing the privacy complaints earlier in this thread; improving server stability/scalability; etc). I’m not sure how much support the Fractal team themselves has received to do what’s needed.
I find that very often the less popular instant messengers are the safest. Since the more popular messengers have no longer proven their safety. There are too many stories of cyber attacks on users. Therefore, it may be worth looking for not very well-known messengers, like Utopia p2p.
In a practical sense, maybe, but isn’t that security through obscurity?
A niche product may not have been audited by anyone (unless you audited it yourself).
The other consideration is whether you can communicate with the people that you want to communicate with. (This is a question of the server and/or the network and/or the infrastructure. It doesn’t matter for the purposes of this paragraph what client software you use.) If you can only talk to yourself, but in perfect privacy, then it may be pointless.
This “critical mass” effect is a serious issue. Fragmentation is both a good thing and a bad thing, good because it avoids a single point of failure (single target), bad because no network gets critical mass and most people can’t communicate with most other people. (It is true that people will try to use bridges to workaround this issue but that muddies the water around privacy and attacks. A bridge can bring the problems of one network to another network.)
