Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4079: Server-Defined Client Landing Pages #4079

Open
wants to merge 17 commits into
base: main
Choose a base branch
from
Open
Changes from 13 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
124 changes: 124 additions & 0 deletions proposals/4079-client-server-landing-page-html.md
williamkray marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -0,0 +1,124 @@
# MSC4079: Server-Defined User Home Pages

## Abstract

This proposal extends the Matrix protocol to allow servers to define custom
formatted documents that can be rendered by clients as a user home page. This feature
introduces a non-intrusive yet flexible manner to communicate server-specific information such as
donation requests, scheduled maintenance, updates, new features, and changelogs.

## Background

Currently, there is no standardized method in Matrix for server admins to communicate information
directly within user clients in a passive way. While rooms can serve this purpose, they lack the
persistence and prime visibility that many server administrators desire. Similarly, server-notices
are aggressive notifications to users that can cause unnecessary noise, and are implemented as
rooms.

## Proposal

Introduce an optional configuration for matrix servers that allows them to specify an optionally
HTML-formatted document, adhering to the current subset of HTML utilized for message formatting.
Clients can render this document in a dedicated "home" view or as a placeholder page when no active
conversations are selected.

## Use Cases

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an additional benefit of something like this, would be that it can improve on the relation between a homeserver operator and their users; right now, homeservers are sort of "homogeneous", in that people use them like a neutral service that just magically exists and they don't know their admin, which can cause problems for sustainability (something that eg. Mastodon does a lot better at).

Having server-specific homepages to introduce people to the community on that homeserver, might help to create a bit more of a social connection to that specific homeserver, making it more appealing for people to eg. run small semi-public homeservers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these could be done using Server Notices

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

server notices are significantly more "invasive", this is a much more passive informational model.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed in the document introduction


- Server administrators want to communicate an upcoming maintenance window without emailing all
users.
- A non-profit Matrix server could display donation information on the home page to encourage
support from its users.
- Announcement of new features or user guides following an update can be nicely formatted and made
readily available upon client login.
- Changelogs for server updates can be displayed, helping users to understand recent changes without
external navigation.
- Links to other supported clients may be supplied in case users are looking for alternative
interfaces.

## Specification

- A new optional field will be defined within the well-known Matrix configuration for clients:
user_home_page.
williamkray marked this conversation as resolved.
Show resolved Hide resolved
- The user_home_page field can be defined as a list of formats following the [Extensible Event
MSC](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/1767-extensible-events.md),
allowing clients which do not render a specific format to fall back to other message types. HTML
is supported as either in-line, or by pointing to an html file at an accessible http(s) endpoint
reachable by the client.
- HTML content will be sanitized by the client and restricted to the subset of HTML currently
allowed for messages.
- This field can be queried by clients during the login or initial loading process, and refreshed at
least once every 12 hours if the client has been open the entire time.
- Clients may choose to implement this feature as a "home" button or as default content in the main
view when no conversation is active.

## Examples

Advertisement of the content for clients to use would be done via `/.well-known/matrix/client`
within the existing `m.homeserver` object.

Example formatting using a file URI:

