Matrix 2.0: The Future of Matrix

https://matrix.org/blog/2023/09/matrix-2-0/

by jrepinc • 3 years ago

599 273 3 years ago

tetrisgm• 3 years ago

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.

CameronNemo• 3 years ago

Maybe you are confused because the old client name, Riot, was sunset in favor of Element?

AIUI the protocol was and is called Matrix. There seems to be no intention to depart from that name.

hparadiz• 3 years ago

They renamed Riot to Element in the wake of the George Floyd protests in the United States. It's the same code base.

Matrix is a protocol. Synapse is the primary server implementation of Matrix written in Python.

SushiHippie2• 3 years ago

Element is to matrix what chrome is to http. The most used client for that protocol.

progval3• 3 years ago

Element is the trading name of a company, of three clients with mostly-independent codebases written by that company (web, android, iOS; not counting the two Element X rewrites), and of a hosting service (EMS).

infinitezest2• 3 years ago

As much as I love the fact that I have my choice of server and client I have to say that it does make me wonder if it affects adoption. When the Mastodon growth spikes happened the complaint that I heard most often was from people that couldn't figure out which client to use or which instance to use. Too much choice tends to paralyze people and they default to proprietary services because they don't know what choices to make.

cvwright4• 3 years ago

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.

toastal3• 3 years ago

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.

gorgoiler• 3 years ago

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.

thisisabore2• 3 years ago

Do you think email should have a branded client, simply called "email" available in all the major app stores? Or XMPP have a branded client, simply called "XMPP" etc.?

Align on a protocol, experiment and compete with clients is a good way to make progress.

notthemessiah• 3 years ago

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

anticensor• 3 years ago

The use of math terms is intentional.

bobbylarrybobby• 3 years ago

A matrix is made up of elements :)

thisisabore2• 3 years ago

Matrix = email. Element = Thunderbird, Outlook, etc.

