search

glitch-soc / mastodon

A glitchy but lovable microblogging server
https://glitch-soc.github.io/docs/
GNU Affero General Public License v3.0
680 stars 180 forks source link

Add support for inline-images when using markdown or HTML #1644

Open draedr opened 2 years ago

draedr commented 2 years ago

Pitch

It would be nice if, when using markdown or html if the images instead of being converted to links, were to be showed inline instead.

A basic implementation would just be changing Redcarpet's no_image settings to false (app/lib/formatter.rb > function markdown_formatter), and changing Formatter's format function to call reformat if the content_type is neither html or markdown (app/lib/formatter.rb on line 63 by putting a ! before %w).

This would be pretty basic and raw implementation thought, because if the user uploaded a media_attachment, it wouldn't be able to add it inline, and if it could, it would have two copies: one in the content and one in the lightbox/gallery.

Motivation

It would allow to make toot like tumblr, for example on all those instances that allow long posts.

ClearlyClaire commented 2 years ago

My main issue with that is that without server-side proxying/caching, we would be leaking info about local users, as it would issue requests to an arbitrary target. And currently, glitch-soc does not have an appropriate proxying/caching mechanism (media attachments are their own thing, we can share some code with that, but it would involve writing new models, database tables and controllers anyway)

draedr commented 2 years ago

I'm sorry, could you elaborate further? I'm not really expert with the proxying part. Which arbitrary target would request?

ClearlyClaire commented 2 years ago

changing Formatter's format function to call reformat if the content_type is neither html or markdown (app/lib/formatter.rb on line 63 by putting a ! before %w)

This would allow arbitrary HTML in toots which is an obvious security issue.

I'm sorry, could you elaborate further? I'm not really expert with the proxying part. Which arbitrary target would request?

If you allow inline images, the images will get loaded by the client. If we do this, we need to rewrite the target of those images to use a proxy/cache, otherwise the hoster of those images will know the IP address of people seeing the post as well as the time they displayed it, which is a privacy concern.

draedr commented 2 years ago

Oh i see, really thanks for the explanation.

This would allow arbitrary HTML in toots which is an obvious security issue.

Then it would be a matter of modifying the formatter to allow tags.

If you allow inline images, the images will get loaded by the client. If we do this, we need to rewrite the target of those images to use a proxy/cache, otherwise the hoster of those images will know the IP address of people seeing the post as well as the time they displayed it, which is a privacy concern.

I see. A partial work-around for this would be, instead of adding images manually, uploading them as media-attachment and using that url, but as i wrote before, i would end-up with two images displayed unless hidden via javascript. But you would still be able to add one manually, so it would be needed to either reformat all images whose domain isn't the same of the instance as links, or allowing external images, but i can see that this may not be wanted, unless like, adding a whole option to the server.

There could be a way using only media-attachments , for example using their ids inside of the url when rendering, and replacing it with the lightbox on the client-side, but that may break in federation maybe.