[OpenID] AddId! - A useful idea of mine?!

Dan Libby danda at osc.co.cr
Wed Jan 31 22:39:40 UTC 2007

Hi Lukas,

On Wednesday 31 January 2007 16:06, Lukas Rosenstock wrote:

> I try to comment on all this thought with an example: Imagine
> videntity.org supported AddIt/AddFriend. A videntity user now logs onto
> LiveJournal with his OpenID. LJ parses the XRDS of the videntity user
> and provides me with a link, let's just call it
> http://videntity.org/addrelationship?url=http://thisuser.livejournal.com/.
> (Noticed something? Currently the parameter is called identity, if it
> was url videntity.org was already have an AddId-compatible DC). The page
> I see lets me set the relationship values. It wouldn't make sense for
> "thisuser" to preset it, because I want to describe the relationship
> myself, don't I?

Short answer: I think that in this type of case you can present the pre-set 
XFN values to the user, and allow them to use them as-is, or modify them.  I 
think that the common case is that XFN relationships are bi-directional 
( kin, sweetheart, contact, friend, etc).  So it's a pity to throw that data 
away if it is available.

Longer answer:
It's funny you should bring this up. I was dealing with this issue just this 
morning. I added the capability to import XFN contacts into videntity. I ran 
into the case where sometimes a page (eg Videntity profile pages) will have 
incoming claimed relationships, ie:  "Sally claims she knows me as a friend", 
instead of "I claim I know Sally as a contact".  So what I did was to present 
the relationship that Sally claims as the default, but allow the user to 
easily change it, or even exclude the relationship.

Further Commentary:

> Again, for bookmarks, we don't need anything more than url, because all
> meta data can be retrieved from it.

But what about *my* meta data?  Perhaps I have created a personalized title 
for the URL that makes sense to me. I may have added keywords, or written 
some notes about it. Certainly both del.icio.us and firefox bookmark manager 
let one do these things.

>  > 4) As this seems to be a fairly generalized framework for transfering
>  > disparate formats, why not make it truly general and extensible,
> possibly via
>  > mime types or xml namespaces...
> There is the namespace of AddId data types. For my first draft there are
> seven of them and the list is extensible. However, since they are not
> URIs (which is again, to keep them short), the namespace is in control
> of the entity that "owns" the spec (which would be me, currently).
> Another possibility would be not to write a spec but only a design
> principle so that everyone could define their own Yadis Service Type.
> For the data formats, AddId is already built on standards. Either a URL
> is given or a Base64-encoded data file, which is in well-known formats
> (like vCard/vCal).

Right. So that's why I suggested mime as a possible way for enumerating 
well-known file-types, without having to update the spec for each one.

Dan Libby

Open Source Consulting
San Jose, Costa Rica
phone: 011 506 223 7382
Fax: 011 506 223 7359

More information about the general mailing list