The Matrix name has never budged since the beginning of the project. One of the Matrix servers is called Synapse. Others include Conduit or Dendrite (see https://matrix.org/ecosystem/servers/).

So yes, Matrix is the protocol, not the/a server.

UltimateEdge3• 3 years ago

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/experiment and I wish that we would be having this conversation about Element X after it becomes usable with any spec-compliant server.

Arathorn49• 3 years ago

Matrix evolves as a protocol by folks proposing new APIs (e.g. MSC3575), implementing them, showing that they work, and making the case that they should be merged into the main spec.

Sliding Sync is an interesting case in that it clearly does work, and it kicks ass - but it turns out to be unnecessarily complicated for the subset of features that you actually need when implementing something like Element X (which is my fault entirely, fwiw). However, should we hold off on putting it in people's hands while we sort that? Nope. Is it a pain to temporarily run a proxy shim service while the protocol stabilises? Yes. It's like running a SPDY or QUIC-aware reverse proxy in front of a webapp that only speaks HTTP/1.1 while waiting for SPDY to be ratified as HTTP/2. Sure, it's another moving part to look after, but the spectacular improvement is likely worth the pain. YMMV though :)

UltimateEdge3• 3 years ago

Matrix evolves as a protocol by folks proposing new APIs (e.g. MSC3575), implementing them, showing that they work, and making the case that they should be merged into the main spec.

Yes, it is just unfortunate that it is not clear enough to more people (such as the_common_man below) that Sliding Sync is only at the MSC stage at the moment and not part of the Matrix spec.

I am glad that at least Element X allows this MSC to improve and for those nits you have mentioned to be resolved.

the_common_man• 3 years ago

Why is sliding sync a separate service and not just part of synapse itself?

UltimateEdge3• 3 years ago

It's currently still a proposal to the spec, and it is not yet part of the Matrix protocol.

Arathorn49• 3 years ago

Because the API is still evolving, and it's also useful that it supports other homeservers than Synapse. It's also written by an entirely different bunch of people (it's effectively written by the Dendrite team rather than the Synapse team).

Once the API is stable I'm sure all the homeservers will implement it natively. Until then, think of it like a reverse-proxy that lets an HTTP/1 webapp talk HTTP/2 to the outside world.

infinitezest2• 3 years ago

I would guess it's so the same functionality can be used with other Matrix servers without having to rewrite the whole thing

the_gipsy2• 3 years ago

Well you can just wait. But the proxy is really lightweight and doesn't require maintenance.

rovr1382• 3 years ago

Until there's an incompatibility, upgrade, exposure, memory overflow, or some other security issue/exploit. Unless you're saying that it's immune to everything and will never experience a change or issue.

mike-cardwell2• 3 years ago

I just set it up. Wasn't that difficult:

1. Added a new postgres db and user 2. Added a new dns name 3. Added a new cert for the new dns name 4. Added a new vhost to nginx to proxy to a new port using the new dns name and cert 5. Added a simple docker-compose to my config 6. Added a snippet to my .well-known/matrix/client

Don't imagine it will take much maintenance. Container will be updated along with the rest of my containers, and the existence of the service doesn't change anything for any existing clients that don't support sliding sync.

Arathorn49• 3 years ago

The most important thing is to keep it updated, as we're fairly rapidly iterating on it, and most of the Element X bugs we've seen have actually turned out to be a stale Sliding Sync proxy deployment. Glad it was fairly straightforward.

CyberShadow• 3 years ago

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

ezst9• 3 years ago

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?

orange-mentor• 3 years ago

I 100% agree with this. I wanted to like Matrix, and I ran synapse for a while, but the operational aspects of it are an order of magnitude more complex than XMPP.

Perhaps the problem they're trying to solve warrants that complexity, but my particular use case doesn't. I just run XMPP now.

panick21_5• 3 years ago

This comment makes no sense. The database replication has nothing to do with sliding sync. Sliding sync is about replacing the client to server protocol, and database replication is the server to server protocol.

Its flat wrong to say that it can't be efficiently implemented on the client side, the server side of the Api is the problem, not the client.

abdullahkhalids• 3 years ago

Is Matrix simple enough now that I can invite my grandpa/grandma and they will be able to join?

How does ease up sign up and use compare to discord?

Assume that I make the choice of which client to direct them to.

masfuerte2• 3 years ago

My octogenarian mother uses it.

airstrike• 3 years ago

Did she set it up herself?

Arathorn49• 3 years ago

Matrix itself is a protocol, so is as hard or easy to use as the client that you use to access it.

Matrix 2.0 is all about demonstrating that a really really fast, mainstream-grade app can be built on Matrix, in the form of Element X: https://element.io/blog/element-x-ignition/. However, right now Element X is intended for existing Matrix users - so unless you have a bleeding edge homeserver, sign-up doesn't work yet. So it's not quite in grandma/grandpa territory yet... but once you're in, it most certainly is.

soupbowl3• 3 years ago

It is less simple than discord and I does not have good audio rooms. I setup family accounts and store their security key for them. Then I help them setup their app in a few minutes and paste them their security key once they are on my matrix server.

In the past I left sign up and setup to family and the element app and it has never worked smoothly. They don't understand the security key purpose or verifying clients.

So to answer your first question, yeah you can invite grandma and grandpa but they probably will need some hand holding at the start. Once they are in, it just works™**. YMMV

jwrallie• 3 years ago

It may not be easier than other proprietary stuff, but it is easy enough and probably the easiest you can get from the free software side.

Just install Element on iPhone or Android and make a matrix account from there, then add each other by the selected username.

You will only have to help your grandpa when you start to add secondary devices that need to be authenticated the first time with a QR code (for decryption purposes).

I have been using Element to text my wife for around 6 months (Android to iOS). I took the opportunity when she was getting notification issues with a proprietary app to convince her to use it. She loves it now. Clean interface, no ads, and voice call works just fine for us.

neilv2• 3 years ago

Thoughts on how this will get us towards when libre software privacy&security type people are ready to advise friends to move to Matrix for personal communication?

(To be clear, the platform has to be all open source and open standards, actually decentralized, guided by those principles -- not an effectively proprietary play even if nominally open. For example, you should be able to get all the same functionality with Element, Fluffychat, Thunderbird, and other user agents, and with any home server, both now and on an ongoing basis. And the user agent implementation difficulty should become tractable enough, in terms of size&complexity and specification, that one person could write a new one -- not like Web browsers have become, where there's mainly only one, that company has been funding the runner-up, and that company can pretty much dictate 'standards'.)

Arathorn49• 3 years ago

Matrix 2.0 is a major step towards getting friends & family on Matrix.

Firstly, it's not introducing new features - it's just making the current featureset work super-efficiently (while retaining compatibility with today's Matrix). So there should be no fragmentation between Element/Fluffychat/Thunderbird, with the possible exception of the new scalable encrypted VoIP conferencing (but then very few Matrix clients implemented the old VoIP conferencing, plus you can always just embed an Element Call instance to get at it now - as Element X does today).

Secondly, we're explicitly working to protect Matrix from the commercial interests from Element (the company set up by the team who created Matrix, of which I'm ceo/cto as well as Matrix project lead). We already have The Matrix.org Foundation (https://matrix.org/foundation) as an independent non-profit to hold the Matrix IP and maintain its neutrality - but we also just hired Josh Simmons (former President of the OSI) as its independent Managing Director (https://matrix.org/blog/2023/09/introducing-josh-simmons-man...).

So: going forwards, the Foundation increasingly does not have to depend on Element not being evil, but instead has its own independent management to ensure the protocol exists to support everyone in the ecosystem, without fragmentation, as per the guiding principles at https://matrix.org/foundation - under its own autonomy.

I'd say this is is good news for libre software privacy & security type people, but then again I'm biased. Practically, the only thing getting in the way of getting friends & family on Matrix is that Element X requires fancy OIDC-native homeservers for registration, so newbies won't be able to use Element X to join Matrix yet. But the app itself should be an excellent way to get folks on board in the very near future.

neilv2• 3 years ago

Thank you for the comments. I'll keep my fingers crossed that this plays out well.

plus you can always just embed an Element Call instance

That sounds like potentially a commercial embrace&extend&extinguish situation, which we need to avoid.

em-bee2• 3 years ago

element still has serious usability issues that need to be fixed before i can get friends or family on board.

the way threads are displayed in the browser versions makes them hard to follow. in our hackerspace, where many are tech minded people, i see regular complaints about that.

scrollback to unread messages often fails. i have never had another chat application where that was a problem. this should just work.

the handling of encryption keys is very confusing. there are to many moving parts, it's not clear what i must save so that i can restore the keys in a new client.

private rooms are also confusing. i want to have a private room be the name of my chat partner, and they want it to carry my name. being able to do that would be very helpful.

i am also missing the ability to use a different nickname in every room. different groups know me under different nicknames. discord and wechat can do it. it would be great if matrix/element could do that too.

kevincox4• 3 years ago

FWIW my partner and mother are using it. We have had the occasional key synchronization issue with Element but has been mostly smooth sailing. I did walk them both through the setup but they probably could have managed. However they have some basic tech skills. I suspect that others in my family with little tech literacy would need to have it set up for them but would probably be fine after that.

sneak4• 3 years ago

One of the big problems as I see it is that all notifications on iOS must be proxied via APNS and those can only be sent by the app publisher, so all home servers must send their iOS notifications to Vector (the Element publishers) to be sent to APNS and on to an iPhone or iPad.

This is a centralized point for surveillance of metadata. I also do not know how much information is actually contained in the notification itself. In any case Vector has knowledge of every home server with an iOS client, and their approximate traffic levels.

Aerbil313• 3 years ago

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

amstan4• 3 years ago

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

Arathorn49• 3 years ago

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 experimenting with for trying to clear these up.

amstan4• 3 years ago

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" resolved) when none are needed.

I've had a couple of friend actually give up on matrix due to this. I also have to keep my phone on silent or else I can't be chatting on matrix without the constant bzzzing.

I'm also amused about the ever growing (currently at $760) bounty on this feature.

freilanzer2• 3 years ago

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

Arcuru• 3 years ago

There are quite a few issues that they've stopped fixing in the Element app in favor of doing it in Element X, the one I've been following is where the iOS app causes a breakage in E2EE when you use the share extension, so they just disabled the share extension entirely and said they'd fix in X - https://github.com/vector-im/element-ios/issues/7618

But X requires Sliding Sync on the server, which is still a separate service to run alongside the homeserver and doesn't have a stable API. I am increasingly disappointed with how centralized Matrix is becoming, since AFAIK there isn't really an alternate client close to the same level of quality as Element.

I probably would've made all of the same decisions myself though, so I don't blame them I'm just a bit disappointed in how it's shaking out.

panick21_5• 3 years ago

You just can't have the newest fancy client without also having the new fancy server. That seem to make sense to me.

xorcist5• 3 years ago

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.

amstan4• 3 years ago

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?

eternityforest• 3 years ago

What about P2P multicasting between devices? Delay for 1 second, if you get an "I did the beep for message hash X" notice in that time from a higher priority device that is currently being looked at, don't.

A bit of a privacy leak on shared networks revealing which IP is doing messaging, but it should be fast and reliable.

neop1x• 3 years ago

Multiple accounts also https://github.com/vector-im/element-android/issues/26 and they closed the issue for it in the Element X https://github.com/vector-im/element-x-android/issues/190

A pretty basic functionality which even Messenger supports....

self_awareness• 3 years ago

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)

kevincox4• 3 years ago

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

ezst9• 3 years ago

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.

Arathorn49• 3 years ago

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.

Which architecture you prefer probably depends on whether you think instant messaging should be about passing messages or archiving chat history.

ezst9• 3 years ago

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.

cyberax2• 3 years ago

Jabber core protocol (XMPP) is kinda like SMTP. It deals with transmission of messages between two peers. Just like with SMTP, you can federate servers, so they can exchange messages between each other.

And the similarities don't end here. XMPP doesn't have built-in support for encryption (apart from the basic TLS encryption for the transport layer), it doesn't have support for message archiving and chat history syncing, there is no support for group chats, and so on.

A lot of this functionality is added as extensions (e.g. group chats are XEP-045), but this simply caused a lot of fragmentation in the ecosystem. So you could never rely on your client (or server) interoperating with other clients properly.

Audio calls and video also never really worked well. Google tried to push them by releasing libjingle in 2006 (!!!) but it was kinda ignored by everyone.

vilunov2• 3 years ago

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 hand, XMPP desktop clients certainly work better and faster than Element, although some of them look quite old, which doesn't take away from their functionality.

IMO it's being heavily overstated how Matrix is better than XMPP.

Also a nice read: https://telegra.ph/why-not-matrix-08-07

And the answer https://lobste.rs/s/wvi9xw/why_not_matrix#c_erbsnb

amatecha7• 3 years ago

Regular reminder Matrix/Element work closely with law-enforcement to provide encrypted comms for them. It's a sector Matrix/Element actively markets to and deals with. My personal view is I'm not using a chat platform designed/developed by an organization so eager to partner with governments and law enforcement agencies.

There's Element's Chief Product Officer & Managing Director presenting at the European Police Congress[0]: https://mastodon.matrix.org/@element/110310853505977058

And a quick post about their excitement at participating in this conference: https://mastodon.matrix.org/@element/110304013472307767

I mean, whatever, it's just doing business, right? When someone criticized this, they gave a snarky, surprisingly unprofessional response: https://mastodon.matrix.org/@matrix/110334695988903649

Dunno about anyone else but my trust in them is just gone. I'm not saying you have to care (and I don't care if you do). I'm sharing this for the people who do care, and don't want to use "secure messaging" made by people who actively market to and collaborate closely with law enforcement and governments.

[0] https://www.european-police.eu/

__s• 3 years ago

What's the problem with e2e encryption for those organizations?

The problem is if they give those orgs a backdoor

amatecha7• 3 years ago

Oh yeah, I actually asked them about that. They said there aren't any backdoors[0]. We're all good, no worries! :) :)

