[HN Gopher] Matrix.org Will Migrate to MAS
___________________________________________________________________
Matrix.org Will Migrate to MAS
Author : LorenDB
Score : 118 points
Date : 2025-04-02 16:28 UTC (6 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| apetresc wrote:
| I vaguely remember an old MSC or TWIM or something that described
| (the possibility of) a new authentication mechanism whereby I
| could set up either a dummy homeserver or something in
| .well_known that would allow me to use my own domain but
| _without_ needing to use my own homeserver for the actual
| traffic. Sort of like an auth-only homeserver, if you will.
|
| Is that part of MAS? Was that initiative ever fully-baked? Or am
| I just misremembering?
| MartijnBraam wrote:
| Afaik that's not related to this, that was already possible as
| a domain alias. I think that feature is called a delegation if
| I remember correctly.
| Arathorn wrote:
| That's .well-known based delegation, which was proposed in
| MSC1708 in Nov 2017: https://github.com/matrix-org/matrix-spec-
| proposals/blob/old... and merged into the spec in Jan 2019
| (prior to Matrix 1.0 in June 2019): https://github.com/matrix-
| org/matrix-spec/commit/0347e873efc...
|
| So yes, fully-baked and part of Matrix since 1.0!
|
| Next Gen Auth via OIDC is instead a key part of the (upcoming)
| Matrix 2.0 spec release - see https://areweoidcyet.com and
| https://github.com/matrix-org/matrix-spec-proposals/pull/386...
| jckahn wrote:
| Cool! I've recently consolidated all of my Google Chat and
| WhatsApp friends onto Matrix (via Element) because it's E2EE.
| Gchat isn't and I assume that Meta has a backdoor into WhatsApp
| conversations. So, those platforms can't be trusted. Signal
| doesn't have a web interface, so that's a no-go for me. lol
| Telegram.
|
| Matrix has been great for me and I recommend that everyone else
| use it!
| Steltek wrote:
| Self-hosted Matrix with all the bridges is awesome and brings
| back that Pidgin/Adium life of one chat app for all of my
| friends. Too bad Apple has an uncanny ability to avoid
| consequences with iMessage.
| nisa wrote:
| It's wonderful that it seems work well for you but my
| experience in bridging group chats with XMPP or IRC was
| terrible. Lost messages, bridge crashes, puppet accounts
| getting randomly broken/duplicated with discarded messages.
|
| From the bridges I've run, only the Telegram bridge is
| somewhat stable for me but it also has it's warts.
|
| Might be different if you run a strictly personal server for
| 1:1 conversations but I'd say from an ux perspective the
| bridges idea largely failed IMHO.
|
| I don't think it's the fault of element/matrix it's a
| difficult problem and I guess with limited resources they
| made a lot of progress and made things possible that weren't
| before but it's not plug and play, at least it wasn't for me.
|
| In general I've found it's also difficult to communicate in
| group chats if there are two worlds with a slightly different
| view (missing reactions, some elements of the messenger are
| not supported like captions, polls and so on...)
| kuon wrote:
| While I generally agree, the slidge bridge for XMPP has
| been working quite well for me, especially whatsapp, but it
| is really new.
| nisa wrote:
| > slidge bridge
|
| Didn't knew about this one. Thanks I'm looking into it!
| VladVladikoff wrote:
| >lol Telegram
|
| Did I miss something? what's wrong with telegram?
| celsoazevedo wrote:
| I assume it's the lack of end-to-end encryption by default on
| basic features.
|
| Good service btw, but not the best from a privacy point of
| view.
| jckahn wrote:
| This is exactly it.
| SahAssar wrote:
| Besides that there it's also them choosing to roll their
| own crypto instead of using established cyphers and
| protocols.
| emptysongglass wrote:
| And every time someone makes this comment. MTProto 2 uses
| standard crypto primitives. Besides this, do you know who
| else rolled their own crypto? Moxie. You don't get to
| roll your own crypto first and then weaponize this
| against your opponents but that's exactly what he did
| along with abusing words like "plaintext" to describe any
| encryption not E2EE.
| maqp wrote:
| AES-IGE is not best practice. Neither is this
| https://words.filippo.io/dispatches/telegram-ecdh/
|
| The difference is Moxie isn't an amateur when it comes to
| cryptographic design. Wikipedia actually lists him as a
| cryptographer. The company has also employed an actual
| mathematician/cryptographer, Trevor Perrin.
|
| Meanwhile, Telegram employed the CEO's brother who's a
| geometrician, which is not the same. You wouldn't hire a
| dentist to perform brain surgery even though both studied
| medicine.
|
| Signal protocol's double ratchet is considered best
| practice by pretty much every competent cryptographer.
|
| MTProto's main issues are not the teething issues of the
| yester-years. It's the fact every chat is sent to the
| server that can then read the messages. Telegram only has
| E2EE in internet debates about it's non-existent E2EE in
| practice.
| 4cstar wrote:
| https://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypted-
| by...
| celsoazevedo wrote:
| It's nice to see their reasoning, but the issue remains:
| Telegram can read most direct messages (because almost no
| one uses private chats) and everything sent in groups.
|
| It's a good service and in some cases it can compete with
| Matrix, Signal, etc, but most direct chats and all groups
| have no privacy from Telegram (and anyone with access to
| their servers).
| maqp wrote:
| https://telegra.ph/Why-you-should-stop-reading-Durovs-
| blog-p...
| Klonoar wrote:
| I'll tell you what's _right_ about Telegram: I don 't know
| how they're the only independent app that seems to be able to
| produce such a well built UI/UX for a chat application in
| 2025.
|
| I maintain that someone should fork their codebase and bolt
| on a different backend (Signal, Matrix, whatever). It's right
| there and it's very, very good.
|
| (Yes, I know it's not as simple as "bolt on a different
| backend". You know what I mean.)
| palata wrote:
| > I don't know how they're the only independent app that
| seems to be able to produce such a well built UI/UX for a
| chat application in 2025.
|
| Precisely because they don't spend so much effort for
| privacy. If your server can read all your messages, it's
| suddenly easier to provide great features. For instance,
| GMail can add your next hotel stay to your calendar
| automatically because it has access to your emails. That's
| great UX, but poor privacy.
| athenot wrote:
| This is not entirely true. For example, Calendar.app does
| the same by _locally_ extracting the .ics out of Mail.app
| without ever sending anything to Apple.
|
| I don't think Telegram's UX is tied to their permissive
| privacy, but they do seem to start with UX then do what's
| needed to support it. That does give them an edge.
| (Instagram has terrible privacy and actively mines
| information from chat and their UX is only passably
| good.)
| palata wrote:
| > This is not entirely true.
|
| My point is that it's generally harder to add those
| features in a privacy-preserving way. GMail couldn't do
| it if it couldn't read the content of the emails, period.
| It doesn't mean that there is no way to have nice
| features in a privacy-preserving way. I just said it's
| harder (sometimes impossible).
|
| > I don't think Telegram's UX is tied to their permissive
| privacy
|
| Not exclusively, but it is obviously a lot easier! Take a
| web client: if the server has access to the data, your
| client can just fetch it. If the server doesn't even know
| about the existence of the group, that's harder. Why do
| you think only the "secret chats" are E2EE in Telegram
| (and those don't support groups)?
|
| > then do what's needed to support it
|
| What do they do to support privacy? They don't have E2EE
| except in the secret chats! That hasn't changed in a
| decade!
|
| > Instagram has terrible privacy and actively mines
| information from chat and their UX is only passably good
|
| This keeps getting further from what I said :). Of
| course, it's possible to do worse than Telegram!
| Klonoar wrote:
| This is such an odd comment.
|
| What on earth makes you think that the same engineers
| responsible for fluid and smooth UI/UX are the ones who'd
| ever influence the cryptography/privacy/security? Whether
| or not the chats are encrypted has zero to do with this.
|
| Telegram has almost universally smooth scrolling, things
| work well across platforms, it's native pretty much
| everywhere with low memory usage and mostly platform
| specific behaviors. Signal half asses this, and Element
| is... shoddy, at best, in comparison.
| maqp wrote:
| Unless you're extremely privileged, privacy does play a
| role in every feature. There is no user experience if
| you're imprisoned for speaking your mind and your
| government intelligence has pwned Telegram servers.
|
| Making a smooth app isn't that hard. Inventing the
| cryptographic protocols to enable group management
| without server-side control, and proving their security
| is the hard part. Something Telegram's developers haven't
| the faintest idea of how to do.
| Klonoar wrote:
| > Unless you're extremely privileged, privacy does play a
| role in every feature.
|
| No, dude. Come on - you really think that plays a role in
| how smooth a listview renders? Or whether it follows the
| correct tab focus order? I don't think I could be more
| clear about what I'm saying in my last comment. Their
| client side app is incredibly smooth and well built.
| Signal, Element, etc do not stack up.
|
| > Making a smooth app isn't that hard.
|
| Yes, it surprisingly is. Multiple chat apps in 2025 still
| fail at this.
|
| > Inventing the cryptographic protocols to enable group
| management without server-side control, and proving their
| security is the hard part. Something Telegram's
| developers haven't the faintest idea of how to do.
|
| This isn't even in the realm of what my point was.
| palata wrote:
| > What on earth makes you think that the same engineers
| responsible for fluid and smooth UI/UX are the ones who'd
| ever influence the cryptography/privacy/security?
|
| Did you even read my comment? I gave an example of how
| privacy _directly_ impacts UX: GMail couldn 't
| automatically add your events to your calendar if it
| could not read the content of your emails. I never talked
| about engineers, just the technical reality. If you don't
| have it, you can't read it. That seemed absolutely
| obvious to me: the best UX for a car would be one that
| doesn't need a source of energy, fits in my pockets and
| instantly teleports me anywhere I want. Go ask your
| engineers to make a car that allows that perfect UX, and
| see how they react.
|
| Telegram has no E2EE except for the secret chats. Last
| time I checked, the secret chats were not synchronized
| between devices (i.e. the privacy has an obvious impact
| on the UX).
|
| So no, I don't think it was an odd comment. It just feels
| like you don't know how it works technically.
| Arathorn wrote:
| Telegram certainly has an excellent UI/UX. On the Element
| side, its quality bar has very much been the target for
| Element X - and (in my biased opinion) we are getting very
| close, if not exceeding it in some places. For instance, we
| just landed The Event Cache in Element X and matrix-rust-
| sdk (https://github.com/matrix-org/matrix-rust-
| sdk/issues/3280 - closed 2 days ago after a year of solid
| work), which provides seamless offline support and local
| encrypted-at-rest caching of the messages it's seen, which
| in turn then makes the native SwiftUI and jetpack-compose
| UIs go brrrrrr.
| Klonoar wrote:
| > its quality bar has very much been the target for
| Element X
|
| I sincerely hope you get there, but it's really hard to
| believe it at the moment. You're not even at feature
| parity with the app (Element vs Element X) you're
| replacing, and it's been out for a bit now.
|
| i.e, you have significant user experience related
| features that keep people using Element (open graph
| previews, just to name one).
| palata wrote:
| I don't understand why you're downvoted for this question.
|
| What's wrong with Telegram is the privacy story. It's not
| end-to-end encrypted, meaning that _the server can read the
| content of your messages_.
|
| I hear that Telegram has a great UX, which makes it popular.
| But in terms of security... it's wanting.
| maqp wrote:
| Telegram is a joke in professional cryptography circles
| https://x.com/matthew_d_green/status/726428912968982529
| palata wrote:
| To me it's just not an encrypted messaging app. I don't
| even get all the discussions about it...
|
| It's a bit like if we analysed the E2EE guarantees of
| email over and over again. Every year, multitudes of
| people would publish a post explaining how email is
| "badly encrypted". Well, email is not E2EE, period. If
| you want E2EE, use a system that has E2EE.
| maqp wrote:
| 1. It's not end-to-end encrypted by default.
|
| 2. No group chat, even a small one between close friends is
| end-to-end encrypted.
|
| 3. Almost all desktop clients support no end-to-end
| encryption for 1:1 chats, meaning if you use the desktop
| client as part of your workflow, you're forced to drop using
| the end-to-end encrypted secret chats.
|
| 4. No cryptographers have ever worked in the company.
|
| 5. Horrible teething issues for the protocol:
|
| Telegram hosted a cracking contest back in 2013. Everyone in
| the industry know they are bullshit, and this was discussed
| back in 2013 The Fallacy of Cracking Contests (1998) | Hacker
| News The tldr is, Moxie issued a counter challenge to
| Telegram where he presented the same goals with already
| broken primitives like MD5, to break the encryption. Telegram
| never proved the challenge could be won even under those
| conditions. (Also again, given that Telegram's built in
| backdoor of "people are lazy" exists, the cracking contest
| was pointless. It doesn't matter how good the encryption is
| if the adversary wears you down to hand over the keys).
|
| http://unhandledexpression.com:8081/crypto/general/security/.
| ..
|
| https://eprint.iacr.org/2015/1177.pdf
|
| https://web.archive.org/web/20160425091011/http://www.alexra.
| ..
|
| https://words.filippo.io/dispatches/telegram-ecdh/
|
| https://mtpsym.github.io/
|
| Also this:
|
| https://blog.cryptographyengineering.com/2024/08/25/telegram.
| ..
| 9283409232 wrote:
| Wasn't there a big falling out between the Matrix team and
| Element or am I misremembering what happened?
| Arathorn wrote:
| Element is the company formed by the team who created Matrix
| to work on Matrix, almost all of whom are still there; there
| is no falling out :)
|
| The Matrix Foundation is the non-profit set up by the Matrix
| team in 2018 to keep Matrix itself independent of Element and
| other Matrix vendors - to act as a steward of the protocol
| and a standards body. Originally Element donated almost all
| of its code on Matrix to the Foundation (e.g. Synapse, the
| original Matrix server) as permissive Apache-licensed FOSS,
| assuming that if Matrix was successful, folks would want to
| fund it.
|
| In practice, by 2023, Matrix was very successful... but it
| transpired that the vast majority of folks commercially
| building on the Foundation's Apache licensed code failed to
| route any funding back to the Foundation (as the hosting
| body) or to Element (as the primary code contributor),
| despite many polite requests. As a result, there wasn't
| enough $ to pay folks at Element to keep working on the core
| Matrix projects as their day job. So, to keep the lights on,
| Element stopped donating their work to the Foundation, and
| changed license to non-permissive AGPLv3 in order to sell
| AGPL-exceptions to the folks commercialising it. This has
| helped the situation somewhat (although Element isn't at
| breakeven yet). Meanwhile, it's left the Foundation focused
| on governance, the Matrix standards process, trust & safety
| and hosting core libraries like E2EE and matrix-rust-sdk.
|
| There's no beef between the Foundation and Element over this.
| In a utopia the projects would certainly have stayed as
| Apache licensed code in the Foundation - but then again,
| other standards bodies like W3C or XSF don't publish code
| these days: it's a phase that a given protocol grows out of
| once third party organisations get busy building
| implementations.
|
| Disclaimer: i'm conflicted on this, being project lead/co-
| founder for Matrix, and then CEO/CTO at Element.
| ants_everywhere wrote:
| I say this all the time, but the _point_ of the permissive
| licenses is you 're making a donation to private industry.
|
| There are reasons to do this, for example if you believe
| that private industry adopting some technology is good and
| you want to make that happen.
|
| But people keep seeming surprised by the fact that these
| donations aren't reciprocated (or at least people don't
| seem to plan for them to never be reciprocated). It sounds
| to me like the AGPL license was more consistent with their
| goals.
| bigstrat2003 wrote:
| Not quite. The point of permissive licenses is that
| you're making a donation to _everyone_. If private
| industry uses your donation fine, if not that 's fine
| too. But it's certainly true that if you have a problem
| with private industry using something you freely gave
| them, permissive licenses aren't for you.
| ants_everywhere wrote:
| If you wanted to make a donation to _everyone_ , you'd
| use a copyleft license.
|
| The point of permissive licenses is to grant the ability
| to exclude people from the enjoying the benefit of
| improvements.
|
| I.e. they're not for creating public goods. They're
| grants for making it easier to create excludable goods.
| ranger_danger wrote:
| > The point of permissive licenses is to grant the
| ability to exclude people from the enjoying the benefit
| of improvements.
|
| I find this comment to be incredibly disingenuous, and
| just plain false.
|
| Excluding people would only be done if someone took a
| permissive license and then _re-licensed it_ to something
| more closed... you 've entirely made up a malicious
| assumption about what people do with the software. And
| you're even assuming people ARE doing something like this
| with the software.
|
| A permissive license simply lets you do just about
| anything you want with it. Some will agree this is more
| "free". But, freedom TO vs freedom FROM is a common
| argument.
| tw04 wrote:
| I think we need to distinguish using and abusing. IMO a
| private corporation taking the source to make a
| commercial project and refusing to give anything back
| (whether patches, money, or otherwise) is abusing.
|
| When corporations utilize the code and make a good faith
| effort to contribute back something, no matter how
| trivial, they are using the source.
|
| Just because it's legal doesn't make it right and I feel
| confident given the current state of the world saying
| that we should start expecting more from corporations.
| The idea "they only exist to make money" is how you break
| the social contract.
| freedomben wrote:
| FWIW I think AGPL is the right license choice for you. The
| more experience I gain the more I lean toward AGPL for
| products, MIT for libraries.
| bigstrat2003 wrote:
| I don't think there's anything wrong with permissive
| license for a piece of software. But if you're running a
| business that needs to pay developers, it's really not a
| good idea. Very few, if any, people are going to donate
| to your project out of a sense of duty to help you keep
| the lights on.
| freedomben wrote:
| I don't disagree, but I think the bigger risk is just
| that big companies who can and should throw some
| financial support your way, just won't if it's
| permissively licensed. They've demonstrated repeatedly
| that they'll just take the software and use it, including
| making (sometimes substantial) money on it, and none of
| that will flow back up.
| 9283409232 wrote:
| I understand now. Thanks for clearing that up for me.
| jcul wrote:
| Signal doesn't have a web interface, but being able to use a
| desktop app is OK for me.
|
| The big downside for me is not being able to use it on two
| devices. All the other services, privacy concerns or not can
| now do this. It's one reason why I stopped donating to /
| advocating for signal.
| foresto wrote:
| > I assume that Meta has a backdoor into WhatsApp conversations
|
| They don't need a back door when they control the front door:
| the app. End-to-end encryption doesn't protect the endpoints.
|
| (In other words, your concern is warranted.)
| ranger_danger wrote:
| And the default/largest homeserver, matrix.org, uses
| cloudflare, so all your data belongs to them as well.
| foresto wrote:
| It is disappointing that they use Cloudflare, especially
| since most Matrix metadata hasn't yet been moved to the
| end-to-end encrypted channel.
|
| (Arathorn: is e2ee metadata still on the roadmap?)
|
| But no, not all your data is exposed. The e2ee parts, like
| message content in encrypted rooms, are opaque to
| Cloudflare.
| ranger_danger wrote:
| There are ways to get web interfaces for Signal.
|
| But I think the bigger issue is that any platform that controls
| the javascript sent to you from a web page, can also
| backdoor/MITM/inject malicious code at any time without you
| knowing.
| jokoon wrote:
| I set firefox to clear cookies, also using cookies to "strict"
|
| This somehow causes a huge pain to connect to mozilla's matrix
| instance, and I never understood why. This is a bit ironic since
| firefox has that feature to clear cookies.
|
| I had to reset password, and do other weird things, I can't
| remember what exactly.
|
| I hope this MAS thing fixes it.
| apples_oranges wrote:
| So unusable for people like me who only surf in private mode
| anon7000 wrote:
| I mean, yeah, tracking prevention features basically completely
| break cross-domain authentication. There are a surprising
| number of valid use cases that need cross-domain auth (or make
| the user experience a lot easier). While there are workarounds
| these days, sometimes it does require deep changes in how auth
| works
| jokoon wrote:
| > There are a surprising number of valid use cases that need
| cross-domain auth
|
| I am not a web developer, but I would disagree with that.
|
| Either web standards respect privacy or they don't, but I
| would not sacrifice privacy for anything.
|
| Firefox was right to prevent tracking, it highlights how
| webstandards are just not good. I something doesn't work
| properly in a firefox private window, to me it should not
| exist.
| kibwen wrote:
| The status quo appears to involve handing over your account
| password to your chosen client. That's worse than this.
| wkat4242 wrote:
| If you don't trust your matrix client, why use it at all?
|
| It's also a bit disheartening to see Matrix putting all
| that "Log in with Google", Apple, Facebook etc so
| prominently on their login page. The whole idea of
| decentralised services was getting out of those walled
| gardens.
| johnmaguire wrote:
| Yeah, I would argue it's less about removing trust from
| the client (which will ultimately get an auth token in
| addition to secrets and plaintext messages) and more
| about allowing for centralized authentication and
| authorization policies.
| cvwright wrote:
| But you already trust your client with all the private
| keys and message plaintexts for your account.
|
| I struggle to see why I should trust it with those things
| but not the account password.
| dwattttt wrote:
| Authentication requires the opposite of privacy. If you
| don't want to be identified, you can't restrict anything to
| your identity.
| kevin_thibedeau wrote:
| If I'm authenticating with server A. I shouldn't have to
| carry ephemera from server B. A can interact with B on
| its own if necessary.
|
| Bubbling up these architectural details to the front end
| is a symptom of the webdev cargo cult coming up with
| broken ideas that get fossilized as the status quo.
| johnmaguire wrote:
| With OIDC, both occur: the client is redirected to the
| authentication server where they directly authenticate,
| then carries a token cross-domain back to the service.
| Finally, the service validates the token against the auth
| server.
|
| The alternative would be something where I enter my
| Google username/password on random websites, and trust
| that they will forward it to Google and not do anything
| nefarious. This is less secure and less private.
| johnmaguire wrote:
| It kind of depends. See Kagi Privacy Pass ("Allows you to
| use Kagi Search with Privacy Pass, which
| cryptographically ensures that Kagi cannot tie that
| request to an account and allows for further privacy and
| anonymity."): https://help.kagi.com/kagi/privacy/privacy-
| pass.html
| nurettin wrote:
| How do you prevent them from collecting "Interaction Data"?
|
| https://www.mozilla.org/en-US/privacy/firefox/#bookmark-how-...
| BrenBarn wrote:
| > No more typing your password in every client you'd like to log
| in to.
|
| So. . . how will we log in? This post is heavy on vague promises
| of greatness but light on concrete details of UX.
| halJordan wrote:
| Read the whole blog, and it directs you further for more
| details. But this blog does tell you they're moving to oidc.
| That means you will get all the non password flows oidc
| supports.
|
| This is a reading comprehension problem more than a blog
| writing problem
| palata wrote:
| > So. . . how will we log in?
|
| I think you will log into your server, and then the server will
| offer you to give access to the client. The screenshot right
| below the line you quote seems to show exactly that.
| BrenBarn wrote:
| I guess I can believe that, but it's unclear because there's
| nothing to tell me what that's a screenshot of. The icon in
| the screenshot is the Element icon, which is a client, so at
| first glance I figure it's a screenshot of Element. After
| reading your comment I can infer that it's actually something
| else (a website?) showing me the icon of the client that
| wants access. That makes sense, but it's not obvious just
| from the screenshot.
|
| One reason I ask about this is I always wonder how it will
| work for someone writing their own client, perhaps a very
| basic client (or a bot). Any answer that involves "you will
| click on X" doesn't apply there. As long as there's a
| straightforward API based way, that's cool. And I assume
| there is one here. But my experience has been that such
| changes aimed at "greater security" often make things more
| cumbersome for small-time developers.
|
| But we'll see. Certainly a smoother login (and logout!)
| experience for Matrix would be welcome so hopefully this will
| be a plus overall.
| kuschku wrote:
| If you use e.g., "Sign in with Google" today, you get
| redirected to your web browser, log in, and get redirected back
| to the client. This means you can use the saved passwords of
| your browser, and if already logged in there, you just have to
| click "continue" instead of logging in again.
|
| With MAS, every login works like that. If you click "sign in",
| instead of getting redirected to Google, you get redirected to
| the website of your homeserver, where you can login and
| authenticate before being redirected back to the client.
|
| The primary benefit of using a standard OIDC flow is that your
| authentication server can easily add support for passkeys,
| webauthn, TOTP or captchas, without having to wait for every
| single client to support these features.
|
| While matrix.org uses MAS for this, providing the same login
| features as it used to, your organization might want to use
| Keycloak to connect their homeserver directly to LDAP.
| neilv wrote:
| * Is all matrix.org's server-side for this open source, and able
| to be self-hosted?
|
| * Do all the Matrix clients need to be modified to support this
| authentication method?
| cyberax wrote:
| 1. Yes. Even the public website is open source. The license is
| AGPLv3: https://github.com/element-hq/synapse
|
| 2. Yes.
| Arathorn wrote:
| The new authentication server (MAS) is at
| https://github.com/element-hq/matrix-authentication-service
| (AGPLv3) and entirely self-hostable - e.g.
| https://github.com/element-hq/ess-helm for the brand new
| official helm charts from Element, or
| https://github.com/element-hq/element-docker-demo for a very
| quick and dirty docker-compose setup i threw together.
|
| MAS provides backwards compatibility for the old Matrix auth
| APIs for existing Matrix clients, so they do _not_ need to be
| modified to keep working. However, to get the most out of all
| the new auth features (2FA, MFA, QR login etc. etc.) then
| clients will need to be upgraded to speak OIDC natively.
| Element X for instance is already OIDC-native.
|
| https://areweoidcyet.com has more details.
| kibwen wrote:
| Discord's ongoing enshittification may create a market
| opportunity for alternatives in the near future. I'd like to
| think that Matrix could be a beneficiary of that, but the common-
| case UX needs to be polished damn well when the time comes if
| they want to capitalize.
| Arathorn wrote:
| MAS and Next Gen Auth open up the way to things like QR-login
| (complete with syncing all E2EE state and verification!) which
| should help enormously with common-case UX.
|
| See https://youtu.be/ZiRYdqkzjDU?t=966 for a demo of it from
| The Matrix Conference in Sept, or
| https://youtu.be/lkCKhP1jxdk?t=1832 showing it working in on a
| fresh instance of element-docker-demo at FOSDEM 2025.
| frankzander wrote:
| Does actually exist matrix servers for warez?
| oofbey wrote:
| So Matrix is the new XMPP?
| yaky wrote:
| This sounds great for large and corporate servers, but a pain for
| small self-hosted ones. More configuration and external
| dependencies. Plus additional confusion for non-techy users on
| those smaller servers.
| jchw wrote:
| I don't think this will be required for other servers any time
| soon, if ever. Clients are going to have to support logging in
| the oldschool way indefinitely, especially since most Matrix
| servers are basically unmaintained.
| t3chguy wrote:
| You say that, but Element X (Android & iOS) already lacks
| full support for the oldschool way. It only supports certain
| flows therein AIUI.
| jchw wrote:
| Yeah, I realize that, but that's exactly why it's Element X
| and not Element. Element was actually planning on dropping
| support for older servers, but for ecosystem reasons they
| had to can that indefinitely. I don't think Element will
| become Element X anytime soon with the ecosystem in such
| bad shape.
| xyst wrote:
| I quickly looked at the MSCs and seems "MAS" and associated MSCs
| enable OIDC/OAUTH authentication flows (basically integration
| with your favorite identity provider such as Google or Apple).
|
| I was hoping for matrix homeserver to act as an identity provider
| as well to give us an alternative to big tech for "identity".
|
| I suppose I could just setup Ory or other open source IdP, but
| would have been nice to have an all in one package.
| Arathorn wrote:
| MAS can be used as an OIDC IdP, and in future MAS will be
| embeddable in Synapse so you can use your homeserver as an IdP
| in the way you want, all in one package.
|
| That said, MAS is deliberately not a very featureful IdP - it's
| focused on being the glue between Matrix and OIDC. If you want
| a more sophisticated IdP then you'll still want to run a
| dedicated one.
___________________________________________________________________
(page generated 2025-04-02 23:00 UTC)