Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
base: main
Are you sure you want to change the base?
MSC4079: Server-Defined Client Landing Pages #4079
Changes from 13 commits
5287f44
f25be00
10c7490
56687ca
71210b4
3d116a4
5f15664
fdf133b
514079f
15187c6
7b54dd8
8d0344a
4f4a81e
8d53f93
b032ae9
0184f30
bf22ba8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I know, it's not something that's supported or even common.
text/html
means thebody
is HTML. Putting the URL in there would simply render text spelling out that URL.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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. ↩
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.