Our great sponsors
-
-
matrix-doc
Discontinued Proposals for changes to the matrix specification [Moved to: https://github.com/matrix-org/matrix-spec-proposals]
We are actually working on fixing the password sending issue, see for instance https://github.com/matrix-org/matrix-doc/pull/3262
Of course, untrusted clients can do all kinds of evil things after having authenticated. (And also clients still need the plaintext password at least client-side no matter what we do)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Speaking as project lead for Matrix, while we're always happy to see new projects building on Matrix, we share the concern that users shouldn't be encouraged to enter their Matrix username & password into arbitrary webapps which may or may not be trusted. To be clear: Sign in with Matrix is an independent project from a community member which isn't associated or endorsed by the Matrix core team.
The direction we're headed in the Matrix spec core team is instead towards replacing Matrix's current auth mechanisms with normal Open ID Connect (rather than wrapping our own OIDC-like thing, as we do today) - as per https://github.com/sandhose/matrix-doc/blob/msc/sandhose/oau.... The common login flow would then be for users to be authed by their server using a trusted OIDC identity provider, rather than ever trusting arbitrary clients with their credentials.
This is not finalised yet, as we still want to find ways to support folks authing on known trusted clients without having to embed a web browser - and we don't want to design out cryptographic login (e.g. OPAQUE style auth mechanisms) in future.