Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App(matrix.org)
matrix.org
Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App
https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app/
203 comments
We’re working towards a 1.0 atm, which the French govt and many others are counting on. In terms of state res not being well specified: https://matrix.org/_matrix/media/v1/download/jki.re/hSmkLkFG... is pretty comprehensive and should be merged into the spec relatively soon. I say kudos to the French govt for backing a FOSS project which is still evolving :)
I don't mean to be disrespectful. The first time I heard of Matrix/Riot was at OSCOn 2015. What has happened since then,and why has it taken so long to stabilize?
We spent massive effort working on:
* implementing E2E encryption and getting it audited, which turns out to be very hard in a decentralised environment
* refining Riot as a flagship client and trying to get it to a Slack/Discord level of UX (still a work in progress)
* scaling, as the 1st gen implementation (synapse) failed to keep up with the growth of the network
* adding features like Jitsi video conferencing, Widgets, Communities, Home pages, Rich Text Editing, Read Receipts, Synchronised Read Markers and much much more.
* dealing with a major funding crisis last year.
In retrospect we probably should have spent more time finalising the current features rather than adding on new ones, and since the end of last year we've been feature-frozen in order to finish the stuff in hand and get to a 1.0.
Fixing the issues which remain in federated state resolution is probably the hardest problem to solve before a 1.0, and I'm happy to say that over the last few months we've made major progress in doing so.
Agreed that in an ideal world this would have all happened sooner, but turns out that decentralised open protocols are harder than centralised startups like Slack and friends. Who knew?
* implementing E2E encryption and getting it audited, which turns out to be very hard in a decentralised environment
* refining Riot as a flagship client and trying to get it to a Slack/Discord level of UX (still a work in progress)
* scaling, as the 1st gen implementation (synapse) failed to keep up with the growth of the network
* adding features like Jitsi video conferencing, Widgets, Communities, Home pages, Rich Text Editing, Read Receipts, Synchronised Read Markers and much much more.
* dealing with a major funding crisis last year.
In retrospect we probably should have spent more time finalising the current features rather than adding on new ones, and since the end of last year we've been feature-frozen in order to finish the stuff in hand and get to a 1.0.
Fixing the issues which remain in federated state resolution is probably the hardest problem to solve before a 1.0, and I'm happy to say that over the last few months we've made major progress in doing so.
Agreed that in an ideal world this would have all happened sooner, but turns out that decentralised open protocols are harder than centralised startups like Slack and friends. Who knew?
(oh, and we rewrote (almost) the whole thing in Go, too)
I saw someone bitching elsewhere about Python 2.7, but have yet to see any other semi-relevant complaints yet, so congrats to the team on that!
Any comment on that?
Any comment on that?
There is progress on Python 3 support:
> Preparation for py3 (PR #3061, #3073, #3074, #3075, #3103, #3104, #3106, #3107, #3109, #3110) Thanks to @NotAFile!
https://github.com/matrix-org/synapse/releases/tag/v0.28.0
> Preparation for py3 (PR #3061, #3073, #3074, #3075, #3103, #3104, #3106, #3107, #3109, #3110) Thanks to @NotAFile!
https://github.com/matrix-org/synapse/releases/tag/v0.28.0
Go is a great choice for implementing a network protocol but most of the time, rewriting is not a great choice (source needed).
Do you have any public discussions or blog posts about this decision?
Do you have any public discussions or blog posts about this decision?
So totally agreed that rewrites are almost always not a good idea, as per the famous "Things you should never do!" Joel Spolsky post (https://www.joelonsoftware.com/2000/04/06/things-you-should-...).
The difference for a project like Matrix however is that our product is not really any single software codebase but the protocol spec itself. In fact, it's a bad smell about the spec if it's too hard to implement it - whether that's clients or servers. So part of the point of the Dendrite (golang server) project is to dogfood the spec and fix its various shortcomings (as per the OP's complaints) and make sure it's fit for purpose. For context, the core Matrix team has already written 4 entirely disjoint Matrix client codebases (Matrix Console on Web, Riot/Web, Riot/iOS and Riot/Android) as part of developing the spec and ensuring it's fit for purpose, so it's not that unreasonable for us to also write 2 server implementations (3, if you include the failed Dendron project).
In terms of blog posts: https://matrix.org/blog/2017/03/15/dendrite-receives-its-fir... is probably the most revealing one.
It's worth noting however that Dendrite progress has not been entirely smooth, though. Particular problems have been:
* When we lost funding last year (https://matrix.org/blog/2017/07/07/a-call-to-arms-supporting...) it inevitably had an impact on the team - and ironically the only two people who left the project ended up being the two folks who were working on (and created) Dendrite. This genuinely wasn't a reflection on Dendrite itself (which is ironically one of the most fun projects to work on in Matrix, given it's all blue skies and green fields in terms of implementing a server that learns from Synapse's many mistakes), but more a sad coincidence. Either way, it ended up with the project being under-resourced (although we're finally fixing that during May having re-hired :)
* Matrix traffic accelerated massively during 2017, and Dendrite wasn't yet ready to use in production - but meanwhile Synapse wasn't performant enough to keep the matrix.org server running smoothly, so we had to pull folks off Dendrite in order to keep Synapse scaling (ironically, ending up taking inspiration to some extent from Dendrite in improving the Synapse codebase)
* In general, it's hard to make progress on an R&D project which isn't yet in production when there's an existing project in production which is on fire.
* We deliberately scoped Dendrite to implement a server against the current Matrix spec that Synapse implements - rather than trying to improve the Matrix spec at the same time. This is good in terms of feature creep, but possibly a bit demoralising as you find yourself failing to innovate and improve the spec and instead re-implementing it, warts and all. I'm not sure what the right balance is here, and in practice we've ended up with the Matrix spec evolving significantly under Synapse, and meanwhile Dendrite then becomes a moving target as a result.
* We've almost certainly fallen foul of the Osborne Effect (https://en.wikipedia.org/wiki/Osborne_effect) too, where folks have held off on using Matrix or running Synapse because they're waiting for Dendrite to land, RSN.
But on the plus side, there's a small but active FOSS community contributing to Dendrite - much more than we've ever had on the relatively impenetrable Synapse codebase. And Dendrite itself works (about 80% of an MVP complete) and is demonstrably ~2 orders of magnitude faster than Synapse (even whilst Synapse's performance is also speeding up). And as we find algorithmic breakthroughs in performance as part of improving Synapse, these breakthroughs equally apply to Dendrite and will make it even crazier fast.
So, I think it's too early to say whether this is a textbook example of "second system syndrome", or whether instead it's a mature and sensible approach to ensuring a heterogenous ecosystem of implementations for an open standard and dogfooding one's own protocol. My hunch is that if we hadn't hit funding nightmares last year it would be a no-brainer win; but even now, it's likely to eventually work out for the best in the end. The best analogy is not the excruciating migration from Netscape to Mozilla that Joel wrote about in 2000, but the more spectacular and successful migration from Gecko to Servo happening in Mozilla right now. It's a massive massive architectural improvement and rewrite in a new language which requires a lot of work, but pays off in the end.
(This is my personal take on it, at least, as project lead for Matrix; those actually working on Synapse & Dendrite probably have different viewpoints! :)
The difference for a project like Matrix however is that our product is not really any single software codebase but the protocol spec itself. In fact, it's a bad smell about the spec if it's too hard to implement it - whether that's clients or servers. So part of the point of the Dendrite (golang server) project is to dogfood the spec and fix its various shortcomings (as per the OP's complaints) and make sure it's fit for purpose. For context, the core Matrix team has already written 4 entirely disjoint Matrix client codebases (Matrix Console on Web, Riot/Web, Riot/iOS and Riot/Android) as part of developing the spec and ensuring it's fit for purpose, so it's not that unreasonable for us to also write 2 server implementations (3, if you include the failed Dendron project).
In terms of blog posts: https://matrix.org/blog/2017/03/15/dendrite-receives-its-fir... is probably the most revealing one.
It's worth noting however that Dendrite progress has not been entirely smooth, though. Particular problems have been:
* When we lost funding last year (https://matrix.org/blog/2017/07/07/a-call-to-arms-supporting...) it inevitably had an impact on the team - and ironically the only two people who left the project ended up being the two folks who were working on (and created) Dendrite. This genuinely wasn't a reflection on Dendrite itself (which is ironically one of the most fun projects to work on in Matrix, given it's all blue skies and green fields in terms of implementing a server that learns from Synapse's many mistakes), but more a sad coincidence. Either way, it ended up with the project being under-resourced (although we're finally fixing that during May having re-hired :)
* Matrix traffic accelerated massively during 2017, and Dendrite wasn't yet ready to use in production - but meanwhile Synapse wasn't performant enough to keep the matrix.org server running smoothly, so we had to pull folks off Dendrite in order to keep Synapse scaling (ironically, ending up taking inspiration to some extent from Dendrite in improving the Synapse codebase)
* In general, it's hard to make progress on an R&D project which isn't yet in production when there's an existing project in production which is on fire.
* We deliberately scoped Dendrite to implement a server against the current Matrix spec that Synapse implements - rather than trying to improve the Matrix spec at the same time. This is good in terms of feature creep, but possibly a bit demoralising as you find yourself failing to innovate and improve the spec and instead re-implementing it, warts and all. I'm not sure what the right balance is here, and in practice we've ended up with the Matrix spec evolving significantly under Synapse, and meanwhile Dendrite then becomes a moving target as a result.
* We've almost certainly fallen foul of the Osborne Effect (https://en.wikipedia.org/wiki/Osborne_effect) too, where folks have held off on using Matrix or running Synapse because they're waiting for Dendrite to land, RSN.
But on the plus side, there's a small but active FOSS community contributing to Dendrite - much more than we've ever had on the relatively impenetrable Synapse codebase. And Dendrite itself works (about 80% of an MVP complete) and is demonstrably ~2 orders of magnitude faster than Synapse (even whilst Synapse's performance is also speeding up). And as we find algorithmic breakthroughs in performance as part of improving Synapse, these breakthroughs equally apply to Dendrite and will make it even crazier fast.
So, I think it's too early to say whether this is a textbook example of "second system syndrome", or whether instead it's a mature and sensible approach to ensuring a heterogenous ecosystem of implementations for an open standard and dogfooding one's own protocol. My hunch is that if we hadn't hit funding nightmares last year it would be a no-brainer win; but even now, it's likely to eventually work out for the best in the end. The best analogy is not the excruciating migration from Netscape to Mozilla that Joel wrote about in 2000, but the more spectacular and successful migration from Gecko to Servo happening in Mozilla right now. It's a massive massive architectural improvement and rewrite in a new language which requires a lot of work, but pays off in the end.
(This is my personal take on it, at least, as project lead for Matrix; those actually working on Synapse & Dendrite probably have different viewpoints! :)
Oh, wow, thanks for the detailed response! I see that it makes sense for Matrix, and I hope you people all the luck for creating the next XMPP.
Great answer. It sounds like this was very much the right call for Matrix.
Are those Dendrite core developers that had to leave coming back now that you have secured funding?
Unlikely, sadly, having got jobs elsewhere before we secured long-term funding. However, it’s not like Dendrite is ownerless - we’ve made good progress on it since they left up until the point we had to temporarily double down on Synapse. Meanwhile, folks from the community who have been hacking on Dendrite are coming on board in the next few weeks. And the old devs are also still around in a FOSS contributor capacity; answering pings via Github and Matrix where needed.
https://github.com/matrix-org/dendrite/graphs/contributors paints a fairly clear picture of where things have got to (with Synapse temporarily taking priority since Jan).
https://github.com/matrix-org/dendrite/graphs/contributors paints a fairly clear picture of where things have got to (with Synapse temporarily taking priority since Jan).
Why would rewriting not be a great choice?
It's normally death for a company initiative. The problem is that it takes time for the rewrite to happen. While it's tempting to believe that since you wrote it once that it will be quick to write it again, usually it takes about the same amount of time to rewrite. This leads to vastly underestimating the time scale required. At the same time, the business tends to look about 6 weeks out. For those 6 weeks they are fine, but usually a "disaster" happens and you are required to make a "quick fix" to the original. "Disaster" after "disaster" happens and normally the rewrite is abandoned. Sometimes it continues, and when you finish you discover that nobody remembered about a really crucial set of requirements that are all but impossible to implement in the new system.
However, in an open source project rewrites are often successful. Sometimes it frustrates the users in the process (see GTK/Gnome/KDE rewrites) but often there is not enough pressure to kill the rewrite so it succeeds. Whether or not you'd be better off with the original is often an open question, though.
I don't know enough about Matrix/Riot to comment about whether their rewrite was a good idea. I hope they are happy with it.
However, in an open source project rewrites are often successful. Sometimes it frustrates the users in the process (see GTK/Gnome/KDE rewrites) but often there is not enough pressure to kill the rewrite so it succeeds. Whether or not you'd be better off with the original is often an open question, though.
I don't know enough about Matrix/Riot to comment about whether their rewrite was a good idea. I hope they are happy with it.
I was involved in a rewrite of a ~10 year old vb app to C#. A lot of it involved rewriting the code almost line for line in C# then adding unit tests and refactoring. It took a team of 4 about 6 months for most of the work. At the end we had a solid and now much easier to maintain app that was consistent with the rest of our application suite.
Highly successful project. Sometimes a rewrite is the right choice.
Highly successful project. Sometimes a rewrite is the right choice.
lots of hack fixes made late in the evening with a comment
//this seems to work now, not sure why, but it does, should really look at this in the morning 2012-05-12
//this seems to work now, not sure why, but it does, should really look at this in the morning 2012-05-12
Second System Syndrome [1]
and General experience [2]
mostly because legacy systems contain a lot of implicit features and undocumented decisions that are hard to re-discover and customers get really annoyed. Maybe less of a problem in this case since it is young and rather well defined domain.
[1] https://en.wikipedia.org/wiki/Second-system_effect
[2] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
and General experience [2]
mostly because legacy systems contain a lot of implicit features and undocumented decisions that are hard to re-discover and customers get really annoyed. Maybe less of a problem in this case since it is young and rather well defined domain.
[1] https://en.wikipedia.org/wiki/Second-system_effect
[2] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I discovered Matrix through the Godot Game Engine community. It was described to me as the next-gen irc freenode chat platform for open source devs ;)
Just wondering about discovery. How do I find interesting channels?
Just wondering about discovery. How do I find interesting channels?
One of the community members has a bot that travels from room to room anytime somebody mentions a room link.
The list (and graph!) of all indexed rooms is here: https://t2bot.io/voyager/
The list (and graph!) of all indexed rooms is here: https://t2bot.io/voyager/
Yep. Their docs inspire little hope that the protocol will be little more than niche. How to build on top of this protocol without requiring someone with domain specific knowledge is beyond what's offered. Cue XKCD protocols comic.
Matrix is gaining adoption throughout the open source world super quickly. There are screenshots, guides, and links to join all over the place. Given that, I'm really impressed that anyone looks at Matrix and thinks of it as "little more than niche".
Just clarify since I've upset some members of its community. I'm speaking from a development perspective. Sure Riot might have a large amount of users online, but what portion of that is people developing on top of the protocol. As I originally stated the docs are less than stellar, considering there are many missing pieces. So other than the original dedicated developers building a few things for a large community, it would appear that on the development side that it is very difficult to get started. As in: I have to seek out someone with specific domain knowledge and ask hundreds of questions and take lots of notes in order to extend and use the matrix protocol properly. Which makes something designed to be open, little more than niche.
Totally agreed that the spec is not where it should be; it has suffered from lack of dev bandwidth after funding mess last year, as we had to shift folks from spec to Synapse work in order to keep up with the growth of the network. we have someone joining end of May who should have specific bandwidth to work on it as part of their day job; we have a goal to close all the gaps by Aug.
> There are screenshots, guides, and links to join all over the place.
Given that matrix describes itself as an open standard, neither of those aspects says much about the project other that there's either some goodwill or a PR department.
Given that matrix describes itself as an open standard, neither of those aspects says much about the project other that there's either some goodwill or a PR department.
fwiw there's no PR or marketing department, unless you count me trying to field questions.
Right now there are 4.5M registered users on the matrix.org HS alone, so I’m not sure niche is right ;)
An interesting number would be how many GCM/APN devices are registered in the matrix.org sygnal server.
All of the Matrix/Riot users I know use private, non-federated home servers, but still rely on the project's Sygnal server(s) for push notifications.
All of the Matrix/Riot users I know use private, non-federated home servers, but still rely on the project's Sygnal server(s) for push notifications.
Sygnal doesn't track this, actually. The best figure i have is that right now the matrix.org HS has 125,209 registered pushers - but as sygnal doesn't store registrations in its DB, I don't have an easy way to say how many Riots on other homesevers are routed through it.
Phone number/email verification is also still centralized as no one has worked out any other way.
Only to the extent that identity servers themselves are centralised, and Matrix lets you run your own.
It's sort of ironic considering France's history with Minitel[0] and encryption[1].
[0]: https://en.wikipedia.org/wiki/Minitel
[1]: https://www.forbes.com/forbes/1997/1201/6012058a.html#75b6a6...
Specifically from [1] is the line: "Its illegal in France to encrypt any communication in any way unless you have permission from the government. How is electronic commerce going to get off the ground in such a society? Good question, which appears not to have occurred to the authorities."
[0]: https://en.wikipedia.org/wiki/Minitel
[1]: https://www.forbes.com/forbes/1997/1201/6012058a.html#75b6a6...
Specifically from [1] is the line: "Its illegal in France to encrypt any communication in any way unless you have permission from the government. How is electronic commerce going to get off the ground in such a society? Good question, which appears not to have occurred to the authorities."
Thankfully, since 2004, the law for trust in the digital economy[0] (LCEN) mostly liberalized the use of cryptography[1].
[0]: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFT...
[1]: https://en.wikipedia.org/wiki/Cryptography_law#France
[0]: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFT...
[1]: https://en.wikipedia.org/wiki/Cryptography_law#France
The US used to regulate "exports" of cryptography under the U.S. Munitions List. Some of the restrictions still remain, but most of them were gradually relaxed in until 2000.
I can't even download FPGA toolchains like a regular person without an account saying I live in the US and a US VPN to support my claim. FPGAs still accounted as ammo, even if you get the dev boards from China.
I'm looking at you, Xilinx.
I'm looking at you, Xilinx.
I don't live in the US and downloaded the latest Xilinx tools earlier this week, don't work for a US company either.
It's a hit or miss, and sometimes accounts get "flagged". From France I didn't have a problem until I connected from Ukraine; since then I have to always fill the infamous "download workaround form" that may or may not succeed, in the best case you get the download link in an email a few days later. Also the download workaround form doesn't let you select the most recent versions of Vivado and ISE.
It's pretty common. Almost all EU governments reserve the right to decrypt encrypted communications by law, also India, Russia, China, Australia. Here's a map https://www.gp-digital.org/world-map-of-encryption/, click 'Powers to intercept...'
I've always wondered about that. The law says
Criminal Procedure Code: Article 230, modified by Law No. 2001-1062
and Law No. 2014-1353 requires the disclosure of encryption keys upon
the authorization of a judge.
I expect you get convicted for not turning over the keys I assume, unless its clear that some other service provided made that technical choice for you in which case hopefully they get convicted.
I would see this as a positive step - it’s a lot harder to legislate against E2E crypto for the populous when the govt is relying on it :)
It has nothing to do with Minitel as it is a private government only slack-like tool. And the encryption restriction is long gone like in the US. Why there is alway francophobes in threads like that ?
[deleted]
Congrats Matrix team! That is huge.
Competitor here, few questions:
- You guys are currently implementing federated protocols, right? We do P2P protocols, I'm curious why you guys chose federated - why do you think it is better?
- How are you guys different than Signal? Obviously way different than Telegram, as it isn't even Open Source (thanks for Open Sourcing your work!).
- When I was working on our E2EE private messaging app (ugly demo here: https://twitter.com/marknadal/status/989602258638684160 ), I ran into problems about metadata. Stuff like, do you guys reveal which public keys are talking to which other public keys? And the frequency of those conversations? Or do you encrypt that information as well (and if you do, how do you handle discovery then, and is it vulnerable to network frequency analysis attacks?)
Awesome work, congrats again, keep it up! Curious to hear more about your architecture.
Competitor here, few questions:
- You guys are currently implementing federated protocols, right? We do P2P protocols, I'm curious why you guys chose federated - why do you think it is better?
- How are you guys different than Signal? Obviously way different than Telegram, as it isn't even Open Source (thanks for Open Sourcing your work!).
- When I was working on our E2EE private messaging app (ugly demo here: https://twitter.com/marknadal/status/989602258638684160 ), I ran into problems about metadata. Stuff like, do you guys reveal which public keys are talking to which other public keys? And the frequency of those conversations? Or do you encrypt that information as well (and if you do, how do you handle discovery then, and is it vulnerable to network frequency analysis attacks?)
Awesome work, congrats again, keep it up! Curious to hear more about your architecture.
> why federated, not decentralized?
afaict, Matrix is both, kind of. Rooms are decentralized, while users are federated.
> What about signal?
Signal is great, but it solves a very different problem. It's a good replacement for talking to your best friends on your phone.
But it fails quickly once you go past that. No true multi-device, no talking without releasing your phone number, no public groups. No mentions, no permalinks. In that regard, I'd say matrix is closer to telegram and irc than WhatsApp or Signal
> what about metadata?
The state of metadata in E2E is... not good. Really, only the content of the message is secret. There are a number of ideas how to deal with this.
afaict, Matrix is both, kind of. Rooms are decentralized, while users are federated.
> What about signal?
Signal is great, but it solves a very different problem. It's a good replacement for talking to your best friends on your phone.
But it fails quickly once you go past that. No true multi-device, no talking without releasing your phone number, no public groups. No mentions, no permalinks. In that regard, I'd say matrix is closer to telegram and irc than WhatsApp or Signal
> what about metadata?
The state of metadata in E2E is... not good. Really, only the content of the message is secret. There are a number of ideas how to deal with this.
> Signal is great, but it solves a very different problem. It's a good replacement for talking to your best friends on your phone.
Riot does this pretty well, and when it's not alpha/beta, it'll probably do it really well.
Riot does this pretty well, and when it's not alpha/beta, it'll probably do it really well.
I had to roll my own chat system recently because the open source solutions out there were surprisingly insufficient - nothing seems to support websockets. Looking forward to the French contributions to the ecosystem!
For instance: at the moment Matrix server implementations expect clients like Riot to long-poll for JSON about each room/chat they're connected to. Alternatives like Prosody's XMPP server implementation dropped websocket support in favor of BOSH years ago.
I wonder why this is - maybe there's just less developer interest since chat has gone mobile, and mobile devices break ws connections so frequently? But it's obvious that chat clients like FB messenger, whatsapp, slack, etc are establishing ws connections.
Strange.
For instance: at the moment Matrix server implementations expect clients like Riot to long-poll for JSON about each room/chat they're connected to. Alternatives like Prosody's XMPP server implementation dropped websocket support in favor of BOSH years ago.
I wonder why this is - maybe there's just less developer interest since chat has gone mobile, and mobile devices break ws connections so frequently? But it's obvious that chat clients like FB messenger, whatsapp, slack, etc are establishing ws connections.
Strange.
Network overhead aside, long polling can be a pretty wonderful interface. “Give me what I don’t have yet, else let me know when there is something” makes for reliable transmission that is hard to screw up. Long polling requests can work idempotently and recover from network failures automatically. I think it’s an especially wise starting point.
> Prosody's XMPP server implementation dropped websocket support in favor of BOSH years ago.
You probably refer to the "old websocket" spec, new websockets are working well: https://prosody.im/doc/modules/mod_websocket
You probably refer to the "old websocket" spec, new websockets are working well: https://prosody.im/doc/modules/mod_websocket
FB messenger actually uses MQTT last time I checked. In practice long poll HTTP is fine for most purposes, and meanwhile we have a GSoC project which should help improve on that this year (starting with push; then the protocol itself): https://summerofcode.withgoogle.com/organizations/?sp-search...
> Prosody's XMPP server implementation dropped websocket
Quite the opposite, but I admit the documentation is in need of improving to make the websocket functionality easier to discover.
It is in the default config file however, right next to BOSH.
Quite the opposite, but I admit the documentation is in need of improving to make the websocket functionality easier to discover.
It is in the default config file however, right next to BOSH.
Rocket Chat supports WebSockets. They don't advertise it very well, but if you look at the nginx config under the manual installation, you'll see that the 'upgrade' header is added when using nginx as a reverse proxy, presumably for ws support. Also, they have an experimental realtime API that uses WS and it looks like it's just the API that is still experimental, while WS are already in use for the regular desktop app and the new (still buggy) mobile app.
Matrix also supports WS actually but nobody bothers with it: https://github.com/matrix-org/matrix-doc/blob/master/drafts/...
WeeChat's (the IRC client, not the similarly-named Chinese messenger) relay protocol uses websockets. This is what enabled us to build Glowing Bear, a web frontend that connects to your WeeChat instance from your browser. I like to think of that as pretty cool :) (Disclosure: I'm one of the Glowing Bear developers, so of course I'd think it's cool)
[deleted]
Tigase XMPP server supports websocket out of the box as well (bosh as well)
I tried matrix/riot out, looks perfect for me and app is slick.
Sending messages though from a server to a room was more difficult than I expected. Java SDK didn't build and many of the other languages were alpha too. Go seemed favored but I dont really want to install. Is there a recommended simple command line app or script to send messages?
Sending messages though from a server to a room was more difficult than I expected. Java SDK didn't build and many of the other languages were alpha too. Go seemed favored but I dont really want to install. Is there a recommended simple command line app or script to send messages?
There's work currently being done by Gnome to make a GTK client written in Rust at https://gitlab.gnome.org/World/fractal/.
I recently installed it a matrix server (synapse the official implementation) and can connect to it through the riot.im web cilent (on the riot.im website) and riot.im node client.
The preview docker image of mattermost is easier to install but I installed matrix because I couldn't get the production docker version of mattermost to work.
I wasted most of time configuring the vhost and the SSL certificates.
The preview docker image of mattermost is easier to install but I installed matrix because I couldn't get the production docker version of mattermost to work.
I wasted most of time configuring the vhost and the SSL certificates.
curl? O:-) Matrix is intended to be simple enough that you don’t even need an SDK unless you really want one.
which java sdk did you try?
which java sdk did you try?
> Matrix is intended to be simple enough that you don’t even need an SDK unless you really want one.
Huh. So Haskell + Servant might be really nice for writing a client, then, yeah?
Huh. So Haskell + Servant might be really nice for writing a client, then, yeah?
Anything you can make HTTP requests in really. I have messed around with sending messages from Ruby and Bash and it's quite easy. And a lot more easy if there is an SDK for your language which will handle a few things for you.
So what's irssi for Matrix?
weechat-matrix. You should be using weechat over irssi anyway!
Why? Longtime irssi user here.
I usually view it as a cost–benefit sort of thing. When a choice has nearly zero cost, only very little benefit is needed to make it the rational choice as far as I'm concerned.
What does WeeChat offer over irssi? Very active development, scripting in many languages, dynamic filtering, raw buffer views, sane defaults, helpful configuration interface, good documentation, live/hotswapping upgrades, architectural soundness, many options for interaction (FIFO pipes, client-server protocol) and so on and so forth. I'm always surprised at how little WeeChat gets in my way when I want to do something out of the ordinary.
And unless you are heavily invested in the irssi ecosystem, the switch is basically effortless.
That's the cost–benefit of it. Another way to view it is this: People who switch from Irssi to WeeChat keep using WeeChat; while people who switch from WeeChat to Irssi go back to WeeChat.
What does WeeChat offer over irssi? Very active development, scripting in many languages, dynamic filtering, raw buffer views, sane defaults, helpful configuration interface, good documentation, live/hotswapping upgrades, architectural soundness, many options for interaction (FIFO pipes, client-server protocol) and so on and so forth. I'm always surprised at how little WeeChat gets in my way when I want to do something out of the ordinary.
And unless you are heavily invested in the irssi ecosystem, the switch is basically effortless.
That's the cost–benefit of it. Another way to view it is this: People who switch from Irssi to WeeChat keep using WeeChat; while people who switch from WeeChat to Irssi go back to WeeChat.
What I don't like about WeeChat is the UI. It's subtly different from irssi’s, which makes it difficult for me to switch.
On a scale from ed to Office 365, WeeChat and irssi have practically the same default UI -- and it's butt-ugly. But I do see your point, and it's likely configurable. Anything specific you need help with?
thanks, I thought it was a bit more complicated with session ids etc, will look at keeping it simple again.
I used the Java SDK from Kamax that was on https://matrix.org/docs/projects/try-matrix-now.html. would be nice if there are others.
I'm excited about it though - is just what I've been looking for.
I used the Java SDK from Kamax that was on https://matrix.org/docs/projects/try-matrix-now.html. would be nice if there are others.
I'm excited about it though - is just what I've been looking for.
I am the author of the SDK - feel free to open an issue on the github repo or come in the dedicated Matrix room #matrix-java-sdk:kamax.io and we'll get you started.
Does this make freedom of information requests less useful to the public?
No. The information being securely stored does not mean users wouldn't have to turn over the information. However usually FoI doesn't usually apply to instant messaging anyway, I think.
In France, there is also no general Freedom of Information law, except for some administrative documents.
Depending on the jurisdiction it's an offence to withhold or destroy information that is meant to be available under FoI.
I sure as hell hope so. Otherwise, what's the point of FoI in the first place?
Judging from http://www.ucl.ac.uk/constitution-unit/research/foi/countrie... it is already not useful. However theoretically, yes. It is hard to discover which encrypted communications are potentially relevant, and if the officials in question are doing something wrong then they have no cause to cooperate.
What do you mean ?
If progressively more governmental communications are made through encrypted means, we cannot access them as citizens.
If they're subject to records retention requirements, they should be retained anyway; and if they're not, they're in the same category as things like phone calls which are currently ephemeral.
(Note that in first world countries phone calls will be digital everywhere except maybe the last mile, and GSM and upwards are digital to the handset)
(Note that in first world countries phone calls will be digital everywhere except maybe the last mile, and GSM and upwards are digital to the handset)
End to End encrypted does not mean the messages have to be stored and retained encrypted and inaccessible. I imagine the responsible sysadmins have figured out something to follow retention laws.
You're not supposed to be able to access any and every government communication. You're not supposed to know what the nuke codes are, or when there's an undercover mission in progress, or [insert punchline here].
Presumably, if there's an investigation, they just force the government employee to give up the keys.
Presumably, if there's an investigation, they just force the government employee to give up the keys.
Yeah, end-to-end encryption is strange here. Aren't there laws in France to ensure retention of government employee communications?
And this is somewhat okay. Though in my opinion there should be some way to lawfully intercept, this brings us back to the same dilemma as with private messaging.
Thanks, I understand but those communications are not supposed to be accessible. This tool will be used by top level gouvernement employees.
Indeed
Freedom of information....which amendment is that :P ?
This is France we're talking about, so it's not amendments, but rather Article XV of the "Déclaration des droits de l'homme et du citoyen de 1789": https://en.wikipedia.org/wiki/Declaration_of_the_Rights_of_t... ("The society has the right of requesting an account from any public agent of its administration."), which is used as the basis for actual legislation today: http://www.ucl.ac.uk/constitution-unit/research/foi/countrie...
I am sorry, I am not french. I thought this is some stupid American law which every Americans expect the rest of the world to know.
Article 34, apparently, although I can't really see how it's interpreted from the text.
http://www.conseil-constitutionnel.fr/conseil-constitutionne...
http://www.ucl.ac.uk/constitution-unit/research/foi/countrie...
http://www.conseil-constitutionnel.fr/conseil-constitutionne...
http://www.ucl.ac.uk/constitution-unit/research/foi/countrie...
This should make the Librem 5 a more attractive phone in France: https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-...
I don't know much about licenses: is Matrix and/or the protocol safe from Facebook, Google and co to pull the same thing again? Feels like EEE is inevitable when these companies allocate resources to provide a better UI/UX and benefits in their own services.
I have no clue what you are trying to ask, sorry. Could you clarify?
Do you mean IP lawsuit's against Matrix itself?
Do you mean IP lawsuit's against Matrix itself?
I guess grandparent means how Google (and later Slack) initially supported XMPP in their chat products, then disabled the XMPP gateway once their userbase was significantly large that most conversations were inside their own bubble.
There's not much that Matrix can do to defend against that, except for strategic marketing with the purpose of achieving a large distributed userbase. If Gmail had existed in 1990, we would not have a decentralized e-mail network today. If Gmail had got into a position where they served 99% of all e-mail users, they would've pulled the plug on mail delivery to third-party mail servers and e-mail as we know it would've been dead.
There's not much that Matrix can do to defend against that, except for strategic marketing with the purpose of achieving a large distributed userbase. If Gmail had existed in 1990, we would not have a decentralized e-mail network today. If Gmail had got into a position where they served 99% of all e-mail users, they would've pulled the plug on mail delivery to third-party mail servers and e-mail as we know it would've been dead.
Isn't that what is slowly happening? My understanding is that it's becoming harder and harder to send email to a Gmail address of you are not yourself using Gmail (without being tagged as spam/junk I mean)
I host my mails and to my surprise, gmail has been one provider which hasn't caused me any trouble so far in 2 years, with Yahoo.
I have proper configuration for dkim, SPF and dmarc. Even when my mails were somewhat misconfigured it worked with gmail.
When a recipient has a gmail or a Yahoo address, I am quite confident that my mails will make it into their inbox correctly.
Not that I'm glad that most people I email with use gmail, since I'm precisely hosting my mails to escape Google (well, this is one of the reasons).
I cannot say that for Microsoft. After a long discussion with them, I think I'm not systematically landing in my recipients' spam folder anymore, but I'm still not very confident. Microsoft, please fix your filters! If I already exchanged with somebody in a two-way direction several times, my mails should not land in their spam folder anymore, especially if they explicitly marked me as not spam (even more if they added me to their contact list), and if you observed only legitimate mails for months or even years from my IP/domain, my mails should not be treated as spam by default even for new recipients, right? Good and reasonable filters are important for internet neutrality, where small providers can exist.
Not that I'm glad that most people I email with use gmail, since I'm precisely hosting my mails to escape Google (well, this is one of the reasons).
I cannot say that for Microsoft. After a long discussion with them, I think I'm not systematically landing in my recipients' spam folder anymore, but I'm still not very confident. Microsoft, please fix your filters! If I already exchanged with somebody in a two-way direction several times, my mails should not land in their spam folder anymore, especially if they explicitly marked me as not spam (even more if they added me to their contact list), and if you observed only legitimate mails for months or even years from my IP/domain, my mails should not be treated as spam by default even for new recipients, right? Good and reasonable filters are important for internet neutrality, where small providers can exist.
It's still federated, its just harder to federate your own instance. It is still totally doable you just have to jump through the hoops of setting up SPF, DKIM, and DMARC.
Will this make end-to-end encryption finally get the polish it needs?
Who knows, polish is not something that's really needed for enterprise since the employees can often simply be forced to use the tools almost regardless of their state.
Within Riot, polishing e2e is already top of our priority list, but yes it definitely doesn’t harm having high profile entities like this expecting it.
Do you feel like WhatsApp is not polished?
If polish is broadly defined as "something that was hitherto still missing in (claimed-to-be) end to end encrypted chat applications", then open source and a decent profit model are definitely features lacking from WhatsApp. Telegram is open source, but one has to consciously turn on encryption and it doesn't work on the web or desktop clients (and the profit model is non-existent). Signal doesn't work without Google services and requires a phone number and turned-on phone iirc (and their profit model seems to be extorting companies like Wire and helping closed source software like Whatsapp advertise with Signal-level encryption). Wire is the best of all, but the Android app drains battery and everything is web (slow, bulky; Electron). None of the above work in a decentralized manner, either.
I don't know much about Matrix or Riot.im (from what I remembered, it was a implemented IRC alternative), but if it delivers on all of the above (and the article sure sounds like it), then it's definitely polishing up some final features that were still missing!
I don't know much about Matrix or Riot.im (from what I remembered, it was a implemented IRC alternative), but if it delivers on all of the above (and the article sure sounds like it), then it's definitely polishing up some final features that were still missing!
Very surprised to never see Keybase mentioned in these discussions. Everything, even the team chats, are end-to-end encrypted with a pretty slick interface.
You can even send E2E-encrypted messages/files to people who haven't even joined yet!
https://keybase.io/blog/keybase-chat
You can even send E2E-encrypted messages/files to people who haven't even joined yet!
https://keybase.io/blog/keybase-chat
Telegram is not really open source.
The server is not, and the Android code is updated months after each update, all commits being squashed(see issue[1]). Also their new app (Telegram X) is not open source.
[1] https://github.com/DrKLO/Telegram/pull/1431
The server is not, and the Android code is updated months after each update, all commits being squashed(see issue[1]). Also their new app (Telegram X) is not open source.
[1] https://github.com/DrKLO/Telegram/pull/1431
>Signal doesn't work without Google services
Not true, it has a websockets alternative to gcm.
>and requires a phone number
The phone number can be anything you control.
>and turned-on phone iirc
Yes
>(and their profit model seems to be extorting companies like Wire and helping closed source software like Whatsapp advertise with Signal-level encryption).
It (now) has its own nonprofit backing it (and a generous benefactor). It's not trying to be profitable.
The "extortion" thing seems to have been about wire using signal code in breach of copyright (ie not complying with the open source license).
Signal has stated that the goal of working with WhatsApp (and others) is to make good crypto be used as widely as possible. Matrix crypto is also based on what's used in signal.
>Wire is the best of all, but the Android app drains battery and everything is web
Signal is very polished (at least on Android - I'm not familiar with the ios app).
Not true, it has a websockets alternative to gcm.
>and requires a phone number
The phone number can be anything you control.
>and turned-on phone iirc
Yes
>(and their profit model seems to be extorting companies like Wire and helping closed source software like Whatsapp advertise with Signal-level encryption).
It (now) has its own nonprofit backing it (and a generous benefactor). It's not trying to be profitable.
The "extortion" thing seems to have been about wire using signal code in breach of copyright (ie not complying with the open source license).
Signal has stated that the goal of working with WhatsApp (and others) is to make good crypto be used as widely as possible. Matrix crypto is also based on what's used in signal.
>Wire is the best of all, but the Android app drains battery and everything is web
Signal is very polished (at least on Android - I'm not familiar with the ios app).
You do not control a phone number.
You can control an SSL cert using DNSSEC.
So you cannot control your signal end-point. Besides, the signal server is in total control of your identity. Plus anyone might still use the phone number to send plain-text SMS'.
TLDR: If you don't control the server, there is no security guarantee. So signal, whatsapp and telegram are out.
TLDR: If you don't control the server, there is no security guarantee. So signal, whatsapp and telegram are out.
For signal the phone number serves as a convenience to label a public key - the security comes from verifying the key. The design is to not trust the server.
WhatsApp is the same but has things like key-change messages off by default.
I believe telegram doesn't even encrypt by default, and has flawed crypto anyway.
You're right that the whole thing is flawed to some degree unless both parties are clued up.
WhatsApp is the same but has things like key-change messages off by default.
I believe telegram doesn't even encrypt by default, and has flawed crypto anyway.
You're right that the whole thing is flawed to some degree unless both parties are clued up.
DNSSEC is as secure as SMS.
But signal also uses name servers to connect clients. HIP, the host identity protocol, is the answer. Check out my nick. I'm not a big fan of the current naming system of the internet. Self-certifying names are needed.
Edit: If DNSSEC is as secure as sms, then signal is as secure as sms.
Edit: If DNSSEC is as secure as sms, then signal is as secure as sms.
You mean for metadata, of course.
Not message contents etc.
Not message contents etc.
you can use signal without any google services though, for more than a year now even.
related commit: https://github.com/signalapp/Signal-Android/commit/166973132...
pretty difficult to find the raw apk though: https://signal.org/android/apk/
about matrix:
you will probably end up having to use the electron riot app for a while, but the community is working hard on native clients, but afaik no client has e2ee in any usable state implemented yet (but a lot of progress is being made).
I think the matrix.org team acts as a non-profit organisation, but most of the core team is also hired by New Vector where, I think the planned profit model is to run matrix instances as a service.
there's some stuff about the funding in the faq: https://matrix.org/docs/guides/faq.html#what-kind-of-company...
related commit: https://github.com/signalapp/Signal-Android/commit/166973132...
pretty difficult to find the raw apk though: https://signal.org/android/apk/
about matrix:
you will probably end up having to use the electron riot app for a while, but the community is working hard on native clients, but afaik no client has e2ee in any usable state implemented yet (but a lot of progress is being made).
I think the matrix.org team acts as a non-profit organisation, but most of the core team is also hired by New Vector where, I think the planned profit model is to run matrix instances as a service.
there's some stuff about the funding in the faq: https://matrix.org/docs/guides/faq.html#what-kind-of-company...
> you can use signal without any google services though, for more than a year now even.
I tried it less than a year ago, because I had heard that too, but it still didn't work. I should try again on my new phone I guess.
I tried it less than a year ago, because I had heard that too, but it still didn't work. I should try again on my new phone I guess.
Do you really believe that Facebook (US company) has not complied with the US goverment and WhatsApp is safe for private communication?
Right!? Anyone who believes Facebook's WhatsApp is actually end to end encrypted and gives no access to the message data is laughably naive.
I don't usual respond to conspiracist posts, but maybe you're going to take Moxie Marlinspike's word for it ?
https://signal.org/blog/whatsapp-complete/
https://signal.org/blog/whatsapp-complete/
Conspiracy theories aside, why would anyone's word be sufficient? How about the code? Give us the code, then we don't need anyone's promises. Enough with promises!
Even the code is not enough, is it? Once you have it, how do you know that's what they deploy?
I deploy my own code.
Do you feel like WhatsApp is open-source and can be found on f-droid ?
WhatsApp has horrible user experience compared to Telegram.
And that's low hanging fruit.
And that's low hanging fruit.
I don't know yet a lot about Matrix but it's a wonderful step forward for government independence.
yes.
Great to read this kind of news!
I can't wait to see the end product (this summer 2018) :)
I can't wait to see the end product (this summer 2018) :)
well, this is what scares me. because, the conversation may be encrypted (protocol, packets), but still messages can be accessible by the powers that be through variety of means.
especially considering they "forked" it, who knows what they will do with it (log keystrokes, take screenshots, in the disguise of diagnostic reasons?).
anytime you are reading a message from your app, or sending a message, the app have all the powers to capture the data in its raw form before transmission, encrypt it with some key that only they have control of, etc. so unless the gov't releases their source code to be truly open (which even then i don't see how you will ever know), you won't get the transparency you need.
encryption is such a buzzword, people think anything encrypted means you are fully secure. this is simply false.
especially considering they "forked" it, who knows what they will do with it (log keystrokes, take screenshots, in the disguise of diagnostic reasons?).
anytime you are reading a message from your app, or sending a message, the app have all the powers to capture the data in its raw form before transmission, encrypt it with some key that only they have control of, etc. so unless the gov't releases their source code to be truly open (which even then i don't see how you will ever know), you won't get the transparency you need.
encryption is such a buzzword, people think anything encrypted means you are fully secure. this is simply false.
From the 2nd paragraph:
We understand the whole project is going to be released entirely open source (other than the operational bits)
– development is well under way and an early proof of concept is already circulating within various government
entities.
The app is developed for use within the government. In which case, a keylogger in the app makes as much sense as a keylogger on any civil servant's workstation or professional phone.
At some point, if you work for the government you have to use and trust the tools at your disposal. You are part of the executive power, after all.
At some point, if you work for the government you have to use and trust the tools at your disposal. You are part of the executive power, after all.
As someone else said: Matrix is an open protocol spec. If they use Matrix, then you can choose to use any client and not just their client. If they require their custom client, it could be argued they are no longer using Matrix.
It will guarantee secure, end-to-end encrypted conversations without degradation of the user experience. It will be compatible with any mobile device or desktop, state or personal.
Is the application they're creating also going to be open source and available for auditing?
Is the application they're creating also going to be open source and available for auditing?
that is the plan, except the operational bits specific to their deployments
hello
i am new here and a noob.
But this application messenger is only maked for France government use or also for everbody people around the world?
thereby, Riot is developed by the france government. Big change it has a back-door or something. you cant trust it as a citizen. correct me if i wrong but this sound like a honey pot to me.
thereby, Riot is developed by the france government. Big change it has a back-door or something. you cant trust it as a citizen. correct me if i wrong but this sound like a honey pot to me.
So what's wronng with signal?
No, what's wrong with more alternatives?
For small private chats on your phone, not a lot, but because of a number of decisions, it does not work very well with large IRC-style rooms full of people you might not know.
You can't run your own signal server. If that isn't huge then nothing is.
To be more precise you can run your own server but it would not connect to the rest of the network (so it's useless).
Source code here: https://github.com/signalapp/Signal-Server
Source code here: https://github.com/signalapp/Signal-Server
Why was Telegram and WhatsApp installation not possible before?
Because of closed source.
Because it's not sovereign.
Don’t suppose anyone knows why the Signal protocol wasn’t chosen?
Because Signal is centralized. With Matrix they can deploy different servers across the gouvernement which interoperate. And potentially open it to the wider Matrix ecosystem
Signal, the service is centralized, but there's no reason that Signal, the protocol can't be. In fact before Moxie went on his silly "only I can do security right" rampage, Signal was federated with a server hosted by CyanogenMod.
The E2EE in matrix is actually based on the double ratchet from the Signal protocol. So you could think of the E2E in matrix as just a federated version of Signal. :)
A point in moxie's favor is that the e2ee ux in matrix is currently extremely painful. I'm willing to use it on a couple rooms that consist entirely of geeks, but don't want to subject non-geeks to the whole verification process.
Not only UX, but there seem to be some subtle timing (in non-crypto/non-security meaning) issues.
I ran Synapse on a resource-limited machine, so it had sort of "lagged behind" (or something like that) a little bit now and then. And I saw a number of "error decrypting image" and similar issues. It had self-resolved somehow after a while (saw the message decrypted the next day) but that's still a problem.
Haven't reported this because I have no idea how to collect any useful information.
I ran Synapse on a resource-limited machine, so it had sort of "lagged behind" (or something like that) a little bit now and then. And I saw a number of "error decrypting image" and similar issues. It had self-resolved somehow after a while (saw the message decrypted the next day) but that's still a problem.
Haven't reported this because I have no idea how to collect any useful information.
Why do your non-geek friends have to verify? None of mine do.
>In fact before Moxie went on his silly "only I can do security right" rampage
Do you have link or source for that? (I'm always interested in listening or watching stuff from Moxie)
Do you have link or source for that? (I'm always interested in listening or watching stuff from Moxie)
The posts that really left me disappointed are:
https://signal.org/blog/the-ecosystem-is-moving/
https://whispersystems.discoursehosting.net/t/how-to-get-sig...
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
I suppose "only I can do security right" is perhaps overly harsh, but my take away was that he considered a walled garden that could be iterated on by his team preferable to allowing even forks of his team's own client to communicate with users on the OWS network.
https://signal.org/blog/the-ecosystem-is-moving/
https://whispersystems.discoursehosting.net/t/how-to-get-sig...
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
I suppose "only I can do security right" is perhaps overly harsh, but my take away was that he considered a walled garden that could be iterated on by his team preferable to allowing even forks of his team's own client to communicate with users on the OWS network.
Probably https://signal.org/blog/the-ecosystem-is-moving/
>Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.
>Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.
Moxie is probably annoyed by the slow pace in which federated protocols move. Having it centralized he can move it a lot faster.
Fortunately there are solutions that incentivize modern features in federated protocols too, like SSLLabs HTTPS checker or https://conversations.im/compliance/ for XMPP.
Fortunately there are solutions that incentivize modern features in federated protocols too, like SSLLabs HTTPS checker or https://conversations.im/compliance/ for XMPP.
[deleted]
Because when you build something like this, you shouldn't:
- requiere a phone
- build on s3 & a lot of other services without the option of a self hosted alternative.
Look up the signal server requirements.
- requiere a phone
- build on s3 & a lot of other services without the option of a self hosted alternative.
Look up the signal server requirements.
Yup. Signal sounds great but I can't use it because I don't have (or want) a smartphone with a phone number. I use Matrix clients instead.
will it erode trust ? or the opposite ?
I won't be using a 'secure' messaging app built by the govt any time soon...
AFAIK, this is mostly intended as a secure messenger _for_ the government. Which makes sense - what are they supposed to use? WhatsApp? Twitter DM? Skype for Governments?
But even if you’re not in the target demographic, you might benefit: The government will run a large installation and hopefully some code will find its way back to the OS version.
But even if you’re not in the target demographic, you might benefit: The government will run a large installation and hopefully some code will find its way back to the OS version.
> Skype for Governments?
I want to type this into a search bar to see if it's a thing... but simultaneuosly I'm terrified of the prospect of discovering that it is.
I want to type this into a search bar to see if it's a thing... but simultaneuosly I'm terrified of the prospect of discovering that it is.
I don’t think it exists as a product, but I’d totally not be surprised if Skype for Business is used in government branches.
> I’d totally not be surprised if Skype for Business is used in government branches.
It is, or at least Centrelink, Medicare, NDIS and Veteran's Affairs use it in Australia. Wouldn't be surprised if it was also used outside of DHHS.
It is, or at least Centrelink, Medicare, NDIS and Veteran's Affairs use it in Australia. Wouldn't be surprised if it was also used outside of DHHS.
Never heard of Matrix... looked it up; gross... python2.7
Also take a look at the network "protocol": JSON over HTTP longpolling, requiring usually a separate socket for each batch of messages sent or received (unless HTTP/2 is available, then it’s a bit less expensive, still has a massive overhead).
Matrix has so much potential – someday, when it’s built on technologically more ideal foundations.
Python2.7 you’ll barely notice, but the network overhead of the Matrix protocol becomes heavily noticeable by the end user (especially if your cell phone’s data plan runs out, and you’re stuck on 64kbps until the end of the month, then Matrix in larger rooms just becomes impossible)
Matrix has so much potential – someday, when it’s built on technologically more ideal foundations.
Python2.7 you’ll barely notice, but the network overhead of the Matrix protocol becomes heavily noticeable by the end user (especially if your cell phone’s data plan runs out, and you’re stuck on 64kbps until the end of the month, then Matrix in larger rooms just becomes impossible)
The spec only states the use of JSON over HTTP as a baseline so anyone is welcome to implement more efficient transports like CBOR/COAP or MQTT or whatever :)
But yes the goal of the reference implementations was to showcase the simplest transport: one PUT to send and one GET to retrieve it.
Meanwhile we’re working on improving the performance of the servers with some rather nice breakthroughs on the horizon.
As I said, the potential is there, the current implementations just aren’t there yet. In a few years it might be entirely different.
And I’m not sure PUT and GET are the simplest solution, I’d think a simple socket over which messages are transmitted in both directions would be simpler than implementing an entire HTTP stack.
And I’m not sure PUT and GET are the simplest solution, I’d think a simple socket over which messages are transmitted in both directions would be simpler than implementing an entire HTTP stack.
Being able to implement a client that runs in a browser (and can thus only deal in terms of HTTP) is very valuable, and one reason to claim that the simplest solution is HTTP PUT and GET.
And that is precisely why it is an idiotic design decision. HTTP is extremely complex (well, and Matrix doesn't actually use HTTP, they just claim they do, but as usual noone reads the specs, everyone just builds crap based on what they think the spec says, because the spec is too complicated), and as such is an absolute dead end if your goal supposedly is to build something secure.
I think HTTP Keep Alive mechanism should help with sockets and it does not require HTTP/2.
Work is underway to rewrite Synapse (the Python server implementation) in Go: https://github.com/matrix-org/dendrite
there was also work being done to port to python3
https://github.com/matrix-org/synapse/pull/2539
but it looks like this hasn't been worked on since october last year.
but it looks like this hasn't been worked on since october last year.
Actually, a separate thread of porting work has been happening over the last month and it's looking very promising indeed: https://github.com/matrix-org/synapse/pulls?utf8=%E2%9C%93&q... etc.
Why is the world so desperate to pretend that irc doesn't exist? Why can't we just get a new irc spec with e2e in mind?
Matrix is an extremely immature project and the French gov is making an irresponsible move here to prop it up as a solution in any capacity.
It's beta software! Where are the audits? Where are the formal verifications? Not that irc has those, I don't mean to juxtapose one not-good-enough product with another, but this is reaching a point of insanity.
If you want security, use signal. If you don't trust signal, learn to trust scores of world renowned cryptographers, and use it anyways. And if you're still bored, renovate irc.
Gosh this is just crazy. It's like saying the tesla 3 will be the authorized taxi vehicle on Mars. There's so much work yet to be done, it's a million years too early to start regulating and organizing something that's not even half built.
Matrix is an extremely immature project and the French gov is making an irresponsible move here to prop it up as a solution in any capacity.
It's beta software! Where are the audits? Where are the formal verifications? Not that irc has those, I don't mean to juxtapose one not-good-enough product with another, but this is reaching a point of insanity.
If you want security, use signal. If you don't trust signal, learn to trust scores of world renowned cryptographers, and use it anyways. And if you're still bored, renovate irc.
Gosh this is just crazy. It's like saying the tesla 3 will be the authorized taxi vehicle on Mars. There's so much work yet to be done, it's a million years too early to start regulating and organizing something that's not even half built.
I think I can relate to your point because I used to write comments like these. You're right. The world is desperate to pretend IRC doesn't exist. We should get a new IRC spec with e2e in mind.
What surprised me is that Matrix is practically a modern IRC spec with e2e in mind. What's better is that the Matrix devs acknowledge this heritage. They don't pretend IRC doesn't exist. They're very up-front about loving IRC, and they have successfully brought over nearly every good feature of IRC into Matrix.
At first I thought it was too good to be true, but it keeps on being good. I have waited for years for a decent IRC alternative which I can convince even my less technical friends and family to use, and Matrix is it. I truly feel like I'm on IRC with my family. It's insanely good. I even use the same client for both.
Matrix can replace your Signal. It can replace your Telegram. It can replace your WhatsApp. It can replace your Facebook messenger. It can even replace IRC. It is that complete.
What surprised me is that Matrix is practically a modern IRC spec with e2e in mind. What's better is that the Matrix devs acknowledge this heritage. They don't pretend IRC doesn't exist. They're very up-front about loving IRC, and they have successfully brought over nearly every good feature of IRC into Matrix.
At first I thought it was too good to be true, but it keeps on being good. I have waited for years for a decent IRC alternative which I can convince even my less technical friends and family to use, and Matrix is it. I truly feel like I'm on IRC with my family. It's insanely good. I even use the same client for both.
Matrix can replace your Signal. It can replace your Telegram. It can replace your WhatsApp. It can replace your Facebook messenger. It can even replace IRC. It is that complete.
It uses HTTP requests for transit! I know you don't actually know what youre talking about, so I'll explain:
There is much more overhead to opening a connection and maintaining a connect and sending and receiving, to the degree that people with bad connections are excluded entirely from being able to reliably use it. This is not true with irc. People in third world countries can use irc. If you can ping, you can chat.
We don't WANT a chat for less technical people. We want e2e safety. We should never prioritize """normal users""" over security in a security oriented proposal! That's insane!
But hey, I'm sure youre just a teen with a laptop, so I won't hold it against you that you'd make such an irresponsible decision.
There is much more overhead to opening a connection and maintaining a connect and sending and receiving, to the degree that people with bad connections are excluded entirely from being able to reliably use it. This is not true with irc. People in third world countries can use irc. If you can ping, you can chat.
We don't WANT a chat for less technical people. We want e2e safety. We should never prioritize """normal users""" over security in a security oriented proposal! That's insane!
But hey, I'm sure youre just a teen with a laptop, so I won't hold it against you that you'd make such an irresponsible decision.
Insert counter-patronizing preamble here.
------8<---------------
While the overhead of setting up a fresh TCP connection for every exchange is non-trivial, I'm not sure "reliable on a bad connection" is a characteristic I would attribute to IRC. The protocol is notoriously unreliable to the point where established practise is to run a client on a server somewhere and then connect to that from your bad connection computers. People who don't lose IRC messages sent while their connection crapped out, while Matrix ensures their client is updated to reflect the current state of the servers as soon as they go online again.
I believe also that modern HTTP options let you reuse the same connection for multiple requests, obviating much of the overhead. Not to mention that you are free to extend the Matrix server with alternative connection methods.
We do want a chat for less technical people. In order for humanity to not screw over itself royally, we need to target the 99%, not the 1%. Things can be good and still target non-technical people, as long as they are open and federated.
Of course, convenience does not trump security, but I don't see how that is the case here either.
------8<---------------
While the overhead of setting up a fresh TCP connection for every exchange is non-trivial, I'm not sure "reliable on a bad connection" is a characteristic I would attribute to IRC. The protocol is notoriously unreliable to the point where established practise is to run a client on a server somewhere and then connect to that from your bad connection computers. People who don't lose IRC messages sent while their connection crapped out, while Matrix ensures their client is updated to reflect the current state of the servers as soon as they go online again.
I believe also that modern HTTP options let you reuse the same connection for multiple requests, obviating much of the overhead. Not to mention that you are free to extend the Matrix server with alternative connection methods.
We do want a chat for less technical people. In order for humanity to not screw over itself royally, we need to target the 99%, not the 1%. Things can be good and still target non-technical people, as long as they are open and federated.
Of course, convenience does not trump security, but I don't see how that is the case here either.
audit e.g.: https://www.nccgroup.trust/us/our-research/matrix-olm-crypto...
formal proofs e.g.: https://matrix.org/_matrix/media/v1/download/jki.re/hSmkLkFG...
Agreed that Matrix is still beta, but hopefully we are heading in the right direction and the end is in sight.
formal proofs e.g.: https://matrix.org/_matrix/media/v1/download/jki.re/hSmkLkFG...
Agreed that Matrix is still beta, but hopefully we are heading in the right direction and the end is in sight.
I think the problem with Signal is that it requires a phone number to sign up: which some people may not feel comfortable doing.
On the other hand irc is nice, but it doesn't exactly have the media sharing tools that have become standard in chat clients (Discord, Slack, etc.).
Although it is a little early for France to choose Matrix, at least e2e is becoming more standard, and countries are endorsing it.
Do the French make their own hardware? An encryption app is useless if you don't 100% trust the hardware. Tainted hardware could figure out, log and send your keystrokes from screen taps/swipes all from silicon.
Its a fallacy of composition to say that better security useless unless its perfect security.
This is better that it was before. More security is better. Perfect security does not and cannot realistically exist for a complex system.
I do think have a reproducible binary would be a huge win. Even if you can't verify the integrity of a single build you could verify that build by consensus.
This is better that it was before. More security is better. Perfect security does not and cannot realistically exist for a complex system.
I do think have a reproducible binary would be a huge win. Even if you can't verify the integrity of a single build you could verify that build by consensus.
Reproducible builds are what nix is good at. Synapse is already well packaged, but Riot has the problem of using electron, which was never fully packaged on `nixpkgs`. Maybe someone with the right skills will be willing to do that. Bonus: vscode and others get better support on nix.
https://nixos.org/nix/
https://nixos.org/nix/
TThis is a rather extreme threat model given how expensive it is to carry out and very obvious once discovered.
But France does have some domestic defence capability here - Thales make hardware security modules and similar products, and STMicroelectronics has chip design expertise while being partly state-owned.
But France does have some domestic defence capability here - Thales make hardware security modules and similar products, and STMicroelectronics has chip design expertise while being partly state-owned.
You're totally right. But it's a step forward anyway. Perhaps that hardware will come after.
You aren't wrong, but most people's threat model doesn't include defense against state-level actors — because for most people there isn't a defense against state-level actors.
Apparently, though, people whose threat model isn't dialed up to 11 don't deserve security or privacy?
Apparently, though, people whose threat model isn't dialed up to 11 don't deserve security or privacy?
I really like the idea of Matrix, but it seems a little immature for a government to use as a standardized messaging protocol.
[0] https://matrix.org/docs/spec/
[1] https://matrix.org/docs/spec/server_server/unstable.html#roo...