There is still no Messenger I can fully recommend. I have the hope that the Matrix protocol and the resulting apps will have all necessary privacy features.
Yep, I think the closest (and to be used) are:
- The Librem 5’s Chatty (fully integrated and compatible comunication with the entire world, hopefully soon also with added support for the jitsi-meet webrtc audio/video chat toolkit and its standard web browser compatible fallback links)
With installed plug-ins for
- GNU Jami (p2p with audio and video support, hopefully soon with support for the small phone screen https://git.ring.cx/savoirfairelinux/ring-client-gnome/issues/818 )
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…
For sure, the protocol and implementation seems also plastered with compromised adverse plugs everywhere.
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.
PTIO in general I’ve found to be quite childish, especially when it comes to objectively evaluating cryptocurrency privacy. Personally, I would operate with discretion when reading PTIO (or PrsimBreak, etc) than make the fallacy of appealing to their ‘authority’.
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.
The concept is explained also explained here.
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.
(The Jami documentation seems to get reworked in the wiki: https://git.jami.net/savoirfairelinux/ring-project/wikis/home )
For comparison, the self-hosting linux distribution Freedombone only hosts XMPP.
“Mainstream software is so broken and the organizations that develop it so untrustworthy that we are reaching a breaking point.”
“Superficially, decentralized systems appear to be gaining ground, but the harsh reality is that the internet has become highly concentrated around a”
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).
I am confident mesh of mobile will emerge, just hard to say when. It reminds me of the path of electric cars.
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.
- 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.