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

201–210 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#201

Post by toastal »

geek_at wrote: post #43
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!

I love the idea of matrix (synapse + element + mobile apps) and I have started moving my family there too but we had so many problems with notifications not being sent to the phone unless you actively open the app. There is a huge discussion about that on git and some can't reproduce, some can't get a single notification even though the apps notification checkmarks were all green. So it had a very very low WAF [1] an…

> There is a huge discussion about that on git

Git doesn’t have discussions??

Re: Matrix 2.0: The Future of Matrix

#202

Post by toastal »

xorcist wrote: post #69
Arathorn wrote: post #48

Earlier quoted context omitted.

Hmm… we haven’t had notification problems like that in many years, from memory. Any idea if this was trying to deliver push notifs to Android without using Google? (Which historically has been painful thanks to Android OS versions terminating the app in the bg). Element X has totally rewritten notification code (given it’s moved from Kotlin to Rust) and should be much more robust for bugs like this. Sorry you got bit…

Communicating via Apple or Google is sadly required these days. How does that work with matrix? Does the protocol specify how to trigger those notifications? Do I need to register for a Google API key when setting up the server? I can't recall seeing anything about that in the configuration file.

Element supports UnifiedPush. My Prosody server forwards my notifications to me via the Cheogram app.

Re: Matrix 2.0: The Future of Matrix

#203

Post by toastal »

cvwright wrote: post #117
tetrisgm wrote: post #2

I always get so confused by the naming between Matrix and Element. I get that Element is the client, but I honestly thought that the name Matrix for the server (or is it just the standard for the protocol?) was sunset. Great service though and hope if gets UX improvements too, as Discord and Slack keep getting more clutter.

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.

Re: Matrix 2.0: The Future of Matrix

#204

Post by notthemessiah »

tetrisgm wrote: post #2

I always get so confused by the naming between Matrix and Element. I get that Element is the client, but I honestly thought that the name Matrix for the server (or is it just the standard for the protocol?) was sunset. Great service though and hope if gets UX improvements too, as Discord and Slack keep getting more clutter.

I just feel like the use of linear algebra terminology pollutes search results. Maybe they should have named it Passta/Meetball or some unique dumb name, and continued the naming scheme after satirical religions (Church of the Subgenius -> Slack, Discordianism -> Discord, Pastafarianism -> Meetball), like name the protocol Passta (maybe figure out a backronym for it), and the client software "Meetball".

Re: Matrix 2.0: The Future of Matrix

#205

Post by gorgoiler »

cvwright wrote: post #117
tetrisgm wrote: post #2

I always get so confused by the naming between Matrix and Element. I get that Element is the client, but I honestly thought that the name Matrix for the server (or is it just the standard for the protocol?) was sunset. Great service though and hope if gets UX improvements too, as Discord and Slack keep getting more clutter.

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.

Growth in revenue-free end users might not be fantastic news for the Matrix team. As I understand it they make money from b2b integrations (eg French government) and supporting a horde of WhatsApp transplants is only ever going to be a net negative cost centre for them.

There aren’t exactly many so it’s a bit hard to generalise but free, large scale chat apps are the side projects of tech companies with existing revenue streams.

Re: Matrix 2.0: The Future of Matrix

#206

Post by bobbylarrybobby »

tetrisgm wrote: post #2

I always get so confused by the naming between Matrix and Element. I get that Element is the client, but I honestly thought that the name Matrix for the server (or is it just the standard for the protocol?) was sunset. Great service though and hope if gets UX improvements too, as Discord and Slack keep getting more clutter.

A matrix is made up of elements :)

Re: Matrix 2.0: The Future of Matrix

#207

Post by LWIRVoltage »

Being a user of E2EE video chat tools and calling apps, - I've been following this, especially more closely ever since Jitsi disabled anonymous video calling on thier main instance /Jitsi Meet

(Yes, there is a the Jitsi Meet Community Instances that are still with the original full functionality that people can access- If they search for Jitsi alternative community instances on a search engine, which isn't something most will be aware of for your average user...)

Having been a user of the Jitsi Meet Electron App even on Linux and Windows(along with the web accessible variant)- and having followed closely the efforts by Firefox on RTCRtpScriptTransform (formerly webrtc insertable streams) mainly to support Jitsi E2EE calls- has been interesting to watch.

Though now with the new Google/Meta/Microsoft account requirement/non anonymous aspect, all of that minus the community instances web interface sites are of use to me now.

If i follow fully, Element Call in a way replaces Jitsi Meet's original capability- though E2EE encryption doesn't have to be "Turned On " in a Chromium based browser - and Element Call isn't yet something that can be launched from a desktop app on Windows or Linux in a similar user-friendly way (I see the Vector IM client is a thing)

- The main difference being for using Element/Element X, one new from the Jitsi Meet ecosystem /usecases i've mentioned, will have to make an account- and for your average user who cannot easily learn about and deploy a server and how to host that on their own- but is looking for privacy- it is trickier to judge and will be more steps , to achieve anonymity from a privacy perspective.

I see the P2P effort is another step towards this as well

I'll likely try to use Element Call and point those I know who use tools like this towards it due to Jitsi's recent changes - as Element Call's web interface is user-friendly enough, and that is the main challenge. What Element is outside of that- and how it integrates into everything and how to use it in the same way in it's other forms- will be interesting to introduce, as those are developed further.

Re: Matrix 2.0: The Future of Matrix

#208

Post by npoc »

beardog wrote: post #119
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…

Makes me sad that billions got poured into cryptocurrency-sphere projects but classic p2p barely scrapes by. (I mean by society not new vector)

You probably don't understand the enormous world-corrupting problem with fiat currencies.

Re: Matrix 2.0: The Future of Matrix

#209

Post by progval »

sfink wrote: post #197
dmix wrote: post #169

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

We use Matrix (mostly via Element) at Mozilla alongside Slack. It's mainly public stuff on Matrix, and the usage pattern varies between teams: some teams are mainly Slack and barely pay attention to Matrix rooms, other teams (like mine) kick and scream if they're forced to use Slack for anything but internal corporate purposes. New hires in such teams tend to assume Slack initially and gradually notice that they get…

> Abuse is vastly more manageable than it was on IRC.

You're comparing a Matrix server operated by someone else (Element) with an IRC network that Mozilla operated themselves. How does your Matrix setup compare to an IRC network operated by a dedicated team like Libera.Chat or OFTC?

Re: Matrix 2.0: The Future of Matrix

#210

Post by Arathorn »

mycall wrote: post #200
Macha wrote: post #188

Earlier quoted context omitted.

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?

Probably from too many mistakes and/or new maintainer and/or better ways to do it. Same as it ever was.

The reason for Riot->RiotX (aka Element) on Android was to both move to a modern Android UI idiom, move to Kotlin, and have a well defined storage interface and switch to Rx patterns, whereas the original app had been built somewhat organically. And yes, the maintainer had changed.

The reason for Element -> Element X is in order to share precisely the same Rust SDK between iOS and Android (and maybe other platforms in future), so all the heavylifting happens in one single audited codebase, rather than doubling up all the development between iOS and Android, doubling the bug count, etc. It’s also a good opportunity to simplify the data flows, which are surprisingly subtle and performant in a messaging app; I’m not sure how much Rx remains. In this instance, the maintaining team remained the same.

Post reply on HN