matrix-spec-proposals
matrix-spec-proposals copied to clipboard
matrix-org
MSC2385: Disable URL Previews, alternative method
This MSC provides an alternative method to MSC2376
Shepherd: @anoadragon453
Signed-off-by: Sorunome [email protected]
Other potential issue: naughty clients could add some urls in url_previews that are not in the message, resulting in URL preview displaying bad content not related to the message.
Why not having just a list of booleans to avoid repeating the url in the message?
Other potential issue: naughty clients could add some urls in
url_previewsthat are not in the message, resulting in URL preview displaying bad content not related to the message. Why not having just a list of booleans to avoid repeating the url in the message?
Further on, please comment on a specific line of text so that discussions could be tracked more easily. As per your concern - as far as I see, the MSC states that URLs in url_previews must be exactly the URLs in the message body, so a boolean would be superfluous.
Other potential issue: naughty clients could add some urls in
url_previewsthat are not in the message, resulting in URL preview displaying bad content not related to the message. Why not having just a list of booleans to avoid repeating the url in the message?
As stated in the MSC, url_previews is basically a whitelist, not a list of URLs to do previews for. So you still do URL previews like currently but additionally check if it is present in url_previews (if present). Thus additional URLs in that list would be just ignored.
Honestly I kinda like the potential to hint clients to render "previews" for links not present in the message.
I believe facebook does this, where you can paste in a link, get a preview, remove the link and then just comment on the link being shared.
essentially turning the preview into more of a "rich link" part of the message.
the MSC states that URLs in
url_previewsmust be exactly the URLs in the message body
Yes, but what if it's not the case?
Anyway, maybe the pb is to avoid rendering useless url preview in the timeline, so maybe the solution is to stop displaying url preview in the timeline and display the preview in a popup when the link is hovered or when the link is clicked (the same way Google docs do it for instance).
the MSC states that URLs in
url_previewsmust be exactly the URLs in the message bodyYes, but what if it's not the case?
It is supposed to be ignored, as stated in the MSC
If a URL is present in this key that is not present in the body clients SHOULD NOT render a preview for that URL.
Honestly I kinda like the potential to hint clients to render "previews" for links not present in the message.
I believe facebook does this, where you can paste in a link, get a preview, remove the link and then just comment on the link being shared.
essentially turning the preview into more of a "rich link" part of the message.
I would absolutely prefer such behaviour to be in a separate MSC. Matrix operates in a very different realm than Facebook; I could imagine such behaviour as somewhat natural in Mastodon but not in Matrix.
Honestly I kinda like the potential to hint clients to render "previews" for links not present in the message. I believe facebook does this, where you can paste in a link, get a preview, remove the link and then just comment on the link being shared. essentially turning the preview into more of a "rich link" part of the message.
I would absolutely prefer such behaviour to be in a separate MSC. Matrix operates in a very different realm than Facebook; I could imagine such behaviour as somewhat natural in Mastodon but not in Matrix.
This could help with clients exempting urls from the array by (for example) surrounding those urls with <>, on other clients, this disables that preview.
I was going to open issue about this then I found this MSC! Thanks for good ideas guys ;)
@Sorunome hello! If you don't have the time to respond to feedback on this MSC, you be willing to allow me to shepherd it?
This was added to the "Needs idea feedback" column on the SCT backlog board as I thought it could use a more recent review from a SCT member.
But in hindsight, this is mostly ready, and is just blocked on closing the existing threads of discussion.
So... taking off the board again until that's done.
If you don't have the time to respond to feedback on this MSC, you be willing to allow me to shepherd it?
I have received a "yes" out of band.
https://github.com/matrix-org/matrix-spec-proposals/pull/4095 is an alternative for this, with the extra functionality of being able to bundle preview data (the bundling isn't mandatory though)
