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

71–80 of 109 posts

Re: This Year in Matrix

#71

Post by foxfluff »

Jnr wrote: post #69
Arathorn wrote: post #12

Earlier quoted context omitted.

When was this? I suspect most of the problems here are due to users joining lots of big federated rooms, which will use loads of resources irrespective of how many local users you have. This is also what Fast Joins are trying to improve (at least for join speed) from the original post. Likewise the matrix-hookshot webhook bridge.

Tried Matrix (and Synapse) the 3rd time a couple of months ago and gave up after a few days. Joining any larger federated room took days or did not complete at all. And then the messages were also delayed for quite a while. That must be the stupidest design I have seen. If it was not so messed up, Matrix probably would have become huge by now. I agree with others in comments, devs should have probably improved the fe…

I kind of disagree about the language. Not because I wouldn't want an implementation in a fast language, but because I think a well designed chat system must be performant even if your language is an order of magnitude (or two) slower than it has to be. If you need to start throwing brute force at it, something's up with the design. Get the design right first and demonstrate it is right by showing that even a slow system has no trouble with it.

Re: This Year in Matrix

#72

Post by xvilka »

mst wrote: post #70
xvilka wrote: post #66

Earlier quoted context omitted.

Official server should have never been in Python anyway. Not a proper language for the network server. They should have adopted Go or Rust servers as the official ones, and pour resources there instead.

Synapse was about proving the concept.

Well, they proved it, time for it to be dropped, and focus on the production-level implementation. But it's still[1] the recommended one.

[1] https://matrix.org/docs/guides/introduction#how-can-i-get-my...

Re: This Year in Matrix

#73

Post by up6w6 »

Very nice blog! I was looking at Signal with their closed-doors development these days, and you have no idea of how much a post from time to time detailing the progress makes means for someone willing to contribute.

Some of the most exciting features for me are:

- Dendrite: we really need some efficient replacement for Synapse

- Sync V3 and Fast Joins: it will erase the feeling of slowness when I open the web client

- MLS: It will help to scale E2EE groups [1] (remember the 256 limit in WhatsApp groups ?)

- P2P: We received this year a first glance of what a network of Bluetooth Low-Energy devices can do with the Apple Find My network. A true p2p instant messaging system is not just a dream anymore.

- Metaverse, file storage: I have no idea if they will accomplish any of them, but having a new non-profit working in the field is always welcome.

[1] https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-Messagi...

Re: This Year in Matrix

#74

Post by snvzz »

Arathorn wrote: post #58
twicetwice wrote: post #55

Earlier quoted context omitted.

I want to voice strong agreement with kevincox. I use an encrypted Matrix room daily and had no idea that reactions, relations (does that mean that edits are in cleartext??), etc are completely unencrypted. I've read a little bit of the spec (though clearly not very much), I've written a bot, I've patched the Element desktop client, I've even been working with a JSON export of my message history and didn't notice—per…

Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions? One could encrypt the emoji itself, but it doesn't seem like a massively sensitive datapoint in its own right. (That said, we will encrypt them eventually, but it's just not very high priority given the fact it doesn't practically feel very high impact, relative to all…

It is. The expectation in an E2EE room is that everything that happens there is E2EE.

Breaking this expectation is a massive red flag, particularly because Matrix is often chosen with this expectation at the core of the decision.

Re: This Year in Matrix

#75

Post by mst »

xvilka wrote: post #72
mst wrote: post #70

Earlier quoted context omitted.

Synapse was about proving the concept.

Well, they proved it, time for it to be dropped, and focus on the production-level implementation. But it's still[1] the recommended one. [1] https://matrix.org/docs/guides/introduction#how-can-i-get-my...

I sympathise with your aggravation but they're balancing doing that while not trying to migrate the existing user base too early and keeping supporting people with production workloads.