[0] https://mastodon.matrix.org/@element/110340953550548309

EGreg• 3 years ago

But that doesn’t mean Matrix makes backdoors. So you can use it too.

What’s wrong with helping organizations including law enforcement encrypt their communications?

Because they are public servants and We the Public should have ways to be able to decrypt those communications.

Secret meetings and intelligence agencies are what leads to totally avoidable wars.

https://community.qbix.com/t/transparency-in-government/234/...

jazzyjackson2• 3 years ago

Fair enough to share the information but I take the opposite tack: if it's good enough for LEOs, good enough for me.

I would also be excited to find paying customers when trying to build free software.

In any case I get the feeling if I were to avoid technology built by companies with government contracts I would be left with my retro 8bit machines. Lets be pragmatic.

soupbowl3• 3 years ago

I don't really see the problem here, I would prefer my local government use open standards that are secure. If they are weakening the crypto to help the police and government come after me then I would have a problem.

panick21_5• 3 years ago

Really strange Point of View. Governments adopting open standards rather then paying money to US tech companies is a good thing.

kevincox4• 3 years ago

I find no issue that the company is working with law-enforcement to provide secure communications. In fact this makes me feel better about the security of those communications as they are trusted by these governments (not that this is a huge mark of quality, but I would consider it positive).

I your distrust of law-enforcement so strong that any company that they purchase from must be untrustworthy? Or is there another reason that this bothers you?

