[E-Lang] VLS for everyone

[Tyler Close]

MarkM wrote:
> >What exactly are the issues with firewalls that are
> related to the VLS
> >service? I really can't think of any. [...]
>
> You answer your question below:
>
> >The place where firewalls do become an issue is when the
> client tries
> >to use the fetched address information to contact the target host.
>
> That's the issue.
>
> >I think we can and should ignore this step in the definition and
> >implementation of the VLS service.
>
> I admit to failing memory of the old httpy discussions, but
> I am mystified
> by this statement.  The purpose of the VLS is to bring
> about Granovetter
> introductions.  If the VLS reports to VatB an address for
> VatC that VatB is
> unable to use to contact VatC, what good has the VLS done
> anyone?  It would
> have failed at its one purpose.

I was hoping to answer this email with a proper SLS spec posted on the
waterken.com site, but it's probably going to be a few more days
before I have time to do this.

The basic idea is that the SLS is just a string lookup service. You
give it a string and it gives you back a list of strings.

This SLS could fulfill the VLS role and many others. As a VLS service,
the input string would be the string representing the hash of the
site's public key. The output would be a list of:

	<scheme>://<ip-address>:<port>

So if a web browser had a URL like:

	httpy://1234567890123456789012;207.218.152.136/index.html

It would send "1234567890123456789012" to the SLS port at IP address
207.218.152.136. It might then get back:

	http://213.219.58.71:80

Which it could then download the HTML from:

	http://213.219.58.71:80/index.html

There would have to be a set mapping from SLS protocol names to
current protocol names. I think just appending a 'y' to any current
URI scheme should do. The 'y' is to represent the granovetter
operation that is being facilitated.

Adding an entry to the SLS
--------------------------

To add an entry to an SLS, you send 2 strings. The first is the
"archash" (same idea as in our reference pipelining technique), and
the second is the lookup key. If the key does not yet exist, then it
is added to the VLS with an empty string list. The modifier facet for
this list is placed at the address indicated by the archash. This
modifier facet would have methods for "add", "remove", "delete".

I think this technique is simple, and prevents all attacks, except for
DOS attacks on the SLS server. Individual SLS servers would augment
this basic "sign-up" protocol with payment requirements and/or
time-to-live information.

Making the connection
---------------------

If you are behind a firewall, then its up to you to register an
address with the VLS that other sites can use to contact you. It's
likely that this is not possible for some firewall configurations. If
this is the case, then some other service, not the SLS, could offer a
man-in-the-middle service to enable connections. You would then
register the address of the man-in-the-middle with the SLS server.

Possible uses
-------------

All of E, Droplets, Mojo, ToonTalk, ... have a need for the service
offered by the SLS server described here. I believe that these
services then diverge in their requirements after the name lookup part
of the connection. I think the name lookup service is valuable enough
it its own right to be a separate reusable product.

I'd also note that the SLS also has the potential to be a
capability-based alternative to LDAP.

Open Questions
--------------

I want to make sure that the SLS can be used to communicate onion
routing information. I want to do some more reading on this before I
write up a proper SLS RFC. If anyone wants to suggest some material,
I'd appreciate it.

Tyler