Hey @[email protected], 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 started making a joke site https://windowsupgra.de/ (hosted on codeberg using codeberg pages). The goal is to make it look like some amazing way to upgrade Windows and actually install Linux. Like those product or marketing pages selling you something.

It's completely rough, but if someone with UI experience could spiffy that up, feel free to make a PR with screenshots. Don't forget, codeberg doesn't have a CI. So at the moment, deployment is literally copying src/ to another folder where the pages branch is checked out, committing, and pushing it.

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.

That is very cool! A good demo of what is possible :)

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).

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.

::: spoiler 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... @[email protected] as a matrix server developer could think of something?