ircv3-ideas
ircv3-ideas copied to clipboard
ircv3
Media capability
Imagine a MEDIA message, that might look something like this
MEDIA Uzrn4me image/jpeg https://upload.wikimedia.org/wikipedia/commons/4/42/Muzeum_Su%C5%82kowskich_-_Zabytkowy_Witra%C5%BC.jpg
It says the nick Uzrn4me references a some media of the type image/jpeg found at the URL https:/....
I think that this is a compromise over embedding images in the messages themselves, and it can be handled by both GUI clients that might decide to embed media of a known type, or by lightweight clients that might treat it like a notice (Uzrn4me referenced image https://...).
The specific implementation might be up to discussion, like what kinds of URLs should be allowed, are tags required, is a new message type required, etc. I just want to propose the general idea for now.
Clients can already handle embedding images which are linked in messages. How is this different?
Sadie Powell @.***> writes:
Clients can already handle embedding images which are linked in messages. How is this different?
Not every link has to be embedded, and a link by itself has no metadata such as file types. But yes, it is not fundamentally different, just a more explicit way (think of the distinction between the draft/response spec and just mentioning a nickname in a chat. Clients can handle the second case, but an actual response can also be of interest).
An alternative approach might be to add a "embed-media" tag or something like that to private messages.
-- Philip K.
The mimetype isn't very interesting and a client can get a more reliable mimetype just by quickly grabbing the response headers from the url.
Iff the URL has to be HTTP, then yes. But for privacy reasons, I also think it would be preferable to not have to send a request just to find out what is being sent.
You'd probably want to be able to relay some other pre-pulled metadata besides the mime type, such as the file size, and a reasonable file name or alt text (the URL may not reveal the actual file name as provided in the Content-Disposition header), as well as the dimensions (image/video) and duration (video). IRC clients will be hesitant to auto-display images without any context and will be even more reluctant (rightfully so) to contact an arbitrary URL to get this information. Maybe a way to provide or link to a thumbnail (as retrieved from <meta> tags).
If we provide some more information then clients could make some heuristic decisions on behalf of the user (e.g. auto download small images or images of specific types only).
I 100% see the possibilities and the vision -- the lack of standard mechanism of auto-displaying inline images with a really nice user interface abstraction for pasting/attaching them is IMO the biggest obvious gap in IRC's capability set and exists without question on every post-IRC medium. My concern, however, is that I strongly suspect many client devs will be weary of doing anything with this MEDIA message except giving the user a button or link to explicitly opt into seeing the image (no better than simply sending the URL as a PRIVMSG).
I don't know that there's a ton of value in having clients relay that information since, frankly, it seems like a poor idea to trust what another client says in the first place.
Perhaps if it came from the server validating content types, length, etc. before passing the request it could be different, since arguably IRCds have to be more or less trustworthy. But that introduces a small mountain of other issues, and I doubt would see wide adoption.
Assuming anything another client sends is valid/trustworthy is just how we get another flavour of CVE-2006-1067
My concern, however, is that I strongly suspect many client devs will be weary of doing anything with this MEDIA message except giving the user a button or link to explicitly opt into seeing the image (no better than simply sending the URL as a PRIVMSG).
Which isn't nothing. Or do IRC clients already offer to present URLs in PRIVMSG inline?
I don't know that there's a ton of value in having clients relay that information since, frankly, it seems like a poor idea to trust what another client says in the first place.
Generally no, but a client could enable automatic presentation on a per-channel/per-user basis.