Live data from Hacker News

Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

matrix.org

171–180 of 204 posts

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#171
post #132

Earlier quoted context omitted.

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#172
post #21

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?

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#173
post #137

Earlier quoted context omitted.

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 .

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#174

Earlier quoted context omitted.

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#175
post #171

Earlier quoted context omitted.

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 soundn…

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#176

Earlier quoted context omitted.

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…

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#177
post #171

Earlier quoted context omitted.

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 soundn…

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?

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#178

Earlier quoted context omitted.

(oh, and we rewrote (almost) the whole thing in Go, too)

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?

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! :)

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#179

Earlier quoted context omitted.

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.

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.

Re: Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App

#180

Earlier quoted context omitted.

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?

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 -…

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.
Post reply on HN