[OpenID] AddId! - A useful idea of mine?!
chris.messina at gmail.com
Thu Feb 1 07:11:10 UTC 2007
I strongly advocate for using XOXO, xFolk, hcard and XFN here.
We've had a lot of conversations about this stuff lately and I think
are starting to make some headway -- more *new* technology is not
needed as you'll adoption severely lacking. Working with existing
technology as a primary principle is essential.
I created a demo hcard on my delegated OpenID:
It's extremely basic, but serves as a model for capturing the type of
data you're talking about. You could even conceal things on that page
(like personal relationships) that are only revealed to consumers
against whom you've authenticated.
Anyway, would love thoughts and feedback -- and to avoid coming up
with any new technology unecessarily.
On 1/31/07, Dan Libby <danda at osc.co.cr> wrote:
> 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
> instead of "I claim I know Sally as a contact". So what I did was to
> 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
> general mailing list
> general at openid.net
Citizen Provocateur &
Open Source Ambassador-at-Large
Cell: 412 225-1051
This email is: [ ] bloggable [X] ask first [ ] private
More information about the general