[Standards-JIG] File transfer in MUC

[Mridul]

Ian Paterson wrote:
> Mridul wrote:
>> It will not allow the user to 'attach' a file to the conference - so 
>> that people joining the conference 'later on' also have a way to 
>> retrieve the file.
>>
>> Ofcourse , one way to look at it is , if you were not online when I 
>> tried sending you a file - you dont get it : like in normal case :-)
>
> Perhaps it's not what you are looking for, but one excellent multicast 
> file transfer solution has been available for years...
>
> The client HTTP POSTs the file to a friendly Web server which 
> publishes the file via an unpredictable HTTP URL (during a 
> configurable period of time). The client then sends the URL it 
> received from the server to the MUC room. The other users click on the 
> URL if they are interested in downloading the file. The advantages of 
> this approach include:
>
> 1. It gets through any firewall.
> 2. The sending client only needs to transfer the file once - however 
> many people might receive it (simple clients).
> 3. People joining the room later will see the URL in the history, and 
> can get a copy of the file even if the sending client has gone offline.
> 4. The method can be supported by all clients, even clients that run 
> in constrained runtime environments (like Web clients).
> 5. It is secure as long as https: (SSL/TLS) is used (assuming the MUC 
> room and the HTTP server are secure - although those may be big 
> assumptions to make).
> 6. Almost every client already supports XEP-0066.

This is applicable to any file transfer solution other than ftp ... 
always host on ftp server , send the url across - practical ? Not always.
I do understand the reasoning - and I mention this as a possibility in 
one of my mails in the thread (just send the uri to conf after hosting).

The intention here is , how to send a file to all participants with 
minimum of additional infrastructure requirements.
For example , requiring to have a fileserver on a publically accessible 
internet (the users could behind different firewalls) when user wants to 
share a file with 3 contacts in a muc is stretching things a bit too 
much :-)

There is a requirement which comes up time and again of doing file 
transfer to all participants in a muc - which is a logical extension of 
having file transfer in a 1-1 chat.
The problem usually is that one of the users would not be using our 
client , and we run into issues. So if there is a documented way of 
initiating file transfer on a conference, it would be great.
You can use muc as a middleware for multicast - in which case , standard 
way to transmit binary content would be nice.

By the way , the muc spec hints about possibility of attaching files to 
the conference - I did not see any proposal on this : did I miss something ?

>
>>
>>> However, in the long term, I think we should use
>>> Jingle/ICE/Psuedo-TCP/S5B/IBB/UPnP/whatever-it-takes to create a p2p
>>> mesh that could transfer files using a BitTorrent [1] style algorithm
>>> wrapped in XEP-defined control channels. The MUC room would also take
>>> part in the torrent and take the role of the tracker and probably a 
>>> long
>>> term repository and policy enforcer.
>
> The long term might look something like that. But IMHO we've got an 
> excellent simple short-term solution already.

The short term solution is not practical except for a small subset of 
usecases unfortunately ... and you are expecting an 'enlightened' user 
(or a client which also uses webdav (and the like) to post content to 
public server and then publish that uri).
Actually , it is not really practical to expect this from most 
users/clients.

Regards,
Mridul

>
> - Ian
>