cohost support

While I would love it if Cohost was willing to mirror anything I link, the big problem with this proposal at present is that it means there would be no way whatsoever to display an image larger than 10MB. 

"a post can contain images hosted on cohost"

A post can, but I don't think a comment can? Whereas you show an external image in a comment.

There'd be no way to display it in-line, yeah, but you could link to an external site. Considering the typical size of a cohost post, that doesn't feel very restrictive to me? It only has to be roughly 600x600 pixels, or for high-DPI 1200x1200. I think 10MB is more than enough to get a beautiful image within that space.

there have been a number of posts in months past that used dynamic content to create "cohost plays" and widely editable shared boards, so i don't think disabling the ability entirely to source images from off site is a good idea

perhaps a warning when posting, to let people know there's a better way for static images?

Disagree with this because it would prevent people from reposting/linking to images on their own websites, and because cohost's upload limits are (understandably) quite small.

It would also force everyone to only use Cohost's fixed layout and limit of four images or else use the very goofy workaround method to grab the URLs and add them.

That will be ameliorated later when the image UI is improved, but I would still strongly prefer to have the option to embed my photos from flickr when I want to. Not every embed is an illicit hotlink.

This would disable anyone's ability to build anything along the lines of "Cohost Plays Pokemon" again.

• Privacy: I think this should be easily dealt with by making external embeds be something you have to manually click to load. This goes for all HTML which would cause external assets to be loaded. There's already the option to load content previews with iframely in our user settings, so I don't see why we can't extend that concept to all external content. Also, FWIW, while modern web browsers are definitely not set up for user privacy, most of them can be configured to not load content from third-party domains using something like uBlock Origin.
• Bad netiquette: site owners can disable requests that are not loaded as part of a request for their own page, so while this might be bad for hobbyists with enough free time to run a site (with user-uploaded content or otherwise) but not enough time to implement such a check, I think in general the web has moved past the era where this was a major problem, even photobucket. In fact, external hosting is critical for people seeking to embed large files without imposing on cohost's own servers. If it's a real problem, then restrict people to only using embeds from well-known domains that definitely will never have the bandwidth issues, as well as from ipfs gateways and the like.
• Mutability, dynamic content, and expiration: these are kind of two concerns at once, but the first one is something that, in order to avoid detection from cohost moderators, would have to be extremely targeted. It mostly would fall under the realm of harmless pranks (like making an image that's normal art for everyone except for anyone accessing the image from, say, the British Parliament's IP address space, in which case it would show a list of war crimes committed by Britain in Ireland), with the occasional case of true malice, like someone trying to exploit a zero-day vulnerability in a browser loading PNG metadata or something and avoiding immediate mass detection by only serving the malicious payload to a small percent of users (which I guess is actually a good reason to be wary, but would be solved by the same solution as I outlined when talking about privacy concerns.) As for expiration... well, that's the tradeoff that you have to take. If a file is too big to fit on cohost's servers, you have to link to it anyway, so you might as well link it in a way that lets it be part of the content.
  

One cool thing Github does with its markdown viewer for Readme files and the like is let you embed images from wherever you want, but it silently reuploads them to its CDN and serves those instead. Such a behavior could also be bypassable by not doing that to images that include a question mark serving as a delimiter for parameters (adding a question mark to a static URL is generally supported by all http servers)