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?
@Handle yes, I could, potentially. What I was referring to is that the vast majority of Librem 5 end users, including myself, probably wouldn’t. I am a regular XMPP user but thanks to the E2E encryption support there, I didn’t feel the need to do so… for now.
Having non-power-user friendly Matrix clients is very high on our todo list. Whatever the Librem5 ends up with should feel as simple as Signal or Silence in the end.
You’re right that most of the things I mentioned that Matrix can do (but telepathy can’t) are also doable with XMPP. However, architecturally/ideologically the protocols couldn’t be more different. In Matrix, conversations are always shared over all the participating servers - this is really important from a data sovereignty perspective. A given conversation should never be anchored on a single logical server. In Matrix, conversation history is a first-class citizen: in fact, Matrix is only about synchronising conversation history between devices. It doesn’t even have a way to do simple store-and-forward messaging like traditional XMPP. Similarly, E2E encryption is a first-class citizen, baked into the core protocol (albeit still in its final stages of development), rather than an afterthought extension like OMEMO. As a result, the entire protocol revolves around supporting E2E-by-default (eventually). Finally, the model of the Matrix spec is a single consistent monolithic spec published by the project, rather than the cloud of XEPs which characterises XMPP. This has advantages and disadvantages, but provides a completely opposite approach for those who want it. This is what Matrix brings to the table 
As I said, conceptually the bridge may run serverside. And yes, you’d have to give it your login or e2e keys etc to work, and it ‘breaks’ the E2E of services like telegram by decrypting/reencrypting for Matrix on the bridge. However, you could run a bridge yourself (as @Handle said), or in future we’re looking at ways to run a bridge (and homeserver for that matter) locally on the client. So you’d have the option to either have a lightweight thin-client or a much heavier one which actually federates directly with Matrix (effectively acting as a server), which could likewise run bridging locally. Finally there may also be a halfway house in future where you can run a local bridge which puppets your local client to synchronise it with the remote protocol. We do this today in some places with SMS, where the local client effectively acts to bridge SMS in/out of Matrix.
hi metthew, its a little off-topic here but as you are so actively and competently answering about matrix here, i would like to know how the local home server concept should work. for know i can have an id at the matrix home server as username@matrix.org which is easy to resolve as there is a server with the matrix domain name. But how should this work with a local home server at any librem5 phone? would any user need a domain for his phone which also would be in need to be update as the ip is dynamic, especially with mobile networks? am i missing some thing?
i just installed riot the last days an like the idea of local home servers which could handle the bridges to other networks but doesn’t get it.
To be clear: the “local homeserver” idea is 100% vapourware scifi at this point, but still an interesting thought experiment about where things could go in future. It comes originally from https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%20Interop%20and%20Privacy.pdf, but the idea is basically: “if we supported a p2p protocol for federation, then you could run a homeserver on the client. This would both help preserve metadata privacy, as well as let you run local bridges”. It’s something we want to investigate over the next year or two. The user IDs would almost certainly end up looking like public key fingerprints (which isn’t a problem, given in practice the idea in Matrix is to invite people by email or phone number rather than their user ID).
Separately, there’s also the idea of having a ‘headless matrix daemon’ for an OS like PureOS which isn’t a full-blown homeserver, but acts as an ‘always on’ matrix client in the background, which other apps on the OS could connect to. This could also support running local bridges (which would act as a local app which ‘puppets’ the daemon to sync it with other protocols). This is also sci-fi atm, but something we’re actively discussing with Purism as a way to handle Matrix on the Librem5.
Thanks. i Like the ideas. Nice thing with the tor layer in between.
It’s hard to predict because our top priority is getting New Vector (the new company that employs the core Matrix team) fully incorporated and funded. There is at least a month or two of work remaining there. Once that is done, we’ll then be in position to work on other legal stuff like rewriting the privacy policy to be less scary (although in turn we have to balance that with time spent improving Matrix as a whole). So, “several months” unless something forces us to address it sooner.
i understand, there is no hurry, the important things is to do it as the best as you can, better to have a good privacy policy, something similar the one i wrote, in one year than a bad one in 3 months, and if there is something you have to because of UK law, if is possible should be clever to start the new company in another country like swiss or a privacy friendly one
thank you for your reply and your time
i’ve found no option on riot to automatic delete after a period a conversation on a room, for example to autodelete conversations older than a week, i’ve made a internet research and i also found if everyone leave a chat room the conversation still exist
any change of this in your roadmap, this option looks as huge lack of control of my conversation to me
“Matrix is only about synchronising conversation history” so removing the history is against Matrix core concept 
