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

181–190 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#181

Post by Arathorn »

gwd wrote: post #171
Arathorn wrote: post #67

Earlier quoted context omitted.

wtf is going on is that: a) p2p matrix works pretty well as a proof of concept - you can try it from https://arewep2pyet.com ; it’s not remotely vapourware. b) funding has been spent on core Matrix dev and making Element kick ass (cf Element X) c) an awful lot of very large Matrix + Element deployments (eg LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many German local authorities) decide to run Matrix deploy…

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.

Re: Matrix 2.0: The Future of Matrix

#182

Post by em-bee »

Arathorn wrote: post #178
dingnuts wrote: post #160

Earlier quoted context omitted.

I'm curious and extremely skeptical as to how the UX is going to be made better regarding the terrible UX surrounding encryption. I used Matrix with a non-technical family member for about six months before giving up and going back to SMS because she frequently got messages about encryption that she was in no way equipped to deal with, and did not even begin to understand (yes, the "user-friendly" key fingerprint scr…

Well, just as folks might be skeptical about Matrix clients ever being as performant as WhatsApp/iMessage/Telegram, and yet we eventually got there with Element X... I'm expecting a similar outcome with E2EE UX. The high level plan is: * Fix all the bugs which cause random undecryptable messages, which was the main thing causing frustration. This is (hopefully) done now by converging on the new Rust implementation. *…

that sounds promising. looking forward to it.

Re: Matrix 2.0: The Future of Matrix

#183

Post by mxmilkiib »

brunoqc wrote: post #106
Arathorn wrote: post #67

Earlier quoted context omitted.

wtf is going on is that: a) p2p matrix works pretty well as a proof of concept - you can try it from https://arewep2pyet.com ; it’s not remotely vapourware. b) funding has been spent on core Matrix dev and making Element kick ass (cf Element X) c) an awful lot of very large Matrix + Element deployments (eg LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many German local authorities) decide to run Matrix deploy…

Thanks Matthew, I always appreciate your comments. I also do appreciate the Apache license. Sorry for the vapourware comment. It's hard to tell these days. Was the Google self-driving car thing vapourware? It never went anywhere. I know that pinecone worked as a PoC. I ran a node for years, for fun. It's just that it always felt like the progress was crazy slow. The yggdrasil demo was what, 4 years ago? How fucked up…

Zulip threads are killer.

Shame you can't categorise Zulip streams like you can with channels on Discord though (something that's also related to the IRC/Matrix vs. Discord conversation/content discoverability thing mentioned elsewhere here).

Re: Matrix 2.0: The Future of Matrix

#184

Post by reducible »

dmix wrote: post #169

Does anyone use Matrix/Element for a serious workplace, instead of something like Slack?

I work at a 25 person startup and we've been using Element as our main chat platform for the past 6 months (paid hosting), however we're now in the process of migrating away. I really wanted to like it because it supports good encryption and is open source, but unfortunately it's just too buggy. The main pain points are:

- Stuck notifications [1]

- Being unable to decrypt messages (from certain users sending from certain devices; some people can read them, others can't)

- No proper notifications for old threads

- Various GUI instability bugs: chats that are suddenly empty, text suddenly randomly overlaid on other text, randomly missing scroll bars, etc.

1: https://github.com/vector-im/element-web/issues/24392

Re: Matrix 2.0: The Future of Matrix

#185

Post by inhumantsar »

sneak wrote: post #147
Aerbil313 wrote: post #134

Earlier quoted context omitted.

Then everyone should just roll out their own app… this seems like an EU-regulation-needed situation.

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.

Re: Matrix 2.0: The Future of Matrix

#186

Post by thedanbob »

rabbitofdeath wrote: post #35

I love matrix - I've been running a Synapse homeserver for over 2 years now for friends and family. We love it. Despite minor problems (upgrading postgres for example) it has been smooth sailing. I really want to stay up to date but they don't make it easy! I'd love to add sliding-sync to my existing docker stack, but I feel like I'm in way over my head!

It might be difficult to switch at this point, but I highly recommend matrix-docker-ansible-deploy[0]. Enabling sliding-sync is one config entry.

[0] https://github.com/spantaleev/matrix-docker-ansible-deploy

Re: Matrix 2.0: The Future of Matrix

#187

Post by lmm »

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?

It's "good enough", especially if the alternative is my phone not vibrating when I get a message and I'm not at my desktop.

Re: Matrix 2.0: The Future of Matrix

#188

Post by Macha »

Arathorn wrote: post #140
wkat4242 wrote: post #129

There's no web version of element X though? It's what I use most of the time. I'll try the Android app anyway, I've been having a really annoying bug with the normal one anyway that hasn't been fixed for a year. So perhaps X doesn't have it.

Element X works pretty well on macOS as a desktop client if you have an Apple Silicon Mac. Otherwise, the big Element Web rework is yet to happen. On Android, I can almost guarantee your bug will be fixed: Element X Android doesn’t share any code with Element Android at all, as far as I know (given the former is mainly written in Rust, and the latter is all Kotlin)

This is the second time you've rewritten the Android app with Riot -> RiotX/Element -> ElementX. Just wondering why you throw it away rather than improve it, and if you're at risk of replacing one set of bugs with another?

Re: Matrix 2.0: The Future of Matrix

#189

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.

This comment makes it seem like Apple's anticompetitive stance on sideloading is a basic force of nature instead of something dreamed up by control freak hippies and implemented deliberately in code.

The problem is iOS's privacy-hostile design (in service of their locked down revenue model), not some unbreakable iron triangle.

On Android, messaging apps can run in the background and periodically talk to their homeserver without an intermediary.

Re: Matrix 2.0: The Future of Matrix

#190

Post by tormeh »

Arathorn wrote: post #96
eviks wrote: post #55

Do they also plan to ditch the desktop Electron version for the users to enjoy similar performance improvements?

Element X actually runs really well on macOS already on Apple Silicon; I regularly use it as my desktop app whenever Element Web is having... issues. It would be amazing to plonk matrix-rust-sdk into Element Web and switch Electron for Tauri or something... but one thing at a time.

I’ve wondered about this for a long time: Why not Flutter? Should give you one codebase for all platforms, while being significantly faster than webtech-based solutions.
Post reply on HN