amatecha7• 3 years ago

My concern is in the opposite direction of what everyone appears to be interpreting, despite what I thought was clear wording in my initial post.

It's not that govt/LE uses Matrix. It's that Matrix/Element actively seeks out partnership with govt/LE (to the extent of presenting on stage at a police conference), suggesting they are particularly interested in a relationship with authorities and personally sympathetic to these authorities, at the management/director level.

This is not a position I expect from an organization that is determined to build secure communications potentially used by activists, people living in oppressive/authoritarian regimes, etc... If I was a member of such a high-risk group, I don't think I would be putting my faith in this org to produce something I can actually consider truly secure.

nobody99994• 3 years ago

Regular reminder Matrix/Element work closely with law-enforcement to provide encrypted comms for them.

Thank you for the reminder. Based on that, are you claiming that Matrix servers/clients are insecure or have government back doors?

If so, what evidence do you have that supports such a claim?

If not, why should I care? I'm not a fan of many organizations/individuals. Should I survey them all to create a database of software those folks use and refuse to use any software they use? What value would I derive from such actions?

Unless you're claiming the former (evidence please), what difference does it make? I use Matrix servers/clients only on hardware that's under my physical control. And I use free (libre and beer) versions of Matrix implementations, so I'm not even giving the developers any money.

Or are you making the argument that LEOs shouldn't have access to secure communications protocols?

I guess I'm confused because I don't understand what the issue might be. If you'd elucidate, I'd much appreciate it!

amatecha7• 3 years ago

I didn't claim/assert anything other than what I linked to already in my original post.

You don't have to care, and like I said, I don't care if you care or not. I'm just making people aware, because some people _do_ care.

It's nice that you personally use matrix on hardware under your physical control. That's rare. The vast vast majority of matrix users have their account on matrix.org and are using Element. I'm glad to hear you are using alternative server and client software.

I addressed the other questions at https://news.ycombinator.com/item?id=37602089

cvwright4• 3 years ago

You are mad that they took money away from someone you don’t like?

And moreover that they used this money for something that you do like?

Smaug123• 3 years ago

"Taking money" is a very poor description of a trade, which both parties chose to enter into because they both expect to derive benefit from it. What the parent objects to is presumably the "government/police/military expects to derive benefit" part, not the "taking money" part per se.

orblivion• 3 years ago

The European Union’s Digital Markets Act (DMA) is a huge step in that direction - regulation that mandates that if the large centralised messaging providers are to operate in the EU, they must interoperate.

Wow. Not interested in winning the war this way.

kibwen3• 3 years ago

Requiring protocols for interoperation results in more competition in implementations, which is often the better scenario as far as users are concerned.

Lacusch• 3 years ago

Maybe you're not but I know a few people (myself included) who will take any win on the privacy front we can get.

rabbitofdeath• 3 years ago

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!

geek_at• 3 years ago

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] and I scrapped it sadly. This was a few years ago, any signs of these problems still existing?

[1] https://en.wikipedia.org/wiki/Wife_acceptance_factor

soupbowl3• 3 years ago

I had this problem 2 years ago and it ended getting fixed. Recently I seen it again and the problem was that my container running synapse did not have working DNS which caused all notifications to stop working. Once I fixed up resolv.conf all was working.

