matrix-login
codeberg.org
A Proof of Concept for using a matrix ID instead of email for signing up to services

I wrote a proof of concept that allows the user to sign up to a service using their matrix ID e.g @user:server.test. The user then receives an activation link in an encrypted room from the service. It worked quite easily and within 2 days of fumbling around with the matrix SDK in python and FastAPI, here we are.

This has been in my head for a while and I just wanted to see if it’s possible (the proof is in the pudding code). Emails are insecure and national services are starting to implement communication services on top of matrix. It’s a not inconceivable that citizens might get a government issued Matrix account and communicate safely with the government over a secure protocol. Why not allow other services to do the same?

Imagine if instead of providing your email address for signing up to services you used matrix instead. Your host wouldn’t be able to read your messages and it could replace things like 2FA codes over SMS, activation links in emails, or health documents from your doctor’s CMS in your email inbox.

Should there be enough time, I’d like to try and contribute this login method to forgejo (the software behind codeberg that’s hosting this repository), but let’s see. First it would take learning go 😅

  • Jade
    4·
    11 hours ago

    Matrix is just as much as a standard as XMPP, if not more so because extensions actually get merged into the core spec

    • erebion@news.erebion.euEnglish
      1·
      4 hours ago

      Are they extensions of core spec?

      Also, the client projects cannot keep up and Element has defacto a monopoly and could always do what they want.

      Meanwhile, XMPP has RFCs and therefore is an internet standard. Extensions can be created anytime and go to different states when implementations show up and demonstrate interoperability. There are sets of XEPs that should be implemented depending on use-case, such as instant messaging.

      See this post as well:

      When one vendor controls all parts of a service (e.g., both a client and server), it has the means to create a boxed platform. Controlling both the server and client allows a vendor to update the client and server without worrying about breaking compatibility with other clients/servers in the larger network. It could update the client to point users to a server that uses a completely different, closed protocol. This is what happened to many XMPP users in the early 2000s.

      Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving third-party implementation feasibility out of the decision-making process.

      Case study: Matrix and Element

      The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it’s developed by the same company that builds the dominant servers and most of the spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn’t supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.

      As a user, consider using clients and servers made by different groups of people to make platform boxing more difficult. Pick implementations that suffer from less feature creep beyond spec compliance. What distinguishes a client shouldn’t be what features it has, but how it implements its features. Obviously, having some unique features is great; problems arise when the number of unique features crosses a certain threshold. Following both these practices encourages implementations to stick to standards compliance, reliability, and compatibility rather than “innovation”. Choose boring technology over shiny new features.

      Try venturing outside the mainstream by taking a look at a less popular provider or client. All implementations start somewhere, and a diversity of implementations prevents a rule by oligopoly.

      https://seirdy.one/posts/2021/02/23/keeping-platforms-open/