Hacker News Reader

Comment by SamWhited | Hacker News Reader

I'm not really a fan of IRC (a federated network where some OSS projects were on their own servers or different ones would have limited the blast radius of a hostile takeover of one server like this), but Matrix is bloated and slow and the protocol makes no sense for chat (though it may have other applications); it's not a great fit for a large network with lots of people who may or may not have modern hardware. Not to mention that the servers would take a lot more resources to run on Matrix (assuming it eventually gets roughly the same size as Freenode was).

View on HN

Wow, that's a lot of negativity. You forgot to disclose your XMPP/XSF affiliation, btw.

Matrix as a protocol is neither bloated or slow, and ~32.1M folks have managed to use it successfully, directly or indirectly, as a global chat network. Presumably that counts as a 'large network'; it's certainly bigger than Freenode.

Synapse as an implementation has historically been bloated, but it's been steadily improving (and in fact last week's Matrix Live has a fascinating analysis of how the remaining memory usage is being fixed: https://youtu.be/694VuhmVmfo). Meanwhile implementations like Dendrite & Conduit are positively skinny.

Overall, I would pick XMPP over Matrix at this point. it is rather bloated and the clients are a little bit obtuse for newbies. I do wonder what the DAU for Matrix is at this point. as I suspect that 32 Million number might be a little overstated.

frankly, as long as folks are communicating via open standards rather than being locked into some vendor silo then they should use whatever protocol works best for them - XMPP & Matrix bridge together fairly well these days.

Based on the phone-home stats in Synapse there's around 300K DAU currently on the network, but this is a major underestimate given other stats which suggest only about 30% of public servers enable phone-home.

> XMPP & Matrix bridge together fairly well these days

Does Matrix support OMEMO for e2e encryption?

