-
Notifications
You must be signed in to change notification settings - Fork 379
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
Helper support for inlining URL previews in clients (SPEC-295) #592
Comments
Jira watchers: @ara4n |
Links exported from Jira: relates to https://github.com/matrix-org/matrix-doc/issues/608 |
The API itself would presumably take a URL and return a JSON blob with a bunch of helpful metadata about that URL - i.e. its opengraph tags, and an MXC url for a thumbnail of it and the actual contents if the URL was an image/video/audio file. The client's linkifier should pull out URLs in messages clientside and hit this API asynchronously to tell the server to go and spider the target and return the metadata (or a cache of the metadata). We wouldn't do this proactively serverside as there's no guarantee that a given client would actually care about this metadata, and it's a slow and heavy process best done in the background. -- @ara4n |
Another way of doing this could be to do it entirely clientside; embedding the target content via iframes or img/video tags - this is how Glowing Bear does it: https://github.com/glowing-bear/glowing-bear/blob/master/js/plugins.js#L184-L201. This is vulnerable to pixel tracking and DoSing the target server however, and only works with services which expose stuff suitable for embedding. Alternatively, services which expose a JSONP endpoint can also be spidered clientside circumventing CORS as per https://github.com/glowing-bear/glowing-bear/blob/master/js/plugins.js#L164-L174 and https://github.com/glowing-bear/glowing-bear/blob/master/js/plugins.js#L404-L423. However, this is a huge security problem as you end up trusting the target content almost entirely, given it can run (almost) arbitrary JS in your client based on whatever it serves up. -- @ara4n |
@ara4n is this not done now? 😇 |
another ping claiming this is completed |
Certainly looks done: https://matrix.org/docs/spec/client_server/r0.3.0.html#get-matrix-media-r0-preview-url |
We would love to inline URLs in matrix clients like Facebook or Slack does. This means that if someone references a URL in their message, the client would go and display the Open Graph data for it, or perhaps a thumbnail if it's an image/video, etc.
CORS however means that the traffic would have to be proxied by the server, which means that the server needs to provide a helper API to do this. Obviously there are major security issues with giving an API that lets servers make arbitrary HTTP pokes - obvious ones that immediately spring to mind are:
Given this requires a server-side API, we should spec it, even as a (very) optional module of the spec. Given it has zero dependencies on the rest of Matrix, it could be an entirely separate API to CS API, but for now it might as well be a CS optional module.
This sort-of relates to #471 and #92, which hints at ways of attaching metadata within a message to URLs - however, I suggest this issue is kept firmly separate.
This also related to ancient Angular-era SYWEB-179 and SYWEB-34.
The Vector related bugs are element-hq/element-web#437 and element-hq/element-web#184.
(Imported from https://matrix.org/jira/browse/SPEC-295)
(Reported by @ara4n)
The text was updated successfully, but these errors were encountered: