Re: [freenet-dev] Easier reference swapping

On Mon, Mar 05, 2007 at 04:19:33PM -0500, Colin Davis wrote:
> For the record- I still think that reducing the initial connection to 
> "IP:Port and Password", rather than having to exchange a noderef will 
> signing your friends up much easier, and make people more likely to use 
> the darknet ;)

Is it so hard to transfer a file? Don't most IM clients (unlike IRC)
manage to get through firewalls somehow? Admittedly they have no
security...
> 
> -Colin
> 
> 
> 
> Colin Davis wrote:
> > Fair enough-
> > 
> > 
> > I (mis)understood the problem as wanting to make it possible to add the 
> > connections without requiring file-transfers.. I didn't realize that you 
> > were trying to avoid having to download the binary from a central source.
> > 
> > For that, I agree, burnable .zips, and .5-style distribution servlet 
> > pages are likely the best that can be done.
> > 
> > -Colin
> > 
> > 
> > 
> > 
> > 
> > 
> > NextGen$ wrote:
> >> * Colin Davis <Colin-nnQb6z/[email protected]> [2007-03-05 15:49:17]:
> >>
> >>> I'm sorry that I'm being dim-
> >>> Could you please explain how the network topography is exposed? I'm sure 
> >>> you're right, I'm just missing it.
> >> Well, your solution is about shortening the reference. I thought you were
> >> trying to address the node installation/deployment problem without emu/the
> >> mirroring system.
> >>
> >> NextGen$
> >>
> >>>
> >>>
> >>>
> >>> If we have two clients, A and B, who want to talk to one another.. Both 
> >>> are behind Firewalls..
> >>>
> >>> * A calls up B, and tells him "Connect to me, at 11.22.33.44, password 
> >>> 'Bob is a super cool password'"
> >>>
> >>> * B Says sure, and clicks the "Connect to a new client" icon in Fred, 
> >>> enters the IP and Password.
> >>>
> >>> * B's machine starts sending Freenet packets to A, thus opening up a NAT 
> >>> hole to his machine through the UDP trick.
> >>>
> >>> * B then tells A "It's running! Add my computer back. Mine is 
> >>> 22.33.44.55, and the password is 'Donkeys are really cool, and I like 
> >>> the way they look' "
> >>>
> >>> * A adds B's IP and password, and starts sending freenet packets to B.
> >>> * A's machine is now exposed, through the UDP trick.
> >>>
> >>> * B's packets, which he is still sending, get through.
> >>> * A's packets get through to B.
> >>>
> >>> * Now that they're talking, they exchange signed keys (real noderefs), 
> >>> so next time, they don't need to do the passwords.
> >>>
> >>> * Fred disables the passwords.
> >>>
> >>> Nothing has required the use of a third party, other than the telephone 
> >>> call between the two of them to share the passwords.
> >>>
> >>> -Colin
> >>>
> >>>
> >>>
> >>>
> >>>>> When Side-A added the noderef of B, it would start sending out packets 
> >>>>> to B, knowing that they won't get returned.. But the Sending of these 
> >>>>> packets would open a NAT-hole..
> >>>>> Then, Side-B would get around to adding the noderef of A, and start 
> >>>>> sending packets to A, opening a NAT-hole on their own side.. Side A's 
> >>>>> packets then get in through this hole, just as B's now arrive at A.
> >>>>>
> >>>>> What am I missing?
> >>>>>
> >>>>> -Colin
> >>> _______________________________________________
> >>> Tech mailing list
> >>> [email protected]
> >>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
> >> _______________________________________________
> >> Tech mailing list
> >> [email protected]
> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
> > 
> > _______________________________________________
> > Tech mailing list
> > [email protected]
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
> 
> _______________________________________________
> Tech mailing list
> [email protected]
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
>

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7KGZA9rUluQ9pFARAjbKAKCoBkgTixBUbO97ZFwF6FSdwpkzHACgvfVx
FHWGnNmiaBF4Z8J4zToTKLA=
=7iHM
-----END PGP SIGNATURE-----