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 😅

  • fruitycoder@sh.itjust.works
    9·
    4 days ago

    I mean OIDC is the standard. SAML is the legacy. Email is just the current defacto messaging platform for accounts so I see no reason Matrix couldnt be.

    ActivityPub isnt built for private data, nor IRC. XMPP can but again not its primary design focus.

    • erebion@news.erebion.euEnglish
      2·
      4 days ago

      XMPP? It’s literally the internet standard for that. But it’s not a platform, it is a protocol. Platforms aren’t a good thing.

      • fruitycoder@sh.itjust.works
        1·
        2 days ago

        Proticols dont do any thing. Platforms/implementations do. Im not knocking XMPP, there are extentions that support e2e, I was just saying that is core to Matrix spec and thus every implementation.

        Heck, I’d think Matrix, Nostr, and XMPP would better than email, which itself is better than shudders propritary “social” media, or plutocrat accounts like Google, Apple, or Microsoft.

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

          Proticols dont do any thing. Platforms/implementations do

          Protocols ensure interoperability between implementations, platforms are not necessary. XMPP works just fine without it.

          there are extentions that support e2e, I was just saying that is core to Matrix spec and thus every implementation.

          No, there are many implementations that in fact do not support E2EE and also many that cannot keep up with the many protocol changes.

          Heck, I’d think Matrix, Nostr, and XMPP would better than email, which itself is better than shudders propritary “social” media, or plutocrat accounts like Google, Apple, or Microsoft.

          I partly agree. Email has issues, but largely works. Proprietary “social” media is just hell. I haven’t looked into Nostr yet, but am going to. Matrix is slow, XMPP has proven to work well for a while, it has been around since 1999 after all. It is extensible, which means you can make it work just as well in the future.

          Not a fan of Matrix in particular, but I guess it’s still better than Facebook, but that’s not a high bar.

      • Jade@programming.dev
        5·
        4 days 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 days 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/

          • Jade@programming.dev
            1·
            3 days ago

            I kind of don’t want to bother replying to your random claims, but I’ll bite a little:

            That post is now five years old, and almost completely wrong or outdated. That first paragraph is also absurd fearmongering - and both technically impossible for matrix and against Element’s buisiness interests. I develop my own homeserver software, and it’s recently become more popular than dendrite. I use a client developed by a friend that seems like it has more features than element (although it’s less user friendly).

            Being an official standard isn’t working out particularly well for ActivityPub.