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 😅
Hi there, Continuwuity developer here - This seems like an awesome idea! You might also want to see if you can use/extend the new oauth specification from MAS to create a more ‘Log in with Social’ like experience, too, although only Synapse supports that right now
Hey @JadedBlueEyes@programming.dev, are you talking about Synapse’s SSO implementation? I’ve had to deal with SAML before and it wasn’t a particularly joyful experience but since synapse makes it possible, it would indeed be a useful contribution to Forgejo too! Maybe it’s just a question of providing documentation and some example configs for Forgejo to make instance owners aware of the Synapse SSO capabilities.
The reason I went with this is implementation is because email just seems to be a notification and communication channel used by other services. Giving the additional option of using Matrix could be easier for devs than figuring out SAML or OIDC.
Question about continuwuity: how can I create an admin user? It might be missing from the doc and the docker image doesn’t have a register_new_matrix_user script.
I’m talking about https://github.com/element-hq/matrix-authentication-service which is the only implementation of https://github.com/matrix-org/matrix-doc/pull/3861 right now.
Yeah, saml is a nightmare! Never make me touch saml, please 🥺
In Continuwuity, the first user created is the admin user - so creating a user using either a registration token, or an admin command via --exec, the emergency password, the interactive console, etc would work.
Matrix? For account creation? WTF?
Why not use an existing internet standard instead? There are so many RFCs, something would work.
Like… IRC. Or XMPP.
That’s what RFCs are for.
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.
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.
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.
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.
I mean out of date software is going to lose compatabilty with encryption.
Matrix is just as much as a standard as XMPP, if not more so because extensions actually get merged into the core spec
And it’s backed by a powerful legal entity.
That’s not a feature, that’s just control.
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.
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.
xmpp plz kthnks
If there’s one constant about Matrix, it is to perpetually reinvent the wheel because it wasn’t invented there in the first place.
I thought it was about reinventing the wheel in a more complicated way that needs more resources and is slower. ¯_(ツ)_/¯
First Problem is the Server nearly everyone uses is dritten in Python. There is no real way to migrate between implementations. That at least could be fixed.
Second Problem is the massive storage space usage. That one is by design and can’t be fixed.
For one thing, I’m glad people finally come to such conclusions. Matrix has been a huge waste, and the tens of millions of investment would have done wonders if poured over better, more mature, healthier and more diverse protocols.
Delta chat uses e-mail securely https://delta.chat/
Woah, cool idea! I wonder how feasible that would be.
Thanks :)
Email is just the communication channel. The relevant code for sending the activation code is just a few lines. Though, there is of course more work to be done for full integration:
- validation of the matrix ID in the frontend (probably a regex?)
- storing encryption keys and room IDs for conversations in order to continue sending messages in to the same encrypted room with users
- adding a mechanism to select either email or matrix for users and allowing secondary matrix IDs (should the user want that)
It should be possible to have this in more projects, but it would probably take a big player to recognise a value (encrypted communication with their users) and adopt it.
Matrix was sure a nice idea but still doesn’t work remotely as food as it needs to, to replace email for that. I take an unencrypted insecure email over matrix any day.
I’d assume that many services were created to send an activation link via email and don’t know how to talk to a Matrix server. In those cases, do they email their activation link to a service or proxy that then communicates it to the appropriate matrix server/account/room?
If the existing service doesn’t want to use matrix IDs and insists on using email, then there is a matrix-email bridge (postmoogle). If the matrix server has that installed, it will be communicating with email and the service won’t have to do anything. Of course, it doesn’t make the communication more secure.
The service could also host their own matrix server with postmoogle, send an email with some format to it and a bot on the matrix server then sends it to the matrix ID of the user, but that’s way more complicated than just adding some code to support communicating via the matrix protocol outright. I did it in about 50 lines (set up the client, create an encrypted chat room, send a message).
Thanks for explaining. 🙂
So can i get rid of simplelogin with something like this?
simplelogin provides email aliases? Using a matrix ID doesn’t solve spam issues. The service could be hacked and all matrix IDs leaked and it would be the same as your email address being leaked.
So, an equivalent service or feature would have to be created for matrix that allows users to generate aliases for use with different services.rambling of other (non) solution
Ooor, users could sign up with room IDs! That would actually solve the problem. As user could create a private room, copy the ID into the signup form, and the service would send messages into the room. It could save the list of participants in the room, i.e your matrix ID though 🤔 So not really a solution.
Good question! Thank you for asking. This would indeed require a solution and aliases built into a matrix server would be the best option. Maybe… uh… @JadedBlueEyes@programming.dev as a matrix server developer could think of something?
For spam protection, we use tools like meowlnir or draupnir with the cooperation of the homeserver to allow completely blocking spam invites - so if a matrix ID goes evil you can leave the room you have with them and add them to a ban list, and you can subscribe to a variety of other ban lists to ban things in advance
