[HN Gopher] Matrix 2.0 Is Here
___________________________________________________________________
Matrix 2.0 Is Here
Author : ptman
Score : 226 points
Date : 2024-11-03 11:09 UTC (11 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| gnabgib wrote:
| Previously (42 points)
| https://news.ycombinator.com/item?id=41987113
| robcohen wrote:
| Congratulations to the Matrix team. I look forward to trying out
| everything this release offers and seeing how I can implement in
| the organizations I work with.
| lousken wrote:
| i hope after the transition is done, there will be a focus on
| multiplatform e2e search, attachment tab improvements (it's fine
| for < 10 attachments in a chat, but not a 1000), optimized
| notification system so friends stop bug me with it, and of course
| custom emojis
| sroerick wrote:
| Does Matrix still sync all metadata with all connected federated
| instances?
| panick21_ wrote:
| Its room based. Each room is synced between all servers used by
| participating members. But if you have a room with only people
| from 1 server, that metadata stays on that server.
| johnisgood wrote:
| Is it possible to configure this so that the metadata remains
| on the server by restricting access to only those users who
| are not members of any other servers?
| Arcuru wrote:
| I don't think there's a setting for "only allow people from
| X server", but you can make the room private and only
| invite people from that particular server.
| alwayslikethis wrote:
| You can disallow users from joining based on their
| homeserver or only allow local (on your homeserver) users,
| so the answer is yes.
| Ugzuzg wrote:
| While creating a room, you can choose to "Block anyone not
| part of your server from ever joining this room".
| ranger_danger wrote:
| It's not about being a member of a room on another server,
| but the homeserver of the account itself, of all the
| members of the room, must be local to that same server as
| the one that created the room in the first place.
| stackskipton wrote:
| Is it possible with Matrix to run your own server but let
| Matrix.org handle authentication? I always thought for many
| that's probably best of both worlds.
| alwayslikethis wrote:
| What benefits does this have? You'll still have to have a
| server running and you lose control of your account, if I'm
| understanding what you mean (letting matrix.org handle
| accounts).
| stackskipton wrote:
| User friction. My problem is this: I'm in a bunch of Discord
| Server/Guilds but watching Discord Inc., it's clear that they
| are ZIRP powered and it might come crashing down in massive
| fireball. However, if users have 5 separate logins, they are
| not going to convert over.
|
| I realize the implications of "What happens if you get
| Matrix.org account banned?" but that's next week problem.
| tucnak wrote:
| I'm a big fan of Matrix, but I'm embarrassed to recommend it to
| my friends until Element X supports audio calls... It's been
| months since the leading-edge release, and I don't know what to
| think: there's Element Call, however it's neither supported by
| Element X nor real alternative to legacy peer-to-peer audio
| calls.
| Arcuru wrote:
| Element X doesn't even support Threads or Spaces still, the two
| things that are absolutely required to organize discussions.
| Arathorn wrote:
| Element X natively integrates Element Call for voip/video calls
| - this is one of the core things of this week's release. If you
| hit the video call button, it'll start off with video muted,
| and it should behave like a voice call (although there are a
| few bugs in the integration still, hence it being marked beta -
| especially on iOS, where CallKit + WebRTC stopped working in
| iOS 18. We're trying to work with Apple on it.)
| error_404_302 wrote:
| Unfortunately, that is not the case yet on Element X android
| (0.7.2 from google playstore). Microphone starts off as muted
| which is an inconvenience.
| aniviacat wrote:
| What do you mean by audio calls? I haven't used Element X yet,
| but judging from the store screenshots you can turn off the
| camera in video calls.
| EVa5I7bHFq9mnYK wrote:
| Don't know about Element X, but Element supports voice calls
| very well.
| johnisgood wrote:
| > Could it be the glorious return of P2P Matrix (if it was
| funded)?
|
| I forgot how it works right now, but I certainly would hope so in
| case of private messages (incl. P2P encrypted audio and video
| calls).
| Arathorn wrote:
| P2P Matrix is a dialect of Matrix where the server runs inside
| the client itself - see arewep2pyet.com for details. In other
| words, there are no servers (other than optional store-and-
| forward relays). It's insanely cool - you can see a demo at
| https://www.youtube.com/watch?v=eUPJ9zFV5IE&t=2192s. It's also
| unfunded and on hiatus until someone provides some $ so we can
| work on it again.
|
| Right now, normal Matrix is a client-server model: you can't
| send messages from a client without it talking to a server (and
| then to another server, and then to another client). MatrixRTC
| VoIP and Video calls in Matrix 2.0 also go via server (for
| now), in order to support multiple participants and firewall
| traversal.
|
| Obviously, both messages and calls are end-to-end-encrypted
| (other than in public chatrooms), which makes it less important
| that they go via a server today.
| johnisgood wrote:
| Thank you for your answer.
|
| > It's also unfunded and on hiatus until someone provides
| some $ so we can work on it again
|
| What are the available ways for someone to provide funding?
| Arathorn wrote:
| https://matrix.org/membership/ is how best to support - or
| buy stuff from organisations who support the Foundation.
| P2P Matrix requires a 3-4 person team to progress
| constructively (rather than limping along on a shoestring),
| which means $$$K/y over and above the current funding
| targets: https://matrix.org/blog/2024/01/2024-roadmap-and-
| fundraiser/
| prmoustache wrote:
| Why wouldn't you use Jami instead of Matrix if you are
| interested in a p2p solution?
| 3np wrote:
| I'm sure there is p2p funding available on the sidelines.
| Give us an actual opportunity to privately sponsor it.
|
| I am sure you have heard the dismay of people who would like
| to sponsor Firefox but only really have the option to finance
| the Mozilla Foundation, who put the money elsewhere? Some
| similar feelings here.
| Arathorn wrote:
| Unlike the Mozilla Foundation, if someone came to Element
| (or the Matrix Foundation) with a large bag of $ and asked
| for it to specifically fund P2P, then a conversation could
| definitely be had.
| alwayslikethis wrote:
| If you want to host a homeserver but feel overwhelmed about the
| amount of services you'll have to host (especially if you want to
| have bridges to other services), check out matrix-docker-ansible-
| deploy [1]. It's pretty much a set and forget experience with
| reproducible deployment, and the documentation walks through any
| decision you need to make.
|
| 1. https://github.com/spantaleev/matrix-docker-ansible-deploy
| Arathorn wrote:
| Ironically i just spent all weekend writing a new "quick start"
| guide for Matrix 2.0 deployments using docker-compose (so you
| literally just set some env variables, `docker compose up` and
| that's it; no ansible involved). I just shifted to the
| debugging phase, but once it's ready, it might be even easier
| than matrix-docker-ansible-deploy as a super-fast way to get
| started :)
| alwayslikethis wrote:
| I'd say the primary benefit of ansible is it makes you
| document everything. It's easy to simply set and forget with
| tools like docker compose, but then when you need to change
| something again, you have to recall what you did originally
| and fix that.
| Arathorn wrote:
| yup, although i'm hoping that a self-contained docker-
| compose repo that you don't need to edit will help with
| that (rather than it being a homespun docker-compose setup,
| which i agree can rapidly become unmanageable).
|
| ansible just feels a bit slow & cumbersome for simpler
| setups, so i'm using envsubst for basic templating to see
| how it feels. It's perhaps telling that something like
| Rocket.Chat just has `docker-compose up` too:
| https://docs.rocket.chat/v1/docs/deploy-with-docker-
| docker-c... and it's annoying that Matrix doesn't have
| something that simple (especially given Matrix 2.0 has more
| moving parts serverside: auth + voip server).
| neets wrote:
| Please share the code here
| Arathorn wrote:
| well, yes - just let me finish writing it first ;P
| EasyMark wrote:
| can you give it a codename that's not impossible to remember
| if you do add such a docker? something that is likely I'll be
| able to remember it in a couple of months?
| Arathorn wrote:
| repo's currently called element-quick-start (given i'm
| doing it with my Element hat on to showcase EW+EX+EC as
| much as the Matrix 2.0 backend)
| ranger_danger wrote:
| > If you want to host a homeserver but feel overwhelmed
|
| I feel overwhelmed at the number of options there are in this
| ansible thing. Now I definitely don't want to try it either
| way.
| urda wrote:
| I haven't tried them, but I've seen https://etke.cc/ suggested
| for dealing with a group who will "host" the server.
| aine wrote:
| at the same time, we are developing MDAD playbook, referenced
| in https://news.ycombinator.com/item?id=42034100
|
| I'm Aine of etke.cc, and yes, we can ease your pain by
| managing the server part of the matrix on your behalf, be it
| on-premises or hosted in the cloud by us.
| aine wrote:
| Alternatively, you can just get your server managed by
| https://etke.cc - the developers of the MDAD paybook - and not
| worry about the server part at all
|
| Disclaimer: I'm Aine of etke.cc
| bhauer wrote:
| Previously, it seemed the sliding sync required a Postgres-backed
| Synapse installation. Does the Matrix 2.0 version of Synapse
| provide a seamless upgrade path for those using the default
| Sqlite installation?
| Arathorn wrote:
| Yes. the sliding sync proxy shim is gone; Synapse now uses its
| native database for sliding sync, same as the old sync API - so
| it works with both postgres & sqlite.
| _flux wrote:
| By the way, Sqlite should only to be used when testing, not
| when actually deploying a system that interacts with other
| systems. https://element-
| hq.github.io/synapse/latest/setup/installati... says as much.
| 01HNNWZ0MV43FF wrote:
| Does this change anything for notifications? I've had to pause
| using Matrix (self-hosted Synapse plus Schidichat for Android
| after Element had the same issues) to talk to my friends because
| we routinely get shit like:
|
| - Message is sent to the server but nobody else's phone gets
| notified about it for minutes / hours
|
| - Message just can't be sent to the server even though the
| sending phone has Internet and a desktop web client on the same
| account works great
| Arathorn wrote:
| If the problems were caused by issues in the old Element
| Android (or Schildichat) app then yes - the Element X rewrite
| will likely fix it. It supports UnifiedPush, so if you're self-
| hosting a push gateway it should nicely integrate (as does
| Schildichat Next).
|
| If the problem was in your push infrastructure, then the new
| app won't fix anything - however, UnifiedPush should be
| reliable these days (especially if you host your own instance;
| some of the shared ones are overloaded and/or deliberately
| throttle Matrix push). FCM obviously should be reliable too.
| _peeley wrote:
| Very exciting! I'm particularly pleased to see the invisible
| encryption stuff mentioned.
|
| One of the biggest pain points I had when setting up a self-
| hosted Matrix instance and getting all my devices signed in was
| the crypto stuff. At least in the client I use, Element, I was
| bombarded with tons of popups with vague "Upgrade your
| encryption!" prompts upon logging in the first time. The
| copywriting on the "Security & Privacy" page was less than
| helpful in illuminating what I was actually "upgrading" or
| setting up, since specific technical terms (e.g. recovery
| key/security phrase/security key) were all used more or less
| interchangeably. If that kind of confusion can be reduced or
| swept under the rug for end-users, it'd be a huge improvement on
| user experience.
| Arathorn wrote:
| Yup. One of the biggest learnings of E2EE in Matrix is that the
| complexity is 95% user experience. However, in Element X, we've
| been determined to get it right - although there is still some
| temporary UX in there while full-blown Invisible Crypto is
| still rolling out (as it requires a breaking change to stop
| encrypting/decrypting with unsigned devices - the equivalent to
| a browser refusing to talk TLS to self-signed certs).
|
| If you haven't seen MSC4161 (https://github.com/matrix-
| org/matrix-spec-proposals/blob/and...) i highly recommend it as
| evidence of how we've made a serious effort to fix the
| terminology and copy - not just for Element X but across all
| Matrix clients.
| zorgmonkey wrote:
| Standardized terminology is an awesome step. I'd love to see
| some of standardized file format for setting up the right
| keys on different devices. In the past I'd had annoying
| issues getting all the messages to decrypt on multiple
| devices, especially if I wasn't using the same client every
| device. Honestly though I suspect I was doing something
| wrong.
| Arathorn wrote:
| there's already a standardised export format for message
| keys (although EX doesn't let you load/save it yet, mainly
| because online backup already solves most use cases):
| https://spec.matrix.org/v1.12/client-server-api/#key-
| export-.... If you enable backup on your clients then EX at
| least will merge the missing keys to/from the backup.
| Meanwhile, the original problem of missing keys were
| probably unfortunately just due to bugs - although as per
| https://matrix.org/blog/2024/10/29/matrix-2.0-is-
| here/#4-inv... we've done a huge amount of work to improve
| this now, and they should be really unusual now (at least
| when due to bugs, rather than permissions or data loss or
| similar).
|
| Separately, talking of standardised key formats: one of the
| team did a skunkworks hack last Friday to experiment with a
| standardized file-format for user public keys - a kind of
| basic key transparency ledger for Matrix, to help with
| bulk-verification within orgs.
| dimal wrote:
| Off topic but I love the YouTube player interface. Instead of
| loading it by default (and adding invasive Google tracking to the
| page), you get the option to opt in. Very nice.
| birb07 wrote:
| hosting such videos on YouTube alternatives (even federated
| once) would be even better. I.e Blender has a peertube instance
| video.blender.org
| wut42 wrote:
| Not really. this can be avoided entirely by embedding with
| youtube-nocookie.com instead of this weird dance and
| youtube.com.
|
| https://support.google.com/youtube/answer/171780?hl=en#zippy...
| evbogue wrote:
| Related: Matrix 2.0: The Future of Matrix -->
| https://news.ycombinator.com/item?id=37599510
| superkuh wrote:
| >Native Matrix Encrypted Multiparty VoIP/Video (aka MatrixRTC,
| MSC4143)
|
| Excellent. This is basically my only use for Matrix because
| encrypted video chats, 1-to-1, and now many-to-many (YES!) are
| the only thing Matrix does better than IRC. I started using
| Matrix video chat to talk to family during the early pandemic and
| sort of got used to it.
| udev4096 wrote:
| I wrote an easy to follow guide for hosting matrix a while back:
| https://hcrypt.net/synapse.html
| fluorinerocket wrote:
| Disappointed this ain't about linear algebra
| _aavaa_ wrote:
| Their main, and default client, still doesn't support multiple
| accounts. It's been years
| vaylian wrote:
| They are very much aware of that missing feature, but there are
| currently other things that have higher priority.
| bhaney wrote:
| > now focusing on making Matrix fast, usable and mainstream-ready
| with Matrix 2.0
|
| Feels like all of those things should have been the focus of 1.0,
| no?
| Arathorn wrote:
| nah, 1.0 was getting it out of beta and making it work at all.
| 2.0 has been all about making it work fast and mainstream-
| ready. https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
| IanCal wrote:
| Does synapse support this at the moment? I can't quite tell from
| the writing here if/how you can run things that support this - my
| guess was no because it mentions improvements to the js SDK are
| required and there's no warning on the synapse repo. Or is that
| just that these features are opt-in?
| Arathorn wrote:
| Synapse now has native support for sliding sync (the new
| "instant sync" Matrix 2.0 API, implemented in Element X and
| other rust-sdk clients like iamb - Element Web has it in labs).
|
| The other bits of Matrix 2.0 require new moving parts: matrix-
| authentication-service to support next-gen auth (although this
| will eventually get optionally embedded inside Synapse), and
| livekit for VoIP. Finally, invisible crypto is purely spec &
| client-side improvements.
|
| As per https://news.ycombinator.com/item?id=42034324 i'm
| currently frantically writing a compose.yml to show how they
| plug together, while kicking myself for not having arranged one
| sooner...
| IanCal wrote:
| That's fantastic thanks - the sliding sync part addresses an
| issue a client I've got would be facing at some point. I'll
| have to check out the details of that.
| pkulak wrote:
| I'm maintaining a Matrix TUI and I haven't updated it in forever
| because I keep saying I'm going to wait for the next stable Rust
| SDK... but I just keep waiting. Anyone know if that is planned,
| because without a stable release, packaging is a bit of a pain.
| Arathorn wrote:
| hm - i think it's just because they've been frantically
| building and haven't time to release. looks like 0.7.1 was the
| most recent release in Jan; will give them a prod. sorry.
| andrewaylett wrote:
| I've had Element X installed for a while -- couldn't use it for a
| while after EMS shut down their small instances and I started
| self-hosting, but it works with my self-hosted Synapse now.
|
| The only problem is that it's got too many paper cuts. I can live
| without Spaces, even though I use them on Desktop. But
| notification channels are a harder sell, and missing avatars on
| notifications is just annoying. Neither are exactly core
| features, but notifications are the most common way I interact
| with Element on mobile and for me, the improvements (and there
| are many) aren't worth the downsides.
| Arathorn wrote:
| > But notification channels are a harder sell, and missing
| avatars on notifications is just annoying.
|
| huh. on Element X iOS, the notif support is genuinely great -
| you get avatars and groupings and reliable notifs on e2ee msgs.
| the only thing is missing is quick-reply (which has been
| blocked behind full multi-process support in matrix-rust-sdk,
| hopefully coming soon).
|
| I'd assumed that Element X Android would be the same; if not,
| it's an omission and will get fixed.
| tredre3 wrote:
| > I'd assumed that Element X Android would be the same; if
| not, it's an omission and will get fixed.
|
| Aren't you Element's CTO? I feel like you shouldn't need to
| make assumptions into how the app works, you should just know
| (even if you're not personally daily driving it). If not you,
| is anyone in charge of ensuring that the project's vision and
| goals are met?
| Arathorn wrote:
| yup, i'm the CTO, and I don't have notifs enabled on
| Android and so hadn't checked - I daily-drive iOS. The
| folks "in charge of ensuring the project's vision and goals
| are met" are the ones running the Element X team - sorry
| that I haven't memorised the full feature parity matrix :)
| Sounds like https://github.com/element-hq/element-x-
| android/issues/1547 is the bug for you to upvote &
| subscribe to.
| t0bia_s wrote:
| Does it help with laggy Element?
| jeltz wrote:
| Yes, it will help with some of those issues.
| jeltz wrote:
| Are there any plan for improving the desktop version of Element?
| E.g. by porting Element X to the desktop. Or should I look for
| other Matrix clients? I feel the Element team with their limited
| resources sadly cannot keep Element Desktop in the shape it needs
| to be to be a great client.
| shmerl wrote:
| Browser version works well?
| jeltz wrote:
| No idea, I do not use it. I generally do not like using
| browser versions of e.g. IM clients.
| daedric7 wrote:
| Eventually attentions will turn to Element Web/Desktop.
|
| For now the magic is happening in the background, SDKs etc.
| Arathorn wrote:
| Yup. On macOS you can use the iOS build of EX already today (i
| daily drive it, and it's very usable). Meanwhile, I built an
| unreleased prototype of a possible EX Desktop which uses Tauri
| + matrix-rust-sdk (codenamed aurora) - weirdly enough it feels
| almost identical to Element X iOS, which makes sense given all
| the heavy lifting in EX is matrix-rust-sdk.
|
| Separately to the aurora experiment, the Element Web/Desktop
| codebase itself is starting to move to a MVVM model to support
| swapping out the underlying SDK (e.g. for a WASMified matrix-
| rust-sdk) and avoid an Element X Mobile style rewrite. That
| said, making matrix-rust-sdk work on WASM is not trivial
| (especially if you want to avoid maintaining two different FFI
| layers for wasm-bindgen and uniffi).
|
| Another track is that matrix-js-sdk is also sprouting
| Simplified Sliding Sync support - I even demoed it in the
| Matrix 2.0 talk: https://youtu.be/ZiRYdqkzjDU?t=617. And it
| already has Next Gen Auth and Element Call support. So there's
| also a chance that "Element X Web/Desktop" just ends up being
| an evolution of the current codebase - I guess this is the
| default path right now.
|
| Finally, there are other clients built on matrix-rust-sdk -
| e.g. GNOME Fractal is shaping up to be an excellent fully
| native GTK4 Rust desktop client, and given it shares the same
| engine as Element X, is suspiciously similar in terms of
| capabilities and perf (although I can't remember if they've
| enabled sliding sync yet).
| https://gitlab.gnome.org/World/fractal
| iknowstuff wrote:
| Any plans for a mac catalyst version of element x?
|
| I recall Rust was a blocker for that a few years back, but
| after I fixed Rust's mac catalyst support to enable fat
| builds of matrix rust sdk for it, it turned out there was
| another blocking library.
|
| the UIKit app has weird scaling and doesn't have the nice
| macOS translucent sidebar/toolbar etc
| Arathorn wrote:
| So I did a catalyst build of EX a while back (which is
| where https://github.com/rust-lang/rust/issues/106021 came
| from) - but rather anticlimactically the end result looked
| almost identical to the normal iOS app when running under
| macOS; I don't remember the sidebar/toolbar looking
| particularly better, and that was my main reason for doing
| the build in the first place (to get a flexibly resizable
| left toolbar). The main advantage seemed to be that it
| would run on Intel.
|
| If things have improved I'd love to know, and then perhaps
| we'll have another shot at it. Are there any good
| comparison screenshots of the two approaches (with a toy
| app, i guess) anywhere?
| entrepy123 wrote:
| I agree that an amazing Desktop client would be great, and that
| most likely there's a need to prioritize where efforts go at
| the moment.
|
| For now, maybe check out Ferdium. AFAICT, it's just a wrapper
| app for web clients, but even this might solve some
| shortcomings of the official desktop app (e.g., cleaner usage
| of multiple profiles).
| elric wrote:
| Is Synapse still the only Matrix server implementation that is
| not in beta? The matrix.org site seems to suggest as much, but I
| don't know how up to date that is.
| Arathorn wrote:
| yes, unfortunately. Dendrite almost got out of beta, but (very
| frustratingly) we didn't have the $ to keep developing Synapse
| and Dendrite fulltime - so we consolidated on Synapse, given it
| was already mature and deployed everywhere, and are focused on
| rewriting the hot paths of Synapse in rust and generally
| improving Synapse's perf and scalability rather than
| maintaining both go and python servers.
|
| Meanwhile Dendrite is getting maintained best effort by the
| former team as time allows.
|
| Finally, the other main area of server dev right now is Conduit
| (conduit.rs) - a pure rust impl targeting small selfhosted
| servers. Conduit itself has slowed down recently but there are
| two very active forks: Conduwuit and Grapevine. All three are
| beta however.
| acheong08 wrote:
| It's unfortunate that dendrite is on life support. I've been
| using it for a long time to contact family in countries with
| high censorship.
|
| I want to migrate to conduit or a fork of it but can't find
| any docs on how to do that. Would rather not spin up a server
| from scratch as breaking existing accounts would mean a
| complete loss of contact with some people that would need
| assistance to even sign up.
|
| Of course, I'm not switching just for the sake of it. I've
| had a ton of bugs with dendrite suddenly taking up gigabytes
| of memory when federating (turned the feature off) and
| somewhat random crashes
| xyst wrote:
| > Next Generation Auth (aka Native OIDC, MSC3861)
|
| Huge for me. I run my own IdP, mailserver and it's one less self
| hosted service that I need to manage credentials for
| wut42 wrote:
| oidc was already possible before and was very easy to setup.
| this change seems to be more about the internals of matrix
| auth.
| raggi wrote:
| Have the new security and encryption features received review?
| Arathorn wrote:
| they haven't had formal independent review yet, but we will get
| them audited. there are relatively few changes in practice
| though other than fixing bugs, removing confusing UX and adding
| the beginnings of TOFU. Off the top of my head it's only TOFU
| which would need new review.
___________________________________________________________________
(page generated 2024-11-03 23:01 UTC)