search

ircv3 / ircv3-ideas

46 stars 3 forks source link

File upload #100

Open emersion opened 1 year ago

emersion commented 1 year ago

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:

slingamn commented 1 year ago

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 commented 1 year ago

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

nektro commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 5 months ago

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

GIJack commented 5 months ago

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.