MSC4079: Server-Defined Client Landing Pages

[williamkray]

Rendered

Signed-off-by: William Kray [email protected]

[joepie91]

This should be more clearly specified; must a client implement this functionality, with a choice between these two options? Or are these merely two suggested representations, and may a client also choose not to implement it at all? Are they allowed to implement it in a manner not specified here?

The field is specified as 'optional' further up in the MSC, but that seems to only describe whether the server is required to provide such content, not whether the client is required to consume it.

[williamkray]

i honestly don't know, i feel like clients may want to choose whether to support this feature. it's not critical to the functionality, and server operators may opt to only support or deploy clients that do support this feature. i don't think it should be a showstopper for a client to be considered fully-baked. but i'm open to feedback.

[joepie91]

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.

[uhoreg]

Some of these could be done using Server Notices

[williamkray]

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

[williamkray]

addressed in the document introduction

[deepadmax]

I think that it shouldn't be specifically an HTML document. This would exclude clients that don't support HTML. It could perhaps adhere to Extensible events and offer the page in different formats.

Following the format of m.text, this might look like;

[
    {
        "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]

i think html is already a pretty widely accepted expectation and is included throughout the spec already.

[deepadmax]

i think html is already a pretty widely accepted expectation and is included throughout the spec already.

With MSC1767, this is intended to change. It is being adopted across the board, so it would be a good idea to try to implement it here as well. HTML could still be offered this way. It would just be that it also supports a plain text fallback and any other format that you might want to support.

[deepadmax]

External resources (e.g., images, stylesheets) MUST NOT be fetched by default to avoid privacy leaks and must be explicitly allowed by the client.

The standard Matrix media repository would be a good fit for this. The client would only ever have to communicate with the homeserver. The homeserver would serve the contents of the homepage to the user directly, as it does with everything else.

[MichaelKohler]

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?

[williamkray]

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.

[deepadmax]

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.

[deepadmax]

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.

[williamkray]

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.

[deepadmax]

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.

[williamkray]

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.

[deepadmax]

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.¹ 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. ↩

[williamkray]

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.

[williamkray]

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.

[Johennes]

Just a thought but maybe we could let servers define the refresh period via cache control headers?