And so says Peter Amstutz on 27/03/06 12:46...
> The solution is to completely re-think how a remote site is identified,
> and I will discuss this in my next email.
Cryptographic key pairs? (Which would then also open up the field to
encrypted payloads when we deem them necessary?)
So A can refer to B by whatever address; before C even tries to resolve
the address, it will first check in its sitecache if there is any site
with that same public key.
And/or, if C "knows" it's in a privileged network (gigabit, behind
firewall, etc), and the cache misses, it can try service discovery next,
and only if that also fails, revert to DNS.
=======================
Funny, that kind of ties into one other thing I have been thinking. It
is quite possible to have a VOS-based "directory" service, comparable to
DNS. You could configure on your client machine the address of your
preferred pointer site, just like you configure your DNS server.
A record could be just a PCR to a remote object. Or even better, a
Vobject containing the remote PCR, but also some metadata. If a site
goes down, it can signal the pointer that it's inactive, and the record
can be flagged as such. If it comes back under a different address, it
can update the pointer.
Like DNS, the pointers can network and distribute information. The
authority to update data could then be purely cryptographic -- when a
site sends an update, it also sends a signature. But pointers may also
have rules like "records with addresses matching 10.0.0.0/8 should only
be shared with pointers whose address also matches this mask".
The pointer site works based on two objects on the site root:
"pointer:alias" and "pointer:key". The latter is a flat listing, where
contextual names are the crypto keys of sites -- and this is what would
be used to resolve most remote PCRs, for example.
The "alias" object is the root of a hierarchic "human-readable" alias
tree, more akin to DNS; interreality could be at
"/pointer:alias/community/freesoftware/vr/interreality", but also at
"/pointer:alias/community/freesoftware/objects/vos".
Then we could refine VIP URLs:
vip://foo.bar/fnord is a DNS-based URL at host "foo.bar". The same
notation is used for raw IP: vip://10.0.0.23/fnord
vip:{dsa}5103581E58E743BC4D30624A73E36EB01A4F3D49/fnord is a key-based
URL, pointing to the server with that key.
vip:/community/freesoftware/objects/vos/hubworld//fnord is an
alias-based URL pointing to the object "fnord" at our "hubworld" server.
vip:/community/freesoftware/objects/vos/hubworld/fnord is equivalent;
since the "hubworld" object in the alias tree doesn't have a child named
"fnord", it's assumed to be an object. But if we later happen to evict
this object into a separate server, the URL remains valid. (In fact,
I'm tempted to claim that the "//" separated URL above doesn't really
need to exist.)
Then in the documentation we encourage people to just type
"/community/..." on the address bar (for the power users who will bother
to use it), and that will be interpreted as an alias URL...
Heh, to the basket with semantic web, this is semantic DNS ;-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical: http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
