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

Matrix 2.0: The Future of Matrix

matrix.org

Post reply on HN
Print view View original

231–240 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#231

Post by ezst »

brunoqc wrote: post #62

Rip matrix p2p. I wonder if they were serious about it, or if it was just vaporware (a la Musk) to get more funding. It has been announced years ago, they raised millions and they have big governments contracts. WTF is going on?

Matrix folks have been constantly over-promising and under-delivering for almost a decade now. If you've been following long enough, that should be of no surprise.

Sorry for the bashing, but I got bitten once, and I see that nothing has changed in substance, so take this as a friendly word of advice: study the history of Matrix, its protocol, its implementations before committing to it seriously or for your org.

Re: Matrix 2.0: The Future of Matrix

#232

Post by MattJ100 »

ezst wrote: post #228
kevincox wrote: post #50

Earlier quoted context omitted.

IIUC Jabber never really had decentralized group chats? It had MUC but these were federated, so if the server hosting the room went down the chat also died. Matrix rooms are fully decentralized and can survive any servers failing. (Although note that not much else in the protocol is decentralized, much of it is only federated.)

> IIUC Jabber never really had decentralized group chats? Jaber had something like that 5 years before Matrix: https://xmpp.org/extensions/xep-0289.html but decided it wasn't an avenue worth pursuing, as a non-issue in practice. This is further proven by WhatsApp (which is based on XMPP/ejabberd) and its billion active users: you don't have to shove this complexity into the protocol level when it runs natively on a d…

> but decided it wasn't an avenue worth pursuing

To add some colour - there are commercial implementations of that (e.g. https://www.isode.com/whitepapers/federated-muc.html ). But from my perspective as a server developer, I've seen minimal interest in this for the public network. Probably because server failures are rare enough events in the general case.

That's not to say there aren't use cases where it is more valuable to have this functionality.

Re: Matrix 2.0: The Future of Matrix

#234

Post by yobid20 »

As someone who works for a company thats developed their own end to end conferencing stack (utilizing webrtc stack on the client side and all custom conference servers and sfu on the backend), what would be the benefits of adding Matrix support and how exactly would that be done (at a high level)? What would the benefits to users be? Trying to understand what all the hype is about here, and whether or not this would be a venture to pursue and what the business justification would be.

Re: Matrix 2.0: The Future of Matrix

#235

Post by kevincox »

ezst wrote: post #228
kevincox wrote: post #50

Earlier quoted context omitted.

IIUC Jabber never really had decentralized group chats? It had MUC but these were federated, so if the server hosting the room went down the chat also died. Matrix rooms are fully decentralized and can survive any servers failing. (Although note that not much else in the protocol is decentralized, much of it is only federated.)

> IIUC Jabber never really had decentralized group chats? Jaber had something like that 5 years before Matrix: https://xmpp.org/extensions/xep-0289.html but decided it wasn't an avenue worth pursuing, as a non-issue in practice. This is further proven by WhatsApp (which is based on XMPP/ejabberd) and its billion active users: you don't have to shove this complexity into the protocol level when it runs natively on a d…

> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure

But I don't want to trust my community to someone providing me infrastructure. Lots of projects, communities or whatever start small on third-party hosting. Many open source projects right now have rooms on gitter.im or matrix.org. I don't think they made a "bad" choice and I don't think they should need to scramble to find new rooms if their provider goes offline.

> In practice the room survives in a "split brain" mode where different users see different participants

Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.

But also do you have any evidence of this? Matrix rooms don't have a "home server" so if this was a bug that occurred it would occur for any member of a chat going temporarily offline, and for large chats that happens often. So it seems like if this is an issue it only happens in very niche circumstances.

> isn't available to the users whose instance went dark as its no longer hosting their identity

This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.

Look at freenode for example. It was fairly organized as far as shifting a massive group of communities goes but still quite messy. In the matrix scenario rooms could have moved by simply adding new admin accounts on different homeservers and kicking or demoting all admin accounts on freenode. The users wouldn't have to do anything (except moving away from freenode accounts if they prefer).

Re: Matrix 2.0: The Future of Matrix

#236

Post by freilanzer »

amstan wrote: post #72
Arathorn wrote: post #33

Earlier quoted context omitted.

The team rewriting Element as Element X is completely different to the folks who would need to make the change in Synapse to not send push to devices who are currently syncing. Agreed we should have fixed this years ago, especially as it's actually a feature in our pre-Matrix system back in 2012. There's basically a blindspot on long-lived missing serverside features like this; i've added it to a new hitlist we're ex…

I offered a simple fix: delay notifications on all except the active client for 30 seconds, if a read reciept gets triggered from the active client then cancel the timer. I couldn't even get anyone in the team to even look at my solution 3 years ago. Not sure why this feature keeps getting defered for "just about to land and things might be better after" server-side features (see how it has 7 out of 9 "dependencies"…

> I've had a couple of friend actually give up on matrix due to this.

I and several others have also given up and just stay with Signal and WhatsApp.

Re: Matrix 2.0: The Future of Matrix

#237

Post by sneak »

inhumantsar wrote: post #185
sneak wrote: post #147

Earlier quoted context omitted.

This requires paying about $10/month to Apple and doxxing yourself with a lot of PII. It also requires that you as a homeserver sysadmin a) have a Mac, b) install Xcode, c) know how to modify and compile iOS applications, d) want to deal with rebuilding and reuploading and re-seeking app approval on major API changes because long-un-updated apps are not allowed in the App Store, etc...

