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.

[lf94]

I want to say MASSIVE thank you @emersion for implementing FILEHOST in soju. I originally came up with this solanum-ircd/solanum#314 and had val write that proposal because it is such a glaring hole in the protocol and wanted someone who's written IRC specs to write us (the world) a good one. I was hoping solanum could implement it, but they haven't. Thank you thank you THANK YOU for moving the needle!

[lf94]

@GIJack I have tried file transfer over base64 on IRC. It sucks. It's slow. In no way practical other than for small files.