I am not suggesting that was your issue but it might help somebody.

Arathorn49• 3 years ago

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 bitten by it.

Twirrim• 3 years ago

If any of those are android users, it may be down to the non-android standards friendly battery optimisation the manufacturer ship their devices with (e.g. Samsung, Huawei, OnePlus, Xiamoi, etc.)

https://dontkillmyapp.com/

I've had more issues with missing notifications on my OnePlus than I ever had on my Pixel (I have list of reasons why I'll never buy Google hardware again, mostly coming down to their support). Most issues get fixed by me persuading OnePlus to stop applying their secret sauce to power control

toastal3• 3 years ago

There is a huge discussion about that on git

Git doesn’t have discussions??

chagaif• 3 years ago

You probably just need to change the settings to battery saver - no restrictions for Element. Your OS is probably killing the app aggressively (I've seen this with telegram a lot as well with many people).

thedanbob• 3 years ago

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

tptacek2• 3 years ago

Just a question, I haven't been paying attention, but where is Matrix on resolving the Nebuchadnezzar vulnerabilities, and is the project still tracking towards switching to MLS instead of Olm/Megolm?

contact98792• 3 years ago

Outside of Matrix 2.0 work, other big items on the horizon include:

- Adding Rust matrix-sdk-crypto to matrix-js-sdk, at which point all the official Matrix.org client SDKs will (at last!) be using the same stable performant E2EE implementation

- Continuing to contribute Matrix input to the MIMI working group in IETF for > Digital Markets Act interoperability

- Working on MLS for next-generation E2EE

IIRC, the rust matrix-sdk-crypto was their intended fix for the vulnerabilities.

Arathorn49• 3 years ago

The main remaining Nebuchadnezzar issue is mitigating server-controlled group membership. The first step has been to kill off the 1st gen E2EE implementations, which were responsible for the implementation vulns found by RHUL - and we should hopefully conclude that next week by moving everything into the matrix-rust-sdk crypto crate implmentation: https://github.com/vector-im/element-web/issues/21972#issuec... is the tracker.

Then, we can address the harder server-controlled group membership issue in one place. First step will be to improve device verification & trust so that trust is the default, not the exception, to make it easier to spot and warn about unexpected devices in the room. The full solution is then either MSC3917 (https://github.com/matrix-org/matrix-spec-proposals/blob/fay...) - or potentially to switch everything to MLS.

We're working on MLS anyway in parallel to RHUL mitigation work; you can see the progress at https://arewemlsyet.com, and it's looking good.

I'm guessing you're not interested in doing a podcast on "yay we converged our crypto implementations on a single robust Rust implementation so we can fix the remaining bugs in one place", but as soon as the server-controlled group membership thing is solved we'll be in touch. Work has also gone much slower than hoped on this, thanks to the joys of funding open source.

tptacek2• 3 years ago

INCORRECT. The messier your situation is, the better the podcast will be. You're still in my top 3 subjects for us to do an episode on. I'm rooting for you! But also for sound messaging cryptography. So I'm one of your most complicated supporters. :)

eviks• 3 years ago

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

Arathorn49• 3 years ago

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.

fabrice_d• 3 years ago

It would be nice to provide first class support for state of the art web clients (both desktop and mobile). That would fit your opening stance of "Matrix has been going for over 9 years now, providing an open standard for secure, decentralised communication for the open Web" more than apps tied to the iOS/Android app ecosystems.

tormeh• 3 years ago

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.

internetguy• 3 years ago

Awesome! I've been using matrix on and off for around 3 years and I absolutely love it.

kibwen3• 3 years ago

Techy friend group of mine migrated from Discord to a self-hosted private Matrix server a few months back. No complaints so far, although we didn't use Discord's voice/video/screen-sharing features (which I hear that Matrix intends to support eventually).

UX-wise, it made me appreciate the distinction between Discord's "everyone is subscribed to every channel in a server by default" stance, and IRC/Matrix's opposite approach. The latter certainly scales better, but the former is so, so much better for discoverability, so it's probably the better default for small servers.

And if you're looking for a Matrix client with a Discord-like UI, try Cinny.

Arathorn49• 3 years ago

The plan on Discord-style voice/video/screensharing features is Element Call (https://call.element.io) which is built to be embeddable into Matrix clients. It’s already in Element X, and is in Element Web/Desktop behind a labs flag. Meanwhile you can always embed Jitsi.

solarkraft2• 3 years ago

As far as I'm able to tell most call functionality is built into the JS SDK (is this true), so what will embedding Element Call actually gain me? The (beautiful!) UI?

Pufferbo• 3 years ago

How did your friend convince your friend group to migrate over to Matrix? I’ve thought about setting up one but my group isn’t so much into the “do it yourself techies” or privacy conscious crowd.

TheHappyOddish• 3 years ago

The tech skill requirements are fairly low if someone hosts a homeserver everyone joins, or everyone joins a public.

kibwen3• 3 years ago

As mentioned, this group is composed of techies who have an innate distrust of proprietary platforms, and the Reddit debacle (following so close on the heels of Twitter's ongoing debacles) was enough to tip the scales against continuing to operate the Discord. For groups of non-techies who care about convenience over all else, sadly I just think you're going to have to wait (or contribute yourself!) until Element/Matrix adds more UX polish.

That said, one thing that did help a lot was having the server host a default client. Anyone can still connect to the server using any client they want, but now they can also go to the server's URL and get a good client without any hassle. We chose Cinny as the default client because it's solid and extremely familiar to any Discord users.

brunoqc2• 3 years ago

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?

contact98792• 3 years ago

It's still in development[1]. Seems like p2p will depend on dendrite so until dendrite is stable, p2p will not be available.

[1] https://arewep2pyet.com/

Arathorn49• 3 years ago

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 deployments without routing a single $ to support development at either the Matrix Foundation or Element, such are the joys of the Apache license.

As a result, we’ve had to pause some of the longer-term R&D. I very much hope that P2P will resume (especially if someone explicitly funds it) and the team is still at Element (but working on sliding sync and account portability). But right now we’re focusing exclusively on fixing the core problems in both Matrix and Element which others in this thread are complaining about. Hence Matrix 2.0, and Element X.

brunoqc2• 3 years ago

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 will the world be in 4 years? Not that it's your fault.

And I care about matrix. I was the one who suggested arewep2pyet.com, I made 1-2 friends use it (matrix), I made 1-2 coworkers use it.

Also, zulip threads now or I riot.

beardog• 3 years ago

Makes me sad that billions got poured into cryptocurrency-sphere projects but classic p2p barely scrapes by.

(I mean by society not new vector)

panick21_5• 3 years ago

Its probably the right choice if yo don't have the funds. But it s great that that team is working on account portability. That would be useful in a p2p world anyway.

Really hoping Full Matrix p2p will happen. Its would be such a cool capability.

Governments wasting so much time and money on so much nonsense software but we can't support and open communication tool.

gwd2• 3 years ago

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 we can; but not on the order of $250/mo (which if I'm reading it right, looks like the cheapest product on element.io -- $5/user/mo, min 50 users). If matrix.org accepts donations, it's not at all clear from your website.

snvzz3• 3 years ago

eg LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many German local authorities

This is extremely sad. They're large tax-funded organizations and should definitely contribute to priorize the needs they definitely have.

Ironically, there might be voices pushing for a move to a proprietary solution they would actually have to pay to use, and have much less control over.

ezst9• 3 years ago

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.

Arathorn49• 3 years ago

Hey, sorry that you got bitten; it must have been a catastrophic problem judging by how upset your comments are. If XMPP does what you need then I’m genuinely glad for you :)

smashah3• 3 years ago

Matrix is great but when is the tech industry going to deal with the fact that many, if not all, bridges are against the respective services' ToS and subsequently put the developers of those bridges under legal risk? Whatsapp has already sent legal threats to multiple bridge-component level project maintainers without any recourse.

amstan4• 3 years ago

My Facebook bridge constantly locks up my account. [1]

[1] https://github.com/mautrix/facebook/issues/236

smashah3• 3 years ago

I strongly believe users should be able to automate and interact with their accounts through whatever clients they wish however I think blocks/bans/technical countermeasures is fair game.

Count yourself lucky for not having an undeterminable, unfightable legal threat over your head from a $800bn mega corp.

derin2• 3 years ago

You should use your bridge off of a residential IP in the same city as your other devices, or else Facebook finds the activity suspicious.

progval3• 3 years ago

The EU just designated Whatsapp as a gatekeeper under the Digital Markets Act: https://ec.europa.eu/commission/presscorner/detail/en/ip_23_... following the "full list of do's and don'ts" link on that page:

Gatekeeper platforms will have to:
- allow third parties to inter-operate with the gatekeeper’s own services in certain specific situations
- allow their business users to access the data that they generate in their use of the gatekeeper’s platform

unicornporn2• 3 years ago

This is likely also the sole reason[1] that Meta is considering connecting Threads to the fediverse.

[1] https://yiffit.net/comment/498225

stavros2• 3 years ago

There's a fair amount of silly legislation that gets passed in the EU, but forward-thinking (or maybe just here-thinking?) laws like these (and the GDPR!) make me glad I live here.

smashah3• 3 years ago

I'm aware of DMAs regs but it forces Whatsapp within 6 months to start enabling interoperability. However it doesn't provide protection for these existing bridge projects.

open-wa, Baileys, invidious devs are all in the dark as to whether or not they're Scott free from their respective C&Ds due to this legislation.

robert_foss• 3 years ago

The EU interoperability mandate for messaging services will surely improve this situation.

lousken2• 3 years ago

Rather than exposing a kitchen sink of features and settings, we’re keeping Element X truly focused: doing one job and absolutely nailing it - all while harnessing the power of Matrix for secure, interoperable, open-standard communication.

does this mean the Element X is more for the mainstream user and regular Element is better suited for power users?

Arathorn49• 3 years ago

Element X also is geared up for powerusers (e.g. as project lead, I consider myself a poweruser) and i've been absolutely loving it as my daily driver for the last few months on mobile. For instance, my account is in around 4,000 chatrooms, and Element iOS was taking ~10s to launch and sync, and could easily take minutes to sync in the morning (heaven forbid the app was offline for more than overnight). Meanwhile, Element X launches in around 100ms, no matter how long it's been offline, and syncs in around a second.

The model that we're going for is similar to iOS or macOS: something which is incredibly simple for normal users, but can also scale up seamlessly for crazy powerusers.

In terms of specific poweruser features: I suspect the strategy will be to see if we can provide the same end result without actually adding the feature - and failing that, add the feature very strategically via progressive disclosure... or perhaps not at all, and rely on other Matrix apps to pick it up.

The intention is to fairly rapidly replace regular Element on mobile with Element X, eitherway.

lousken2• 3 years ago

Ok, I understand... one last thing I ask every year - custom emojis when? :)

And thank you for your the hard work!

solarkraft2• 3 years ago

I'm really glad you're aware and trying to get in control of the UX paper cuts that sum up quickly.

Telegram has been adding a ton of features during the last 5 years, all while keeping the core experience pretty much the same (fast and seamless). Whatsapp is also doing this.

With some UX Design chops, you should be able to do it.

infogulch3• 3 years ago

I wrote a summary of the post: https://twitter.com/infogulch/status/1704933396508553385

rebolek• 3 years ago

The future of Matrix is robots and people as batteries.

preya2k3• 3 years ago

Once more, Kudos to Arathorn/Matthew (the head of Matrix/Element) taking the time to answer most Hacker News comments, as he mostly does for all Matrix-related HN threads.

It's really nice to see him answer in a calm and mostly objective tone while people are blaming him for shortcomings and problems of all the different Matrix-related software projects. Admitting to failures and problems that Matrix definitely has, while still defending the overall project and giving insight into the status of MSCs/projects is admirable.

Thank you Matthew. I wish you an endless amount of patience for the future.

Arathorn49• 3 years ago

thanks :) sorry for monopolising the thread, but it's too tempting when I have the answers to hand, for better or worse...

preya2k3• 3 years ago

Looking forward to your talk tomorrow in Berlin.

teawrecks• 3 years ago

I'm curious if someone could build a discord replacement on top of matrix, most importantly with voice chat and video streaming functionality. Discord is clearly focused on monetization at this point, the only changes happening now are ones that make your experience objectively worse. I've also been on Linux for a few years now and discord still doesn't support streaming game audio.

And before someone suggests it, I tried Revolt, and it's not there yet. The latest client (as of a few months ago) couldn't find my audio devices at all, and came with a big warning about how their audio backend was being completely rewritten, and what I was using was now legacy.

Arathorn49• 3 years ago

Absolutely. Element is already quite close to that, and once Element Call and native Matrix group VoIP matures more, hopefully it'll be even easier to converge on Discord's featureset.

whiterock2• 3 years ago

my biggest struggle with matrix, is that, at least in element-ios, messages keep transpositioning, i.e. at some random time a message that is 2 days old is pushed all the way down to the new messages. also the aop frequently crashes with some media.

but apart from that I of course love the idea of an „SMTP approach“ to instant messaging :)

Arathorn49• 3 years ago

this is literally why we rewrote element-ios in rust, in the form of Element X iOS :) https://element.io/labs/element-x

