Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Year in Matrix

matrix.org

Post reply on HN
Print view View original

41–50 of 109 posts

Re: This Year in Matrix

#41

Post by jeroenhd »

I've looked into putting Cactus Comments [1] on my website, but I kind of had to can that plan when I found out that it requires the slow and resource hungry Synapse homeserver implementation at this point in time. I was hoping to use Conduit or Dendrite, but those are simply not ready yet.

In my opinion, the biggest problem with the current Matrix platform, especially if you self-host, is the server implementation. It's not buggy, but it's just awfully slow. The "dpt of ping" [2] section at the bottom of the weekly Matrix updates show that five seconds of latency between servers (measured by basic ping bots) is far from uncommon. The latency is still significant in the non-synapse version of the graph, but it's much better already.

With the speed new MSCs are accepted every month I don't think any alternative server stands a chance at catching up to Synapse any time soon, and I don't know how I feel about that. Yes, Matrix is an open platform with an open source spec, but it's effectively impossible to develop an alternative backend implementation with the way development is currently done, unless you've got a lot of developers and money to throw at the platform.

I'll probably look into Conduit again in a few months, hopefully the project will keep up it's impressive pace so that it's useful for my purposes.

[1]: https://cactus.chat/

[2]: https://matrix.org/blog/2021/12/17/this-week-in-matrix-2021-...

Re: This Year in Matrix

#42

Post by kuon »

3np wrote: post #31
kuon wrote: post #10

I tried to adopt matrix for our small business and here is summary of my experience. - Synapse is very resource hungry even for a small server - Synapse creates a gazillion of TCP connection and keep them open, it was a real problem for my ISP router (SOHO router for 1gbit/s) and it took a very long time to debug, be sure to limit the number of TCP connection on the server - Synapse is hard to get a good idea of the…

> federation issues > gazillion TCP connections We’ve been running a Synapse server with quite a bit of federated rooms, even larger ones like you mention. Never noticed a single issue like this that I recall. I wonder if the reason is that we’re doing whitelisting, instead of federation with everyone by default. The whitelisting is quite liberal; I’ll add a server as soon as I’m in a conversation thread with someone…

I didn't whitelist anything, maybe that was a source for issue.

> Disagree. Sure, UX can be improved, but compromising here defeats the purpose of why we’re doing this in the first place.

The thing is, as I ran my own server in my office, SSL (with no E2E) is already a good privacy. And even with that setup, the server users got "harassed" by the UI asking them to sync devices keys.

For many users, a single prompt about security is enough to discourage them.

Re: This Year in Matrix

#43

Post by kuon »

teitoklien wrote: post #33
kuon wrote: post #10

I tried to adopt matrix for our small business and here is summary of my experience. - Synapse is very resource hungry even for a small server - Synapse creates a gazillion of TCP connection and keep them open, it was a real problem for my ISP router (SOHO router for 1gbit/s) and it took a very long time to debug, be sure to limit the number of TCP connection on the server - Synapse is hard to get a good idea of the…

Synapse is bloated and mostly good for very large organisations. Use conduit.rs or dendrite. I use conduit and it takes a couple of MB ram even while I’m in large rooms

Last time I checked critical features were not supported, like read receipts.

Re: This Year in Matrix

#44

Post by karmanyaahm »

jeroenhd wrote: post #41

I've looked into putting Cactus Comments [1] on my website, but I kind of had to can that plan when I found out that it requires the slow and resource hungry Synapse homeserver implementation at this point in time. I was hoping to use Conduit or Dendrite, but those are simply not ready yet. In my opinion, the biggest problem with the current Matrix platform, especially if you self-host, is the server implementation.…

I'm running Synapse and Cactus chat on a 1gb memory, 1 vCPU Linode and it's just fine.

Given, I have a small blog (ie low load on cactus), but I'm in many (15+) medium sized (100-1000 members) federated chats and it's just fine on a day to day basis.

There are some limitations tho:

- I can't join large rooms (2000+ members and whatever number of servers that entails on average)

- Initial sync (first time log in on new client) is crazy slow - syncv3 will hopefully fix this

My definition of not being resource hungry is being able to run on a 1gb, 1 vCPU VM - however you and me might have a difference in that opinion

Re: This Year in Matrix

#45

Post by jeroenhd »

karmanyaahm wrote: post #44
jeroenhd wrote: post #41

I've looked into putting Cactus Comments [1] on my website, but I kind of had to can that plan when I found out that it requires the slow and resource hungry Synapse homeserver implementation at this point in time. I was hoping to use Conduit or Dendrite, but those are simply not ready yet. In my opinion, the biggest problem with the current Matrix platform, especially if you self-host, is the server implementation.…

I'm running Synapse and Cactus chat on a 1gb memory, 1 vCPU Linode and it's just fine. Given, I have a small blog (ie low load on cactus), but I'm in many (15+) medium sized (100-1000 members) federated chats and it's just fine on a day to day basis. There are some limitations tho: - I can't join large rooms (2000+ members and whatever number of servers that entails on average) - Initial sync (first time log in on ne…

I think the initial sync issue is one of the worst problems, because someone joining in to leave a quick comment will be waiting for the system to synchronize. You can run the system on 1GiB/1 vCPU, but that comes with a performance penalty.

My instance of Synapse definitely can't join any matrix.org chatrooms, no matter how hard I try. Even rooms with a few hundred participants are awfully slow and leave scrollback state a broken mess. When I tried to join the main Matrix channel, both of the CPU cores I had dedicated to Synapse were pinned for at least half an hour, even after I tried to cancel joining the room!