Fundamentally they've 'lucked' into a 'nice problem to have' type situation here, and I get how annoying it is - I was freenode staff during a period where the ircmatrix bridging was unexpectedly popular enough to be a 'nice problem to have' for everybody involved and the author of the blog post we're discussing probably remembers some sharp words on my part during the process - but frankly on balance I'm mostly impressed.

Re: This Year in Matrix

#76

Post by jimmygrapes »

Arathorn wrote: post #47
jeroenhd wrote: post #45

Earlier quoted context omitted.

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

The following comment is not well considered.

I once installed Litecoin Core (on Windows 10) on my desktop PC. I had Comcast (branded as Xfinity) broadband, whatever speeds my region and apartment supported. I had a 1TB monthly limit before throttling. I lived in the east SF bay area. I downloaded Litecoin Core software at the beginning of the month. I got dial-up speeds for the rest of the month. I got a 5x average bill that I had to negotiate down. Nobody on my server even cared about the federated rooms, it was just me trying to give them more flexibility.

Allowing federation with Matrix has the same issue, and I know it's being addressed, but I want to hammer this home. Self hosting means normal, poor people, too, not just EU government entities and Upcoming Big Tech partners. I know you know this, but every advocate needs reminders here and there.

Re: This Year in Matrix

#77

Post by jimmygrapes »

2pEXgD0fZ5cF wrote: post #6

I have been using matrix for quite a while now, and managed to get the people I write the most with on it too! Back then I rented matrix hosting with modular.im (now called ems) once I noticed that I did use Riot/Element on a daily basis, and the latency of matrix.org servers was too big for my taste, combined with the lack of online status display. Now that dendrite is starting to finally mature, I will probably swi…

A migration guide would be much appreciated.

I'd also like them to name homeserver.yaml in the Synapse Debian package to something akin to homeserver.example.yaml so that updates don't make me have to diff changes to figure out what I need to add (since accepting the package version overwriting my homeserver url is unacceptable). But that's neither here nor there.

Re: This Year in Matrix

#78

Post by jancsika »

Arathorn wrote: post #58
twicetwice wrote: post #55

Earlier quoted context omitted.

I want to voice strong agreement with kevincox. I use an encrypted Matrix room daily and had no idea that reactions, relations (does that mean that edits are in cleartext??), etc are completely unencrypted. I've read a little bit of the spec (though clearly not very much), I've written a bot, I've patched the Element desktop client, I've even been working with a JSON export of my message history and didn't notice—per…

Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions? One could encrypt the emoji itself, but it doesn't seem like a massively sensitive datapoint in its own right. (That said, we will encrypt them eventually, but it's just not very high priority given the fact it doesn't practically feel very high impact, relative to all…

> Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions?

Why couldn't the client simply count the number of reactions?

I can't imagine it'd be a performance issue. After all, if you didn't have reactions you'd have a bunch of in-band "+ 1" comments; if such a thing would bring down the server then I'd assume you'd have much bigger problems.

Edit: clarification

Re: This Year in Matrix

#79

Post by jimmygrapes »

snvzz wrote: post #74
Arathorn wrote: post #58

Earlier quoted context omitted.

Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions? One could encrypt the emoji itself, but it doesn't seem like a massively sensitive datapoint in its own right. (That said, we will encrypt them eventually, but it's just not very high priority given the fact it doesn't practically feel very high impact, relative to all…

It is. The expectation in an E2EE room is that everything that happens there is E2EE. Breaking this expectation is a massive red flag, particularly because Matrix is often chosen with this expectation at the core of the decision.

Just chiming in as a plus one updoot etc. here. I understand the balance of complexity and resources needed to make essentially meaningless data encrypted, and I fall firmly on the side of "do it anyway". I can explain to users that things take longer because they're encrypted, I can't explain to them why they have general sentiment analysis derived from emojis used over time intercepted by in a room they thought was secured.

Re: This Year in Matrix

#80

Post by searchableguy »

Arathorn wrote: post #37
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…

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

Have you considered adding wallet connect based login option?

https://walletconnect.com/

Post reply on HN