[JDEV] [Fwd: Cool idea! (Jabphone ;-)]

[David Waite]

-----Original Message-----
From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org]On Behalf Of Marty
Saxton

>I'm a relative newbie to jabber, so forgive me if I'm re-hashing old
issues.  I think we
>all agree that "Presence" is the key to a wide range of peer-to-peer
appliciations beyond
>instand messages (e.g., voice over ip, video phone, file sharing, peer
hosted games).
>The problem is that all these application result in binary data that can't
(efficiently)
>be pumped through the existing jabber client/server[/server]/client xml
stream.  Is there
>anything in jabber (existing or proposed) that can facilitate direct
peer<->peer
>connections?  I can think of two problems that need to be addressed:

The primary way to do peer - peer communication in jabber (At least at this
point) is Out of Band transfer. Content will need to be exposed both via
location (URI, such as the URL of a web page) and desired handling (for http
example, load in browser, save as file, handle with X program, etc).

>1) The security risk of exposing your IP address to others.  It requres a
greater level
>of trust between peers to expose IP's to each other.  At the very minimum
"expose IP to
>peer" must be a standard jabber option for each peer in your roster.

Exactly. Peer to peer communication requires the user to indicate that that
user has a higher level of trust, either as a configuration option or via a
popup warning dialog.

>2) Firewalls (IP masquerading, NAT, PAT, whatever):  two peers both behind
firewalls
>generally can't establish a direct peer to peer connection.  Has anyone
proposed a
>generalized peer<->proxy<->peer solution for binary data?

There is never a generalized solution for binary data. The best you can get
is to say that it is out of band, and that the protocol and the non-jabber
clients using that protocol can figure out a way to get around this problem.

For file transfer, for instance, it would be possible to expose the file via
a http server which basically is a port redirector running on a remote
machine. You could also just send a URL to the file rather than sending it
using your own bandwidth - for a large program you could send them the
download URL from the program's homepage, or you could upload the program to
publicly accessable webspace via ftp/webdav/whatever.

-David Waite