What I just said about “early days” seems to be confirmed by Riot’s security page:
As of May 2017 Riot’s end-to-end encryption is technically in beta, but this is due to some residual stability bugs and missing usability features. Once these are resolved we plan to get the full implementation security assessed and out of beta. End-to-end encryption will then be turned on by default for private conversations.
first problem is servers, because with this privacy policy they log too much things
second one is permission app, but let’s see how librem 5 handle it
i’d like to have an official reply from purism about it, because i feel it as a privacy problem
I just hope this matrix stuff will be optional and removable, not integrated into the core messaging system of the phone. so that i could just wipe it clean and install my preferred messaging app.
I do understand about vanilla os and blah but hate to remove some core components. I.e. removing telepathy stack with libcomhistoryd on jolla is possible but insane (telepathy is pluggable though hence not bound to any specific protocol).
Hi folks - I’m the project lead for Matrix.org; only just found this, so sorry for the delay. Quick answers on my side:
[1] https://github.com/matrix-org/matrix-android-sdk/commit/daa3d2a2148878097612e9e038d024d1098ff195
[2] https://github.com/vector-im/riot-android/pull/232
thank you @matthew for your reply, it’s very appreciated
is awesome to have the option to make your own server, the problem is for normal users who are not able to do it, so we have to trust the server admin/owner
because all surveillance we see from big corps and governments, company like purism and alternative messagging system like matrix are welcome, but even if your intentions are the best one, people like me will be ever scared from what should be happen to our data, because we need to trust you, but we know in the age of surveliance and big data economy we can trust no one, so the best thinks you (both matrix and purism) can do is to make products/service where the data you have is essential and well encrypted from user, so you can see nothing, and the privacy policy should be essential, as i already wrote in another topic
otherwise is just about a choice to trust android-whatsapp or purism-matrix, this is not bad, but the goal is to do not have the trusting problem, chosing a service who have no visible data but just encrypted with a good, short and well readable privacy policy, where if a malicius dev or an hacker see/sells the stored data, can just access to a useless encrypted file
same for the client, i’m scaried from android apps permission, and i really hope purism will make this issue a priority, giving to the user the full power to manage it with a good user interface and popups when needed, and of course i hope matrix client will just require the permission who really need and will access to the data when WE choose to use it
i know i’m paranoid, but as i wrote we live in a big data surveillance/economy era, and freedom is really important to me, i think company like matrix and purism have this user target, because normal user will just spend 100$ for and android phone with whatsapp used by almost everyone, less money needed and less problem, i have to convince people to use matrix to comunicate with me, and every time i’ll be watched like an alien “why you are not using whatsapp?” and so on, than i will explain why i really think different, and that’s why your policies and how the service/data storage work need to be made for paranoid like me, thanks to snowden and others heroes, we know we cannot really trust people or companies, that’s why technology architecture are important more than manifesto
i’m happy to see you like “my model” of privacy policy, i hope you, both purism and matrix server, will use it
opt-in is also awesome as i understand you need analytics for improve your product, and with opt-in you will respect the user privacy and will
about android permission i just don’t like how android work, but this is because usually apps will abuse of these permission
after your replies i’m satisfied about matrix or i’ll be when i’ll see the newer privacy policy from you and from purism server of course
let us update on this if you still have time to communicate with us, thanks again for your time and your work, is important to have a privacy wise comunication system to be used for freedom and free speech
yes, i found that wondrous when i touched matrix the first time. for purism which states to use telepathy (which i consider the way to go while not really usable currently) i wonder if there would be a native “connection manager” for matrix (a libpurple one seems to exists and there is a bridge from telepathy).
@purism: will there be a telepathy connection manager for sms/mms? 
where are you seeing that Purism is going to use Telepathy?
i’ve read it somewhere but don’t remember where and can’t find it with their search. it may well be that it was mentioned as part of pureOS and they tell pureOS will be installed on librem5…
i like the telepathy idea as (in theory) you can freely choose the protocol and the gui. but i found a mailthread now about the topic which even mentions matrix and librem5 (and contains a post from a Matthew Hodgson - is that you? ) which tells alot about architectural problems of telepathy… so what 's your oppinion?
Yup, that mail-thread was me too. As you saw, there was debate on whether telepathy should be left to die, or whether Matrix could replace it (albeit with quite a different architecture, given the multi-headed approach would be done serverside rather than clientside), or whether there’s a “telepathy but done right” model which could work better, providing a local OS abstraction which could be backed by Matrix (or other connectors if preferred). To my knowledge there hasn’t been a conclusion yet, although on the Matrix side we’re syncing with Purism about it this week.
i’m quite new to matrix (old user of irc and jabber) but amazed. but from my view matrix cant be a replacement for telepathy (i wondered about the subject already) as it’s below: as you say: a huge change in architecture.
the telepathy design fits so well because you are forced to stay on the device with a mobile if you want to support sms/mms, a proxy is mentioned there but that sounds ugly.
i’m not that deep into the messanging topic (only seen that empathy is unusable) - can you enlighten me about the major problems of the telepathy architecture? is it fixable with affortable efforts?
Rob McQueen (who I think ran the telepathy project) wrote a huge rant on its problems here: https://mail.gnome.org/archives/desktop-devel-list/2017-September/msg00047.html. Meanwhile, some of the stuff that telepathy doesn’t implement (and can’t, without big reengineering effort) include:
You’re right that Matrix isn’t a direct replacement, as architecturally it differs. However, one approach being considered is to expose a Matrix-like API in the OS which maps easily to the Matrix client/server protocol, and is handled by a daemon process of some kind which handles some of the heavy lifting (e.g. E2E crypto; local chat history). This daemon could also implement other backends direct to IRC, XMPP, Slack or whatever if people wanted to take Matrix out of the loop entirely - at which point it starts feeling a bit like a modern version of telepathy (although in practice the only ‘connector’ which we’d be focusing on the Matrix side would of be the Matrix-backed one).
</thought experiment>
so you see matrix protocol as a blueprint for an api which can be used for others protocols or even local stuff like sms or voice-call - did i get that right?
still a background daemon handles the local stuff (i already thought of history, i’m often in areas without internet access and hate not to be able to use my phone), i like that idea…
what’s your oppinion about d-bus? the mailthread states it’s the cause for bad performance.
Matrix already bridges through to many protocols (IRC, Slack, XMPP, Gitter, Telegram etc) but does so using bridges which run (conceptually) server-side. But yes, in the hypothetical daemon model, the same generic Matrix-like RPC API could also abstract other protocols directly (or local stuff like SMS & PSTN calls), similar to Telepathy.
I haven’t played with D-Bus much myself, so all I’ve seen is the Telepathy guys implying that it introduced too much complexity. An alternate solution could be to have the local daemon API just be the Matrix HTTP API (but immediately converting that to other protocols if/when it makes sense). An a final extreme would be to have the local daemon be a full Matrix homeserver (albeit one set up for p2p federation, in future).
Ugh oh by the sound of it it will be integrated into dialer - which is all about the insanity I’ve mentioned in my post.
As for telepathy…
I’ve attempted adding features to gabble but the only thing I’ve managed to add was roster versioning and csi. anything else (eg simple carbons) stumbles upon ambiguity of the client implementation.
In any case - new platform, new challenges. let see what exactly will be on the plate.
well, as per the previous posts in the thread, there’s discussion about abstracting it from the dialler. and one could always fork or swap the dialler for whatever tech floats your boat…
Hello all, I have found this very interesting thread about Matrix/Riot. I would like to share my “average man in the street” feedback and ask a request.
1. First, the feedback :
My wife and I are not expert in softwares. We like when we use and it works easily. I have installed Riot for Android for both of us… and I can say that it was not intuitive at all. The homeserver/identity server fields appeared strange for us.
Then we had to setup the E2E discussion, and the “room”. Same here, not easy.
However, when everything is setup, we can say that it works pretty well. We are really happy to see such an app allowing to communicate in a cross-platform way. And despite all the “bad points”, the overall is positive.
2. Request :
So seeing the above concerns, I would like to know :
In any case, thank you very much.
We understand that the project is at the beginning and we are very impressed about the progress. Also, my requests and feedback are our opinion, but maybe people have different opinion.
Thanks also from me for the thorough responses, this is very valuable information. I am still very new to Matrix and trying to understand how it differs from other protocols I am somewhat more familiar with, especially XMPP.
So please allow me go through your list of things Telepathy (which I don’t know) doesn’t do and compare them to what I know about XMPP and with what I understand about the privacy implications:
For those who don’t know XMPP, it supports (IMHO similar to Matrix) a federation system which allows anyone to install a “home server” and which works with IDs that look exactly like email addresses, which I think makes this relatively easy for beginners as all they need to know is that ID if they want to contact someone new.
So please forgive me that I still don’t quite understand what new things Matrix brings to the table that XMPP can’t do already. I understand the current XMPP landscape is so fragmented because most client apps and too many servers don’t support various subsets of these XEPs (or do so poorly), but to counter that the Librem 5 could e.g. enforce minimum requirements on the servers people want to sign up to. Once that is under control, the rest appear to be mainly UX choices and development.
That worries me a little, as this would mean giving my other IM identities (and any E2E encryption keys?) I want to bridge to my Matrix server (which in many cases would be either Riot.im or a new Purism server), or am I misunderstanding something?
