[JDEV] File Transfer Proposals

[David Sutton]

Hello,

On Sat, 2002-02-16 at 03:25, Moz wrote:
> 
> Some minor thoughts on details of David's idea.
> 
> David said:
> >  My personal belief is that peer-to-peer connections open up
> >  a whole world of problems, such as firewalls and interconnectivity
> >  between different clients. 
> 
> Flip side is that hosting files opens its own can-o-worms, not least
> because of the copyright issue. There's also bandwidth and storage,
> which could get annoying. I'm more concerned about cease-and-desist
> letters from the RIAA though.
>
This is true, and I tried to address this with the idea of being able to
redirect a user to a different storage server.

As for the RIAA, that is a legitimate problem which may put people off
of a solution like this. Its hard to get the balance right.
 
>
> Peer to peer transfers can be intermediated at a peer level if
> required, using free email servers if nothing else. I am not sure
> that we actually want to build in a violation of the systems that
> ISPs use to stop their users being silly (for whatever definition
> of silly applies). Clueful users will already tunnel whatever
> they want through whatever holes exist, and opening a gateway
> for less experienced users might not be good.
>
Its not always security which dictates such practices. "Real World" IP
address ranges are in short supply, which is what NAT and subnetting was
designed to handle.
>
>
> That said, if someone who is actually willing to do the work wants to
> build this, I'm not opposed to them doing it. It could be the thing 
> that makes Jabber wildly popular with the existing IM users. But I 
> would want to be able to disable it in any server I'm running, just
> to keep costs sensible.
> 
The thing is that it is an external component, not a part of the server.
The further away from the server and the xml stream, the better. Its
like transports, if you don't want to run them, you don't have to and
the system works quite happily.
>
> >      - Upload -
> >      If the file already exists, there is no need to upload the file again,
> >      the user is simply added to the ACL, and given an expiry time. 
> 
> ?? if they don't need to send the file again, why put them in the ACL?
>
Take the idea of a person sending a file to 5 users on the same server.
You upload the file once, and then just have a single ACL containing the
5 users. As each user collects the file, they get removed from the acl,
until it is empty and the file gets deleted.
 
> Terminology too - perhaps consistently say "the sender sends the file"
> even if it doesn't parse too well, just to keep it clear?
> 
Sorry, the continual changing of trains and buses makes it hard to keep
a single thread of thought going :)

> >      - Download -
> >      The receiver sends a 'request to download', consisting of the
> >      filename, size and md5. This, along with the ACL stored in the
> >      files database record, help form a basic protection against files
> >      being downloaded by the wrong person. Its not perfect, but it is
> >      functional without requiring unstandard extensions. 
> 
> Random, single-use URIs would be a tiny improvement. IMO, since we're
> working on top of IM/chat, we can work on the basis that everything
> happens "now", or close enough to. I'm not sure that accepting offline
> users will make a huge difference to usability, at least IME most
> transfers are "hey, here's the file".
>
If you want to give out a file to multiple people, and keep track, then
its best to have an easy identifier .. in this case three .. a little
excessive maybe, but then again I like things in threes sometimes :)
  
> 
> Moz
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

Regards,

  David