Yup, OMEMO and Olm are bit compatible. In fact XEP-0384 went through a phase of recommending Olm as the implementation to use (grep https://xmpp.org/extensions/xep-0384.html for Olm).

(Although the bifrost bridge doesn't currently implement E2EE - and it would have to reencrypt anyway to turn the Matrix event payloads into XMPP stanzas and vice versa)

> XMPP & Matrix bridge together fairly well these days.

I want to test this claim. After an hour of google searching I'm none the wiser:

1. Can I bridge private messages, or just MUCs? I use XMPP only to keep in contact with friends that use XMPP. I would love to integrate them into a single client, but afaict it does not appear possible.

2. Do I have to run my own XMPP bridge, or is there some automatic integration service I'm completely missing? For comparison, the experience of bridging a matrix room to IRC was as easy as clicking "add new bridge" in the Element UI.

> You forgot to disclose your […] affiliation, btw.

Um.. :D

Psychological projection https://en.wikipedia.org/wiki/Psychological_projection

Speaking of disclosure, aren't you the CEO of Matrix?

I'm the project lead of Matrix (as it says in my HN bio). (I'm also ceo/cto of Element, but that's less relevant).

Less relevant? You are the CEO of a company which sells Element Home, a product based on Matrix... and you accuse others of not disclosing properly?

An entry in the HN bio should be considered sufficient disclosure.

I disagree, I don't click the bio link for every comment I read. I'd have never known they were the project lead if another commenter didn't call them out on it.

You may want to make clicking through a habit when commercial & project interests may be involved.

HN's minimalist post format isn't amenable to adding such disclosures all the time - but making them available in bios is practical.

You may also want to assume deep undisclosed conflicts may exist whenever there's no bio info at all – as with your user page.

Oh, for all the bigco employees to have their affiliations declared for when they're flacking their company interests under a pseudonym! Oh, for net upvotes/downvotes on highly critical/opinated posts to be cross-tabulated by employer conflicts! Unlikely, but things to think about.

They don't need to add the disclosures all the time - they've got a lot of posts that aren't about Matrix.

But bringing up that you're the project lead of the project your discussing seems like an obvious step.

Clicking through to everyone's profile is only occasionally useful and an impractical suggestion.

When a commenter takes strong stands on the relative merits of projects or commercial products, and there's a whiff of involved partisanship, a clickthrough is pretty easy & wise.

And, it often has the added benefit of more useful credibility context than just revealing blatant conflicts.

It's impractical to expect a commenter to consider, for every comment, "how much involvement in these particular topics should I declare?". That's especially the case on topics for which the commenter often comments, or multiple comments in related threads in a long discussion - where such a standard would be onerous for both the author, and the readers.

Add major affiliations to the bio, and I'd say you're covered for comments related to those affiliations, as it's then easy to check for anyone observing any partisanship, without encumbering all writing/reading with redundant disclosure-noise.

Sorry, but I agree with @gojomo. Making it public in your bio that you are afilliated with a project, is very sufficient disclosure in my opinion.

No one expects you to read every bio of every comment you read, but conversely we shouldn’t expect him to preface every single one of his comments with “Hey guys, I’m the project lead of Matrix.”

Arathorn is very active in comments, and it’s well known to frequent readers he is the project lead of Matrix.

Considered sufficient by who? I sure don't, and this is not a site rule either.

A "…by reasonable readers" can be assumed.

If you want scrupulous disclosure of relevant affiliations inline in every single comment where they could apply, I think you're in the wrong place.

As you note, it's not a site guideline. As I've noted in a sibling thread, it wouldn't fit the minimalist HN presentation, and would place an onerous burden on both writers & readers.

It'd also especially encumber people with deep personal knoweldge and interest in some topics, if every related post required boilerplate "I'm employed by X"/etc inserts.

But putting it in the bio for the curious/suspicious is a very honorable thing to do!

Again, I don't think you speak for all "reasonable readers". I have seen plenty of disclosures on this site, and I think that should be the default.

He did disclose it, he just said he thought it was less relevant (maybe since it doesn't directly answer the question of the post he's replying to..)

The guy gives up additional disclosure information and you see that as an opportunity to make smartass comments

He didn't disclose anything, ameminator did, and he then confirmed.

You'll note that I didn't show up and advocate for XMPP. Also I have no real affiliation with the XSF except being a volunteer and maintaining a library and having written a few specs (in the past I have had more strong affiliations, but never any financial considerations or anything that I'd need to disclose, I have just volunteered more in the past than I do now)

> You'll note that I didn't show up and advocate for XMPP.

Can't XMPP be considered a competitor? If so, that's like saying an oil company exec has no reason to disclose their affiliation when advocating against renewable energy sources.

It's not about whether you are advocating for or against something specifically, it's about whether you have a vested interest in the outcome which could conceivably affect your veracity, or even just your outlook and how you perceive the facts (it doesn't need to be nefarious, nobody can be completely impartial).

To clarify my intent, I'm not sure I think you should have noted your affiliations in this case, but I don't think the reason stated for not doing so is really evidence either way.

I was arguing that it makes no sense to use Matrix for this and they should continue using IRC, but yes, I have written some XMPP related specs in the past. But fair enough, consider this my belated disclosure.

I've tried Matrix multiple times, and each time have been turned off by the broken and/or slow clients, both on mobile and desktop. No thanks.

"Matrix as a protocol is neither bloated or slow"

The protocol may not be, but in practice, the servers and clients that nearly everyone uses sure as hell are.

I run a synapse server for half a dozen people on a reasonably beefy box and it sure feels that way when I'm using it on a daily basis.

Really? I run Synapse for a half a dozen people, on an EC2 Ubuntu server with 2GB memory and it works great for me!

Yes. 8GB and 4 Xeon cores here.

Are your users in loads of massive federated rooms?

No. they pretty much only use it to talk to each other. Until their clients start randomly complaining about encryption keys and they no longer can.

This sounds really weird. What was the perf problem you were seeing? (aside from whatever has gone wrong with encryption failures) For context, message sending latency should be measured in tens of milliseconds, at worst, unless the server is completely overloaded with federation traffic.

I haven't investigated too deeply. It may just be the clients rather than the server, but it's been there from the beginning. Just a slow laggy experience on all three of iOS, Debian and OSX with Element. Spinning progress bars, blank appearing rooms whilst stuff waits to load. Messages sometimes appearing in different orders for different people in the same room. Messages just not appearing for other people occasional. Random undecipherable complaints about encryption keys leading to some people not being able to read other peoples messages in the same room.

I regret getting people onto Matrix now. I'm keeping it running with the hope that things improve and because I don't want to get people to move to another system which may also have problems.

Should have just stuck with XMPP and my Prosody server, and IRC.

If you can hook synapse up to a prometheus & grafana I would be super interested to see what it’s doing. Private servers should be lightning fast (assuming you use postgres and are on sensible hardware). It’s only when you have public servers which join massive public rooms when things can start to chug.

I am using postgres and on sensible hardware. I've never setup prometheus or grafana though and I'm unlikely to be able to do so any time soon.

The implementations might be bloated (js heavy, etc), and the non bloated implementations written in C++ or Rust or so don't have the full feature set yet, but is it really the protocol to blame?

In which way does the protocol make no sense for chat? IRC is extremely complicated as well and a giant pile of hacks.

For clients maybe not, but for servers the protocol itself is to blame, yes. A giant distributed graph database where everything has to be synced constantly means you use a ton of memory. IRC is definitely complicated, and arguably a pile of hacks, but an event based system (more or less) makes a lot more sense for chat where you want realtime communication (more or less), not to wait while you sync nodes in the graph to every place that wants them.

This makes no sense. Propagating a bunch of messages doesn't suddenly use a ton of memory just because you're organizing them as a graph rather than a linear pubsub-style stream.

Sorry, it was a bad explanation. The point is that you have to keep a lot of past state in memory for future messages to make sense and sync properly, unlike an event based system where you (more or less) only need to perform some action when you get an event then forget about it. This is an IRC thread though, sorry I got sucked in but let's not let the Matrix CEO derail it and try to score users. The whole point is is that it didn't make sense for them to switch to matrix because it uses more resources than most IRC servers and because they are trying to be a drop in replacement, not make users sign up for new things.

You don't have to keep that much state in memory at all, actually. I'm not sure why you think that you do.

Most of the state resolution (eg. the auth chain) involves calculations of which you can cache the result without needing to care about the inputs beyond that - at least, unless you need to recalculate them once later if delayed events come in.

Ultimately, the performance problems that Synapse has are problems with Synapse's implementation choices (especially around the database schema), not with the protocol nor with the state resolution algorithm.

Presence may be a protocol level issue. My server struggled pretty badly until I disabled it and I see that's generally the advice: https://github.com/matrix-org/synapse/issues/3971

That doesn't seem like a fundamental issue though.

It’s a synapse implementation problem, not a protocol issue. And it’s being fixed currently.

Reply on news.ycombinator.com