[uf-discuss] Re: XFN for email addresses?
chris.messina at gmail.com
Fri Jun 15 12:46:01 PDT 2007
On 6/14/07, Ryan King <ryan at technorati.com> wrote:
> > I agree that the lack of transitivity with email "endpoints" make them
> > very weak from a claims perspective, and I agree that we can do
> > better, but given that Technorati and the like still require a
> > verified email address to open an account, I don't see this behavior
> > going away anytime soon.
> Technorati does not require a verified email address.
My bad. I presumed that to sign up for a Technorati account, which you
can use to claim other URLs, you needed to verify an email address.
> > One goal of mine to develop a replacement for those "add friends from
> > your address book" widgets, which are so seductive and therefore so
> > dangerous. People are being trained to enter their email and password
> > on almost every new social network; in the case of Gmail, that
> > username/password combo access far more than just your mail (think:
> > Google Checkout, web history, etc). This is extremely dangerous. If we
> > could instead train people to type in a URL-pointer to their list of
> > friends, authenticate remotely, and then pull down the list of
> > contacts, including email addresses as necessary, we'd have a much
> > safer social web.
> I agree that this is a Good Goal (tm), but that doesn't mean that XFN
> alone is the way to do it. In fact here's a better way:
> 1. User enters url (possible OpenId enabled) to a page that contains
> their contact info and XFN data.
> 2. The XFN data (rel-friend, rel-colleague) is used to find the list
> of people to import
> 3. Use rel-me hcard uid, etc to find contact information for the
> people on the list.
> 4. Import the contact info you find.
What this leaves out, however, is the ability to contact people
programmatically, say, to invite or add them to a new social network.
It's my opinion that the URLs that I lay claim to should not
*automatically* be added to social networks as accounts without my
Therefore, I agree with your steps, but there needs to be a 5th step,
which to communicate an invitation to the contact information
discovered: in the case of email, the contact transport is obvious; in
the case of URLs, the contact mechanism is not clear or does not
currently exist in the wild.
For example, let's say that I have an OpenID and on the end of it is
an hcard with rel-me links to my Flickr, Last.fm and Technorati
accounts. No other "contact" information is given. You would like to
invite me to NewFoo, the latest and greatest social network, and since
my OpenID turned up on your OpenID as a rel-contact link, NewFoo has
discovered my whereabouts. Now, I don't want you to be able to
automagically add me as a friend on NewFoo, but I wouldn't mind being
invited, and at that point, NewFoo needs to offer a mechanism for you
to contac me at the URLs that I've made publicly available.
If I've added you as a rel-contact on my OpenID endpoint, then perhaps
you should be able to send me an invitation through some
yet-to-be-invented OpenID messaging transport  that will arrive in
my non-email OpenID Actions Inbox as a decision to make (as opposed to
a message to be responded to): "Ryan has invited you to NewFoo. Cancel
Upon allowing, a message would be sent back to NewFoo from my OpenID
provider indicating my acceptance of your invitation, at which point
my URL could be listed on your friends list as a rel-contact with all
the conveyances and benefits that that might afford.
Anyway, this is a long way of explaining how OpenID-enabled friending
would work, riding on a layer of XFN and a yet-to-be-invented (perhaps
Jabber?) messaging transport over OpenID.
At the least, this is what I think would come after your step #4 (and
interestingly also addresses some of Pelle's concerns).
Citizen Provocateur &
Open Source Advocate-at-Large
Cell: 412 225-1051
This email is: [X] bloggable [ ] ask first [ ] private
More information about the microformats-discuss