Qualifying the type of users using Element

[germain-gg]

Is your feature request related to a problem? Please describe.

As part of the Delight team we're trying to cater for the needs of three different user groups.

• Personnal messaging users
• Community users
• Workplace users

It often seems that we are stuck trying to figure out a solution that would fit all three groups where the reality is that they have widely different type of usage and should sometimes have different default values for specific settings or how the application articulate itself

Describe the solution you'd like

We mentioned the idea of letting users mention what kind of usage they will have with Element.

Describe alternatives you've considered

I believe we can go a step further. Often-times homeservers admin know a lot about the type of users that will use their instance (I consider matrix.org an exception here).

We could add an option to the homeserver config (homeserver.yaml) to advertise the type of users using this instance

• Users of Element One => personnal messaging cohort
• Users of mozilla.org => community cohort
• Users of element.io => workplace cohort

We should also let users override that setting, but the advantage of moving that responsibility onto the instance admin is that we not be required to ask this information upfront

Platform issues

• How and where could we ask the use case question? element-web#21949

[daniellekirkwood]

This is a really great idea.

Part of asking this question on mobile was to introduce the user to element and show them that you can use this product for all those things. It's a little bit of marketing with a little bit of emotional support so I would suggest we treat it differently from this issue (as both would be great).

[germain-gg]

@clokep and @niquewoodhouse I'd be interested in hearing your side of this too?

[clokep]

I believe we can go a step further. Often-times homeservers admin know a lot about the type of users that will use their instance (I consider matrix.org an exception here).

We could add an option to the homeserver config.json to advertise the type of users using this instance

@gsouquet clarified that this is referring to the homeserver's configuration (homeserver.yaml).

The idea here is that the admin sets something in the configuration (defaulting to unset, most likely); (new) users would get some account data set, which clients could read. This could then be used to make decisions by the client on e.g. default notification settings or something else.

I think this would work for some use-cases, as given above, but I'm unsure. There is some prior cases where we've done something similar (see https://github.com/matrix-org/synapse/blob/4bc8cb4669ddeb719a3a6de39b093fc3be8db6fe/synapse/rest/client/versions.py#L90-L93).

In many ways, it feels like these should be part of a configuration for the client though (e.g. client.json), but this only exists for Element Web (not Desktop, iOS, or Android) and (additionally) only Element Web might get a separate deployment per-homeserver.

My overall gut feeling though is that it is:

• It isn't super desirable to include configuration that is unused by the homeserver itself.
• What about other homeservers besides Synapse? Is this a specced thing that we would need to care about?

should sometimes have different default values for specific settings or how the application articulate itself

I think I would push back on this -- this increases the complexity of documentation / tutorials, etc.

[germain-gg]

Closing as we took a different approach, which was implemented as part of matrix-org/matrix-react-sdk#8984