I hope sync v3 lives up to the hype, but I'm wary. Synapse's Pythonic base seems ill-fitted for an instant messenger backend in my opinion, and no amount of protocol trickery can work around that.

It's not that I think the 1GiB is necessarily that excessive, but Dendrite and Conduit are blowing Synapse out of the park in terms of performance, to the point that I'd almost rather see the Matrix folks dedicate their development efforts more on bringing Dendrite up to speed than to expanding functionality.

Re: This Year in Matrix

#46

Post by Arathorn »

dane-pgp wrote: post #39
Arathorn wrote: post #37

Earlier quoted context omitted.

The excitement purely comes from the fact it makes it way easier for casual users to try out Matrix (even at the expense of then being beholden to the SSO providers), and it forced us to dogfood and land first class SSO support :)

If someone uses a third party SSO provider, can they create recovery codes to mitigate the risk of having their account closed by that provider? That would be a nice feature to prompt such users to make use of, once they've tried Matrix out for a while and have built up some chat history and connections they wouldn't want to lose.

Not yet, but it’s on the horizon (it’s the account portability / multihomed accounts stuff in the OP)

Re: This Year in Matrix

#47

Post by Arathorn »

jeroenhd wrote: post #45
karmanyaahm wrote: post #44

Earlier quoted context omitted.

I'm running Synapse and Cactus chat on a 1gb memory, 1 vCPU Linode and it's just fine. Given, I have a small blog (ie low load on cactus), but I'm in many (15+) medium sized (100-1000 members) federated chats and it's just fine on a day to day basis. There are some limitations tho: - I can't join large rooms (2000+ members and whatever number of servers that entails on average) - Initial sync (first time log in on ne…

I think the initial sync issue is one of the worst problems, because someone joining in to leave a quick comment will be waiting for the system to synchronize. You can run the system on 1GiB/1 vCPU, but that comes with a performance penalty. My instance of Synapse definitely can't join any matrix.org chatrooms, no matter how hard I try. Even rooms with a few hundred participants are awfully slow and leave scrollback…

Well, you can try sync v3 today via sync-v3 proxy (which is written in Go) and Hydrogen, as per the video linked in the post. It solves the initial sync problem completely; it’s not hype; it’s real.

The main thing that bogs down Synapse is if users join massive federated rooms and you end up replicating huge amounts of traffic onto your server. So we’re working on that too via Fast Joins and better-than-full-mesh federation for P2P.

Re: This Year in Matrix

#48

Post by kevincox »

Arathorn wrote: post #30
kevincox wrote: post #23

Earlier quoted context omitted.

> And in general I trust and know that decisions with the spec are being made carefully. This is one place where I strongly disagree. Almost all features have "We will add encryption later" which is not a way to build a secure messenger. Stickers, polls, profiles, spaces, relations, reactions... they all start with and unencrypted version with the promise that "encryption will come in a later MSC". They should really…

This is a really interesting point. We deliberately built Element to help prove the spec and define its direction (including ensuring it has decent privacy properties), to avoid all the failure modes where folks build a protocol without a real app or product in mind and end up with something which tried to be all things to all people and useful to none. While I’d have loved us to have infite manpower getting all the…

I think it is helpful to have Element to test out the spec. I think the problem is that the "bar" for accepting features is too low for my taste.

> While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec.

I get the decision. But it leaves a sour taste in my mouth that Matrix advertises itself as "secure" but almost any user is leaking sensitive information without knowing. I suspect that 95% of users would be surprised if you told them about the number of things that leak in E2EE rooms. Probably the better approach would have been to skip pushing E2EE as the default, and disable all insecure features in Element for E2EE rooms (or have an explicit opt-in). The marketing team would hate this approach but it least it is honest and safe.

Re: This Year in Matrix

#49

Post by Arathorn »

kevincox wrote: post #48
Arathorn wrote: post #30

Earlier quoted context omitted.

This is a really interesting point. We deliberately built Element to help prove the spec and define its direction (including ensuring it has decent privacy properties), to avoid all the failure modes where folks build a protocol without a real app or product in mind and end up with something which tried to be all things to all people and useful to none. While I’d have loved us to have infite manpower getting all the…

I think it is helpful to have Element to test out the spec. I think the problem is that the "bar" for accepting features is too low for my taste. > While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec. I get the decision. But it leaves a sour taste in my mouth that Matrix advertises itself…

There isn’t a marketing team for Matrix, unless you count me & the dev advocacy team. I actually have another (big) blog post called Metadata And Matrix which attempts to enumerate the privacy properties we have today to try to educate everyone, and how we’re improving it in future - will post it shortly. Agreed it could be better, but if you’re on your own server you are in a pretty good place.

Re: This Year in Matrix

#50

Post by blitzar »

davidhyde wrote: post #32

> "Social Login via multiple SSO providers (MSC2858) - almost 50% of new registrations on the Matrix.org homeserver now use social login!" Interestingly the split of SSO usage is roughly 70% Google, 12% GitHub, 11% Apple, 6% Facebook and 1% GitLab. Congrats to the matrix team, really great work. However, I'm a little confused by the excitement around "social login". Why is it such a great thing? Aren't you just givin…

Welcome to federated decentralised service. Please log in with your facebook account.
Post reply on HN