whiterock2• 3 years ago

oh that‘s so cool. will give it a try now! :) really looking forward to the search feature btw hehe.

tentacleuno• 3 years ago

Why not fix the issues with the current implementation as well as rewriting it?

chamik• 3 years ago

This is an amazing step in the right direction. I host a small conduit server for a friend group and I can't wait for the improvements this will bring as a whole!

Good work.

noname120• 3 years ago

Oh wow congrats to the entire team for this amazing achievement! And the cake under the cherry is… Element X is open-source as well[1][2]!

I really can't wait for Beeper[3] to rebuild their fork on top of Element X (it's currently based on Element, formerly called Riot). When this happens it will be an absolute game-changer for the messaging ecosystem.

————

[1] https://github.com/vector-im/element-x-ios

[2] https://github.com/vector-im/element-x-android

[3] https://www.beeper.com/

Arathorn49• 3 years ago

Beeper don't seem to like Sliding Sync, for whatever reason, so I wouldn't hold your breath on it ;)

16• 3 years ago

From what I understand, the Beeper team has invested a lot of time and effort (and code!) into their own "make matrix go vroom" solution which also benefits their complex bridging system, and I imagine it would take some significant engineering time to unravel it for sliding sync.

notsahil• 3 years ago

Synapse already eats up lots of space, adding sliding sync will boost it up and will be difficult to self-host it.

