Generic Matrix Client Support

[ChurchOfTheSubgenius]

While the complete Commune experience necessitates the combination of both back- and front-end systems, the basics of Commune's functionality can be achieved strictly client-side, making it perfectly suited for an MVP.

We'd like the client to decouple itself from the commune-server so that it can optionally be used as a regular Matrix client (Element etc).

Ideas:

• Configurable via .env flag
• Use matrix-js-sdk to talk to Synapse/Conduit directly

Questions:

• Do we want to tie the client to a specific homeserver and domain?

• How do we make spaces/rooms publicly accessible?

• What do we do with commune specific features - hide them completely?

• • -

TODO:

• [ ] Refactor frontend to remove hard dependency on commune-server
• [ ] Allow commune to speak directly to Synapse/Conduit via the client-server API (integrate with matrix-js-sdk)
• [ ] Refactor frontend components to work with native matrix events
• [ ] Additional Sveltekit routes for handling conventional matrix URLs, make them publicly accesible

[erlend-sh]

Do we want to tie the client to a specific homeserver and domain?

Matrix.org is the sane default to start with as far as self-service goes. We can figure out what the other configuration options (hidden behind a toggle) should look like together with self-hosting early-adopters.

How do we make spaces/rooms publicly accessible?

Same as whatever matrix-viewer is doing I reckon. We just need a very clear opt-in process for admins. It should work somewhat similarly to t2bot, with the addition of a default mention-all announcement when a room has been made web-public.

According to matrix-viewer there also exists some kind of world_readable attribute in Matrix homeservers?

What do we do with commune specific features - hide them completely?

I'd rather we just greyed them out, so users know they're soon to become reality in regular Commune.

On that note, maybe we could call this "Client as a Service" MVP 'Commune Preview' and host it on preview.commune.sh? It has multiple meanings:

• It's essentially a preview of the full Commune platform experience, i.e. a precursor to what is yet to come.
• It literally lets you pre-view Matrix instances

[ChurchOfTheSubgenius]

Matrix.org is the sane default to start with as far as self-service goes.

Just to clarify, I meant whether the generic matrix client should be able to log in to any matrix homeserver (like Element et al) or be configured to use single homeserver (mycoolmatrixsite.com). But yes, this should be configurable.

According to matrix-viewer there also exists some kind of world_readable attribute in Matrix homeservers?

Yes, Commune uses the same attribute, except every new space/room is world_readable by default. Should work the same with matrix, as the API won't expose anything that isn't world_readable, publicly. Will look more into this shortly.

On that note, maybe we could call this "Client as a Service" MVP 'Commune Preview' and host it on preview.commune.sh?

This is a good idea. :+1:

[ChurchOfTheSubgenius]

I've decided to put everything under two config options.

# Set the client to act as a pure Matrix client
PUBLIC_LEGACY_MATRIX_MODE=true|false

# Tie the client to a specific matrix homeserver, or allow the user to choose homeserver (Element etc).
PUBLIC_LEGACY_MATRIX_OPEN=true|false

Enough to start with, but expect to require more options for fine-grained control.

[ChurchOfTheSubgenius]

Commune uses pretty URLs like https://app.commune.sh/rust for public spaces - which is really just #rust:commune.sh under the hood. Native matrix clients URLs use full room aliases like https://app.commune.sh/#/room/#rust:commune.sh (🤢).

Using commune-style URLs would require a lot less work. Otherwise we'd need to write a whole lot of extra sveltekit routes.

[ChurchOfTheSubgenius]

Commune uses pretty URLs like https://app.commune.sh/rust for public spaces - which is really just #rust:commune.sh under the hood. Native matrix clients URLs use full room aliases like https://app.commune.sh/#/room/#rust:commune.sh (🤢).

Using commune-style URLs would require a lot less work. Otherwise we'd need to write a whole lot of extra sveltekit routes.

After tinkering around with Element web for a bit, I think we should just follow their URL format, just to be consistent with being a native matrix client too. It's not pretty but that's okay.

[erlend-sh]

Using commune-style URLs would require a lot less work.

Did that turn out to not be true? I would understand sticking with the Element format if was simpler to implement and/or less error-prone, but if it’s actually harder to do it their way I don’t understand what we gain by following their example.