[OpenID] AddId! - A useful idea of mine?!
danda at osc.co.cr
Wed Jan 31 22:39:40 UTC 2007
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
> (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.
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.
> 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.
Open Source Consulting
San Jose, Costa Rica
phone: 011 506 223 7382
Fax: 011 506 223 7359
More information about the general