[foaf-protocols] [FOAF-SSL] XRI, WOT, Alternate transports, Server security, Naming, DNS support

thib thib at stammed.net
Thu Apr 15 01:20:00 CEST 2010


Story Henry wrote:
> Well that's a bit my attitude. I am pretty sure we can work together if they take off, but
> it is not worth me reading all the work they are doing ( yet ) because we have enough
> on our plate here already :-)

Yep, I understand.  It'd be great if some people from the XRI community 
would come here and participate in the development of WebIDs instead, since 
most problems seem similar, they may have solved some in some way already.

> [snip]
> 
> RDF with linked data is also about discovering new resources. RDF is among 
> other things a Resource Description Framework, or also a Relational Description
> Framework. From your WebId I can discover your friends profile.
> 
> RDF is based on graph theory and logic. The level of abstraction is so high
> that you can express anything. It's about semantics. So if XRDS makes sense,
> then it shoudl be possible to write an RDF ontology for it.

OK, this is reassuring for my little mind.

> See the GRDDL spec.

I will, thanks.

> [snip]

About the whole WOT thing, I realized I wasn't looking at the big picture, 
even though I thought I was.  You changed my mind about this, there's really 
no issue, and that web will actually be quite close to representing "trust" 
as it should be;  very naturally that is.

Now I feel I wasted a bit of your time with this, I'm sorry.

> [snip]
> 
> It is not necessarily duplicated. It is usually preferable to link to other 
> resources. Think about writing a web page, and linking to your friends. Do
> you really want to make a copy of their web page, and maintain what they are 
> saying? It is clearly easier just to link to them, and let them work on maintaining
> facts about themselves. (If you are paranoid you could keep a cache of
> everything they say)

Yes, so it's a choice.

>>  This is in contrast 
>> to PGP-style WOT where that information is at one place only, but 
>> cryptographically signed by the relevant people.
> 
> It is not really in one place :-) It is in one signed document, that is
> copied all over the place. Hence the difficulty updating it, I think.

Yes, I wasn't very clear;  I just meant it was in "one authoritative place" 
(even though that's still ambiguous), or, as you put it better than me, in 
one document.  Well, we're on the same wavelength.  ;-)

>>  This saves space, since we 
>> don't duplicate the info -- if many people trust it, then they just sign the 
>> same data (a name/email, a photo).  The problem is that people cannot 
>> *create* information about other people, they can just approve information 
>> created by the concerned people only.
> 
> yes.

And again, FOAF leaves that choice open.  So both "WOT styles" are needed, 
they just serve their purpose in different ways.

> [snip]
> 
> My thought is that you add the above to your foaf. Then when someone write
> about you using the webid, they can find the ping page (in html it would just
> be a form), and post the URL that is talking about you thtere. Very simple, and very 
> RESTful.

Yes, that's nice.  Is there a standard way to write these POSTs, so one can 
use a client of his choice instead of the individual HTML forms?  (I'm sorry 
my knowledge is very limited, I'm not sure where to search for answers to 
questions like this one.)

> [snip]
> 
> The web seems to function quite well :-)

You're right.

> [snip]
> 
> Only if http broke. Just keep you old web server up, start your new server, and link them.
> So perhaps ftp is the protcol of the future. Then just 

Yep, how unlikely, I know..  it's all very theoretical talk.

> <http://bblfish.net/#hjs> owl:sameAs <ftp://bblfish.net/doc.rdf#me> .

That would certainly work, but you'll still want to push the change to all 
your contacts, which is very slow.

Again, I know this has no real practical use, I'm not a SPDY believer 
myself, but just because it's possible to abstract this seems to me that in 
some way, it's the right thing to do.

And also because we can't really trust the far future, ever.  :-)

> [snip]
> 
> URLs are URIs. IF you keep changing the location of your web documents, 
> you are going toloose a lot of people. Notice how http://google.com/ has 
> been around for a long time?
> 
> Some people don't seem to understand this. Le Monde changes the URL of 
> its documents after publishing to an archive, and makes it very difficult to find. 
> It's not surprising newspapers are looosing so much in the web world. But in this
> case it's their own stupidity that is the reason for that. And I suspect this is
> often the case.

I agree, and Toby Inkster's vocab seems really nice to help with this.

> [snip]
> 
>> (I probably just feel the problem is not at the right place, but I might be 
>> completely wrong.)

That didn't change, however.  To illustrate my thoughts, I'd go with a 
simple example:

An organization might be providing WebIDs one can look up with this URL:

   http://a.org/<webid>

The organization expands, after say.. ten years.  Something that was 
completely unpredictable at the beginning -- they didn't think they would 
ever do something else than ID providing, but hey, they do now, and they 
don't want to miss the opportunity they have.

They need that namespace.

They now have to add a subdomain, or put the WebIDs a level deeper.

But would you still think that they're stupid?  I think they even did the 
right thing at the beginning;  why would they unnecessarily clutter the URL? 
  That kind of anticipation sometimes can't happen, ten years is already a 
very long time for this kind of planning, IMO, but we could add more years 
to the example to get to the conclusion.

It's a problem that, in a theoretical sense, cannot be solved with URLs, 
because IDs are not locations.

Now, even if they did add an "id" subdomain from the beginning, why would 
that be necessary for the lookup clients?  In this example, the client knows 
he wants to get an ID which is global to that organization.  If there were a 
special protocol to look up IDs in place of HTTP, stating "id" anywhere 
inside the ID itself would be simply redundant and useless.

So, in the end, my point is this:  this limitation (using URLs) is 
artificial.  It makes things easy, and is thus great, but I think someone 
willing to put minimal effort in this should have the choice to be able to 
lift that limitation (choice is always good).

(BTW, I think purl.org is an artificial answer to this artificial problem. 
It is needed, but only if we want this setup simplicity.)

I'm not re-inventing i-names (even though they seem like another answer), 
because I'd like to use an infrastructure that's already in place for a 
long, long time:  the DNS.  It could be anything else, and the choice for 
that should also remain open if possible, but DNS looks perfect for this.

Practically, this would simply mean adding a record type to the name servers 
willing to support this, and detailing the standard lookup method in a spec 
(which would merely be stating anything, redirecting to the DNS spec all the 
time).

Again, the record could point to any server.  We could either:

* Select a mandatory protocol to retrieve the WebID or
* Invent a protocol to negociate the transport protocol.

As we discussed, selecting HTTP is fine, but the negociation is just so 
simple..  should we ignore its potential?  (this is not rhetoric, I'm asking 
for opinions).

URL namespace issues are thus not a problem anymore, and with the second 
solution, even people experimenting with shiny things like SPDY could make 
the switch for their WebID, all in absolute transparency.

Oh, and there could be many ways to represent the WebIDs now, but we could 
just point to the email spec (which is perfect for this) so we still follow 
the "don't re-invent" philosophy.

Ambiguity for clients supporting any method could be easily solved by a new 
URI scheme.  How about:

   webid://thib@a.org

or

   wid://thib@a.org

Even if you don't like the whole idea, you have to admit it, it's sexy.

>  [snip]

-t


More information about the foaf-protocols mailing list