```
{
"m.homeserver": {
"user_home_page": [
{
"mimetype": "text/plain",
"body": "# Visit https://your.domain/user-home.html for the latest server announcements."
},
{
"mimetype": "text/html",
"body": "https://your.domain/user-home.html"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of newish to the spec, so I'm wondering if it's common to have a URL and load that, or have inline content and render that, all on the same field?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dunno, this is my first MSC. format here is following previous suggestion and is based on the extensible event MSC, to allow for plaintext messaging as a fallback render if clients don't support the html format, while continuing to support the idea of simple, in-line content OR separating the content out to another hosted file somewhere (which presumably can be managed separately from however this json is managed). clients would either be presented with the in-line content which they would render, OR a url they follow to fetch the content to render.

this is wide open for improvement.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of newish to the spec, so I'm wondering if it's common to have a URL and load that, or have inline content and render that, all on the same field?

From what I know, it's not something that's supported or even common. text/html means the body is HTML. Putting the URL in there would simply render text spelling out that URL.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clients would either be presented with the in-line content which they would render, OR a url they follow to fetch the content to render.

I really don't think the client should fetch any external data. A server owner could, if they'd want a specific website to be reflected, run a service that routinely fetches the website, cleans the HTML, and updates the landing page accordingly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from a technical perspective, seems like maybe having a mimetype of application/http would make more sense for this purpose...

i think this is a reasonable use case for fetching external data... this endpoint is controlled by the homeserver administrators and is already used for server delegation. they should be able to point another endpoint for the client to use for other purposes, and the client is responsible for supporting that data endpoint in a sane and safe way. this same concept is currently leveraged for jitsi endpoints, openmap tiling services, etc. which are arguably more critical attack vectors compared to a limited subset of html formatting.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good point. Though it's a bit different with Jitsi, as that's a widget and fundamentally operates differently. Whereas this sort of feature could be implemented strictly through Matrix. Either way, I do like your idea of an application/http mimetype; I think that could be the way to go.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's actually a perfect parallel: this IS effectively a widget, but rather than having the widget tied to a room, it's rendered by the client elsewhere (as determined by the client). instead of room state events defining the widget content (which becomes impossible if the widget is not defined by a room), we are moving that definition to the well-known endpoint. i imagine concepts defined here may eventually be extended to proper widgets at a later point in time. my hope is that this barrier to entry is a little easier for client developers, as currently very few clients actually support widgets at the time of this writing.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's actually a really good reason to serve the content directly, in a standard format. Not all clients (are going to) want to support widgets.1 Keeping it simple and internal will likely lead to more clients implementing the landing page. It would lend itself to a much lower barrier to entry. I feel it would be mistaken to require widget support in order to support landing pages.

Footnotes

  1. Widgets are written in the web languages (HTML, JavaScript, CSS) and so by definition require the inclusion of a web view in your software. That means one extra dependency. And if it's not utilised anywhere else in the app, it could also be considered bloat.

Copy link
Author

@williamkray williamkray Nov 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right but that is solved by supporting the extensible event format proposed above... If remote content isn't supported by the client it can fall back to something else it can render. This is the whole reason for the changes made to align with that msc. Hence my thought that improvements here may someday trickle down to widgets and they might gain more widespread support in clients due to straightforward fallback behavior.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i've updated the verbiage to clarify that minimum support (if a client supports this feature at all, which is itself optional) is plaintext. anything beyond that goes, with html/http examples demonstrated as part of this MSC.

}
]
}
}
```

Example formatting using in-line HTML:

```
{
"m.homeserver": {
"user_home_page": [
{
"mimetype": "text/plain",
"body": "# Welcome to our Matrix Homeserver!\nVisit our website to make a donation."
},
{
"mimetype": "text/html",
"body": "<h1>Welcome to our Matrix Homeserver!</h1><p>Visit our website to make a donation.</p>"
}
]
}
}
```

williamkray marked this conversation as resolved.
Show resolved Hide resolved
Only one value is needed for clients to serve the content. If more than one is presented, the same
standards used the the [Extensible Event
MSC](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/1767-extensible-events.md) are used to choose a format to render.

## Security Considerations

To mitigate any potential security risks from malicious content:

- Clients MUST sanitize the HTML content according to the existing rules for message content
sanitation.
- External resources (e.g., scripts, stylesheets) MUST NOT be fetched by default to avoid privacy
leaks and must be explicitly allowed by the client. Images or files may be rendered and linked
using mxc URIs for native matrix media serving.

## Privacy Considerations

As this feature may potentially be used to track user interaction with the
home page content, it's important to:

- Provide clients the ability to disable external resource fetching.
- Ensure that user privacy preferences are respected when displaying this content.

## Conclusion

This spec change proposal seeks to empower server administrators with the ability to
directly communicate important information to their users within the Matrix client, enhancing the
user experience by providing relevant and timely information while respecting user privacy and
security.