Security, Convenience, and Speed will always be in constant tension. If you start by assuming that a perfect solution will always be unattainable, deciding on what tradeoffs are acceptable becomes easier. Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.

> Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.

Once you're going to push encrypted data through a centralized service, you might as well just run Signal and skip running the homeserver too.

Re: Matrix 2.0: The Future of Matrix

#238

Post by msm_ »

amstan wrote: post #74
xorcist wrote: post #64

Earlier quoted context omitted.

Is it really that simple though? Jabber tried to be smart about which device to ring, and sometimes someone ended up with a missed notification. I always felt gutting that complexity and ring all instead would have been the more robust way.

So you consider your phone vibrating loudly on your desk for every recieved message while you're actively chatting and reading the same message on your desktop a correct implementation?

Yes, I don't want any clever tricks from my chat clients. I dislike this kind of under-the-hood magic. Client should just receive the message and send a notification if it's not silenced.

Re: Matrix 2.0: The Future of Matrix

#239

Post by vilunov »

cyberax wrote: post #180
vilunov wrote: post #150

Earlier quoted context omitted.

Most of criticism of XMPP with regards to fragmentation and extensions can be applied to Matrix as well. In fact, the sliding sync itself already fragments the ecosystem by not being supported out of the box by many server implementations and therefore homeservers. Encryption often has to be enabled with some machinations as well if we're talking about clients other than Element (and electron-based). On the other han…

This criticism kinda misses the point. E2EE, especially for group chats, is _the_ reason to use Matrix. It's an extremely hard problem, and you'll basically need to replicate what Matrix does if you want to solve it. Doubly so when you add federation. It required more than one iteration of Matrix to get it right, which I (personally) totally expected to happen. I don't think XMPP will _ever_ get it right. Regarding c…

I am actively using E2EE in matrix group chats daily. It is absolutely horrible. Matrix has not gotten it right.

It is a typical situation to observe "Failed to decrypt message" across the whole chat history. It is typical to observe reordering or even lack of messages, which make reading the chat unbearable. It is typical to have problems with session validation.

On one account I have even lost the validated status of another member's sessions, even though we have validated each other before and the only thing that changed is that they logged in with a different client. Since we live in different countries far away from each other, we just have to look at the red shield every time we open the chat and keep in mind that it's not a MITM but just a Matrix failure.

> XMPP just sucks on mobile

So does Element. I have <10 chats joined, and every time I open the Element app I have to wait for 10+ secs before I can start reading new messages. This will surely be fixed by sliding sync, but it's a problem of its own.

Re: Matrix 2.0: The Future of Matrix

#240

Post by snvzz »

Arathorn wrote: post #220
snvzz wrote: post #213

Earlier quoted context omitted.

Is there going to be a way to have very simple clients, perhaps with a helper in the server side? It'd be nice to bring matrix to microcontrollers and "retro" computer platforms.

the API already is super simple, and low bandwidth could already work on retro machines (I had 6809 in mind when experimenting with it). The problem is e2ee, but we have the Pantalaimon e2ee proxy to convert unencrypted Matrix traffic into E2EE traffic for precisely this sort of thing :)

That's promising :)

I had 68000, 8086/88 and 6502 in mind.

Post reply on HN