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

221–230 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#221

Post by CyberShadow »

UltimateEdge wrote: post #7

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

FWIW, if you use matrix-docker-ansible-deploy, enabling the Sliding Sync proxy involves just adding one line to your configuration (for the most common setup).

https://github.com/spantaleev/matrix-docker-ansible-deploy/b...

Re: Matrix 2.0: The Future of Matrix

#222

Post by gwd »

Arathorn wrote: post #181
gwd wrote: post #171

Earlier quoted context omitted.

Just poking around matrix.org, it's not clear exactly how one would "route [some] $[s] to support development" other than paying someone else for a hosted server. Our open-source project just switched to using Matrix from IRC; we're not really big enough to warrant hosting our own Matrix server, so most of us are just using matrix.org. We have some industry funding, and try to support other open source projects when…

Well, we need to fix that then. https://matrix.org/membership/ and https://matrix.org/blog/2023/06/membership-program/ is the way to donate.

I see now that somewhere most of the way down the front page there's a button-type link to "Support Matrix", which leads to a page which points either to membership or to a handful of ways to donate:

https://matrix.org/support/

I'd suggest you make sure there's a link to that page 1) somewhere in the menus 2) somewhere in the footer. I'd also make a link to the membership page from the "About" page, and a link to the "Support Matrix" page from the "Membership" page, so that people who manage to find the Membership page but aren't ready to become members can support via patreon / whatever.

Thanks for all your work on Matrix! Looking forward to seeing the improvements coming down the line!

Re: Matrix 2.0: The Future of Matrix

#223

Post by freilanzer »

Arathorn wrote: post #33
amstan wrote: post #18

It's quite disappointing that there's huge ongoing work around reinventing clients from scratch where the basic functionality of not ringing all my devices while I'm using only one of them [1] is still not there (bug open for years), despite it being a pretty simple fix. [1] https://github.com/vector-im/element-meta/issues/360

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…

Well, that doesn't exactly inspire confidence in the project for me.

Re: Matrix 2.0: The Future of Matrix

#224

Post by nostrfanboi »

toastal wrote: post #203
cvwright wrote: post #117

Earlier quoted context omitted.

Yeah. I still think that the Matrix.org Foundation should have a branded client, simply called “Matrix”, available in all the major app stores. Lock it to the matrix.org server and offer membership in the foundation as an in-app purchase. Could help with some of their recent funding issues.

The fact that the group in control of the spec, the reference server, the most popular client, & the biggest server is the same entity is problem enough as it is for control/decentralization. Branding it top to bottom as Matrix would be the beginning of the end to me.

Matrix federation is inherently too centralized to my taste. You always rely on a server and a domain name. HN geeks can run their own server but still depend on ICANN down the line.

Re: Matrix 2.0: The Future of Matrix

#225

Post by ezst »

UltimateEdge wrote: post #7

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

Sliding Sync is just your old bouncer with lip service and a fancy name, because the Matrix protocol is now officially deemed hopeless to be implemented efficiently on the client side, hence the need for a proxy to maintain your "client state" i.e. your client running on the server.

I'm really tired of the litany of buzzwords and excuses that the Matrix team comes up to cover-up this large sunk cost fallacy of a protocol. Nobody needs a distributed graph database and state resolution to prop-up a chat system. It has not proven to have any real-world benefit nor served to build a niche in which Matrix is in any way better than the competition. It's been a failed experiment for about 10 years with no end in sight. At what point does the community wake up to all the nonsense?

Re: Matrix 2.0: The Future of Matrix

#226

Post by ezst »

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…

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

I would be inclined to call this FUD. XMPP had E2EE before Signal and Matrix even were released. Current XMPP uses a flavour of double ratchet encryption (OMEMO) that puts it in par with those two, while working on MLS (just like Matrix).

> And forget about mobile apps, XMPP just sucks on mobile.

And yet, Conversations uses a fraction of the energy and resources Element requires. And does audio/video calls more reliably. And works well for 1:1 to large chat groups with thousands of participants.

Re: Matrix 2.0: The Future of Matrix

#227

Post by ezst »

Arathorn wrote: post #75
self_awareness wrote: post #19

How Matrix decentralisation is an improvement over Jabber's decentralisation? (disclaimer: I have no knowledge about neither spec, I'm not suggesting Jabber was better)

It's more that Matrix is different to Jabber/XMPP. In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git. In XMPP, you pass messages between clients on different servers using a given server as a hub, and clients can choose to back up their message history on their local server. Wh…

> In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git.

XMPP had FMUC (Federated Multi-User Chats) about 5 years before Matrix was even invented. It didn't see broader adoption in the XMPP world because the community figured that this isn't a problem worth solving, and/or that the incurred complexity isn't worth it.

And worse, Matrix even hasn't found an adequate and scalable solution for this "proud" ambition (and probably never will). I don't expect that you could demonstrate in good faith that distributed state and its resolution are a net positive for Matrix, its community, its ecosystem, nor that it has opened new possibilities for the practical cases and users. We are back from the blockchain hype/hangover already, and I can't wait for the same thing to happen to Matrix: this was the wrong tool for the job. Just let it go.

Re: Matrix 2.0: The Future of Matrix

#228

Post by ezst »

kevincox wrote: post #50
self_awareness wrote: post #19

How Matrix decentralisation is an improvement over Jabber's decentralisation? (disclaimer: I have no knowledge about neither spec, I'm not suggesting Jabber was better)

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 distributed/federated infrastructure (the erlang VM in this case).

> Matrix rooms are fully decentralized and can survive any servers failing.

In practice the room survives in a "split brain" mode where different users see different participants, the room isn't available to the users whose instance went dark as its no longer hosting their identity, and messages are popping mid history while the state resolution is working hard to reach consensus. When the servers finally come back online, there is a risk of never catching up fully, or worse, for the rooms to remain split forever.

And I adventure a hot take there: this property of staying seemingly online (in a frankenbizarre way) came handy way fewer times in the history of Matrix than for all the incurred complexity reflected in daily bugs, privacy, security, performance issues and inconsistencies.

Re: Matrix 2.0: The Future of Matrix

#229

Post by ezst »

monlockandkey wrote: post #133

Does anyone know how to integrate chats into a web app using Matrix. Rather than writing a messaging web app from scratch, can I hook into matrix?

That's a use-case where XMPP shines, historically. There are embeddable/lightweight clients doing that job well without all the matrix fuss.

Re: Matrix 2.0: The Future of Matrix

#230

Post by camgunz »

freilanzer wrote: post #223
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…

Well, that doesn't exactly inspire confidence in the project for me.

I like the honesty; oddly it has the opposite effect on me.
Post reply on HN