Arathorn49• 3 years ago

Yup, it's true that sliding sync proxy increases disk space further, although it's not so bad. A big advantage once it's stable and merged into a native homeserver will be reducing the storage duplication between the proxy and the HS.

Meanwhile, we really need to get https://github.com/matrix-org/rust-synapse-compress-state/pu... hooked up in Synapse so that it automatically compresses state; I don't know why this never landed when it was written in in 2021 :(

COGlory• 3 years ago

I just went through a HUGE pain in the ass with my homeserver. I was on the Hetzner cloud plan and at the highest storage tier already. I had about 80 GB free, and setup sliding sync. It filled up the remaining space (unbeknownst to me) and my homeserver stopped working. Fortunately I was still able to login, but no disk space was available for the Postgres vacuum. I wound up having to rsync everything over to my desktop, setting up Docker on my desktop, running the compression tools on my desktop, and re-uploading. I now have a 20GB dummy file on that server.

wkat42424• 3 years ago

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.

Arathorn49• 3 years ago

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)

wkat42424• 3 years ago

Ah ok no I don't have a Mac, I use FreeBSD :)

And thanks I'll try that out!! I really hope it fixes that sync bug. Thanks for all your work on it. It's a great platform.

Macha2• 3 years ago

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?

wkat42424• 3 years ago

