File upload

[emersion]

On many messaging platforms, the server provider is also responsible for providing a way for clients to upload attachments. This removes the need for clients to maintain/pick their own upload service.

@progval has written a proposal: https://github.com/progval/ircv3-specifications/blob/filehost/extensions/filehost.md

Prior art:

• https://xmpp.org/extensions/xep-0363.html
• https://spec.matrix.org/v1.3/client-server-api/#content-repository

[slingamn]

Some ideas that have come up before:

1. I think the 005 token should point to an extensible metadata JSON file, rather than the bare upload endpoint
2. It's worth thinking a little bit about authentication up front (I like EXTJWT for this, but other people might think differently)
3. One of the functions of this should be to specify an image hosting domain (not necessarily the same as the upload endpoint domain) that is trusted for image auto-fetch (as in, no less trusted than the ircd from an IP address privacy standpoint)

[slingamn]

Also, large uploads will require resumeability, for which there's https://tus.io/

[nektro]

it would likely be easier for clients to support something akin to https://getsharex.com/docs/custom-uploader and then send the url to the chat

[GIJack]

No. It would be better all around if file handling gets done in band. The ONLY way to do this with IRCv2 is with DCC, which is between clients.

On the modern internet, clients don't and shouldn't expose IP addresses directly to eachother. Also, because firewall rules, IRC should handle everything in band.

[SadieCat]

Please be realistic. There is zero chance of any implementation adding in-band file transfers. Any in-band transfer will block the client connection until it is finished and will require some overengineered escaping system as IRC messages are inherently text-based.

[emersion]

soju + goguma now support this spec: https://git.sr.ht/~emersion/soju/tree/master/item/doc/ext/filehost.md

[GIJack]

Please be realistic. There is zero chance of any implementation adding in-band file transfers. Any in-band transfer will block the client connection until it is finished and will require some overengineered escaping system as IRC messages are inherently text-based.

By overengineed escaping system, you mean base64, which has been a standard for encoding binary data in text-only streams for decades now.

Shit, I am pretty sure you could probably define this as another ctcp sub-protocol with base64 encoding for data, and some basic signalling for start/stop/meta for things like file length and checksum. You could also probably use ctcp to negotiate checksum.