In T193964#4250027, @bd808 wrote:

The cloud-services-team and I want to be on record here that this project is for testing matrix, and should not be used to create a general purpose production instance. It would be nice to see documented acceptance criteria for your trial somewhere so that it will be easier to decide when things have advanced to a point where discussions with the SRE team about production hosting options are warranted.

Here is an attempt (numbers are somewhat random / made up, feedback welcome):

Matrix is a federated network so for most purposes it makes no difference whether we use the Matrix.org homeserver or one hosted in WM Cloud. There are two exceptions, testing which is the goal of this project:

• speed
• single sign-on

So those are the technical success criteria: working single sign-on (or agreement that it cannot be done with reasonable effort and it's OK to go without it) and decent speed (less than 1s completion time for most operations in most cases).
The social success criteria is 20% of IRCCloud / Slack users saying they see it as a viable alternative that's more in line with our values.

We now have a working, non-federated, still insecure Synapse instance at https://synapse.matrix.wmflabs.org:8448

New users have to be registred server side at matrix-synapse-01 with ~$ register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml https://localhost:8448

Then, any client can be used to connect to it. At https://riot.im/app/ that means using the custom server option with https://synapse.matrix.wmflabs.org:8448 , (and manually going to https://synapse.matrix.wmflabs.org:8448 and accepting the self-signed certificate for the time being).

This will not be the final instance setup, and I don't think it is wise to open it to public consumption yet. But I set it up to play with single sign-on and anyone who wants to test the speed difference is welcome to join.

I got a working OAuth_v1 password provider for mediawiki code at https://github.com/chicocvenancio/mediawiki-synapse-auth

My idea here is to only handle the last step in the OAuth dance on the password provider, it gets the request token and the oauth token and request an access token. Does that seem flawed to anyone?

Matrix has OAuth v2 on the spec, but it seems like a lot more upstream work to make compatible with OAuth v1, so using a password provider seems like a good way out until T125337. That does mean we can't make the full flow in the server, so my idea was to break the flow for the first steps in the client and then pass the request token to the synapse server.

Basic PoC is working for the server-side part.

Is the server communicating with others yet? If I use it will I only be connected with people on this server?

In T193961#4530070, @MarkAHershberger wrote:

Is the server communicating with others yet? If I use it will I only be connected with people on this server?

Yes, only with people on this server, it is not federated or bridged at all at this point.

In the short term, we are going for a (temporary) hosted instance instead. Less effort to set up, trivial amounts of money and makes it possible to gauge organizational interest without expending too much effort first. See T215042: Set up a hosted Matrix.org / Element instance on modular.im.

Merging MediaWiki-Stakeholders-Group-Technical into MediaWiki-Stakeholders-Group