Unfortunately it won't connect. I have a home server that I connect to through VPN (not reachable online and with a self signed certificate). The old element asked me to allow the self signed CA but element X says it can't connect. I wonder if this is by design?

Getting a let's encrypt cert is very difficult because my server can't get reached from the public internet. I have it that way because I use this one only for bridging and I'd like to keep it safe.

fladd• 3 years ago

Yes, I was also surprised that the new features are only for phones. I guess aiming to be "better" than other chat apps (with the others nowadays being Whatsapp and co) means to be "mobile first"... sigh

monlockandkey• 3 years ago

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?

ezst9• 3 years ago

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

tcfhgj• 3 years ago

You could use the matrix-js-sdk or matrix-rust-sdk if you want to deal with wasm

Arathorn49• 3 years ago

https://github.com/vector-im/hydrogen-web/blob/master/doc/SD... is the best option currently.

iptq• 3 years ago

exciting to hear! I only wish i had more time to contribute.

Has there been any movement on migrating away from long polling (#475)? I didn't see anything about it in the announcements or comments despite such a big milestone

Arathorn49• 3 years ago

Low Bandwidth Matrix is the answer to that, and it’s currently on hold unless it gets funded: https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i...

It might also get changed as part of Sliding Sync refinement.

xvilka• 3 years ago

Hopefully it will be the default once implemented. Everyone will benefit from compact protocol in the long run. Should have been done from the very beginning.

snvzz3• 3 years ago

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.

benatkin• 3 years ago

Looks like there's an open protocol and an open source client implementation for video calls. https://github.com/vector-im/element-call

This is great! Jitsi has never clicked for me. I tried it a few times, and read about it, and was never excited about it. I just tried Element Call, albeit an empty room, and the UI feels right.

dmix• 3 years ago

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

reducible• 3 years ago

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

sfink• 3 years ago

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 very slow responses on Slack, and then switch mainly over to Matrix to talk to the rest of us.

It's been good to us. Note that our primary comparison point is IRC, not Slack, mainly because of our project roots of openness and widely distributed contributors. So it's a serious workplace, but an atypical one. Encryption has periodically caused problems. Leaving the company and maintaining access to your communication seems to be a bit painful. Search is not great. Threads are tolerable. Inviting outside people in works well. Abuse is vastly more manageable than it was on IRC. Performance is mostly good. Both Element Web and Element on Android are very usable. Notifications are a little wonky, but I don't rely on them much so I can't really gauge whether they're good enough if you do.

progval3• 3 years ago

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?

LWIRVoltage• 3 years ago

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.

astroderf• 3 years ago

Can this perennial scam get off the front page already. ffs.

Ilikeruby• 3 years ago

I see Decentrilised and I see secure and I see a scam

yobid202• 3 years ago

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.

Arathorn49• 3 years ago

Using Matrix would mean:

* You get best practice audited (in the near future) end-to-end encryption

* You get decentralisation if your users want to host the stack themselves

* You get bridges to other systems (although not many FOSS voip bridges for Matrix exist today, admittedly)

* Similarly, you get an open standard API on which you and others can write bots/apps and other extensions to add new functionality, and benefit from the wider ecosystem

* You get some preexisting clients like Element Call to build on.

yobid202• 3 years ago

Well, we dont want e2ee because then we cant decode audio and transcribe, or record meetings. All of which are high demand user requirements. We dont want decentralisation either for the same reason. We dont interop with other video conference systems other than asterisk for dial in/out. And the ones that we might consider doing that for dont support matrix either. We want a fully integrated system for our users so i dont see external clients being a thing. An open standard api is a plus but in my experience there's always something they fall short on requiring something custom. This is why i find it difficult to see where matrix could improve anything for us. Trying to find some benefit but I really don't think there is one other than maybe marketing and saying we play nice with open source or open standards.

czard• 3 years ago

Honestly what's the point given XMPP? Tried setting up Matrix, was a pain, went for ejabberd and it was a breeze. Gajim and c0nnecteasy work perfectly. Can't help but feel like if half the efforts of building Matrix went into XEPs or something we would have a rock solid IM alternative and clients by now. And tbf, can Matrix do group video calls? That's the only really useful feature missing from XMPP now, for which there's actually a XEP that recently went into a Deferred state, for a lack of participation/experiment. So, what's the point?

Arathorn49• 3 years ago

the original post has a full section about Matrix’s support for E2EE group video calls, which you can play with at https://call.element.io. This, and much more, is the point.

zaik• 3 years ago

Dino the XMPP client can do group video calls.

Matrix 2.0: The Future of Matrix

Related Stories