Really Simple People

Posted to the social-network-portability mailing list, December 14, 2007.

Ben Werdmuller wrote:
<blockquote>
I would argue, strongly, that user data needs a more flexible,
permissive format: an RSS for people, rather than something rigid and
RDF based. Where it makes sense to add extra format detail to a field,
like locations or contact details, it should let you do so. But no
data should ever be rejected because it doesn't fit into the model.
</blockquote>

Seconded. This domain is becoming needlessly complicated.

I have argued in the past for a 'Really Simple People' format. RSP.

Here's one:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<person>
<name>Stephen Downes</name>
<email>stephen@downes.ca</email>
<url>http://www.downes.ca</url>
<OpenID>sdownes.livejournal.com</OpenI>
<rss>http://www.downes.ca/news/OLDaily.xml</rss>
</person>

This file should be located in some obvious places. If you have an OpenID, for example,

sdownes.livejournal.com

put it here:

sdownes.livejournal.com/person.xml

or put the address in the head your home page (http://www.downes.ca) here, right beside your RSS:

<link rel="alternate" type="application/rsp+xml" href="http://ideasandthoughts.org/feed/" />

and in your RSS file, put it in the head (as the author of the feed) or the item (as the author of the item):

<item>
...
<author rsp="sdownes.livejournal.com/person.xml" />
</item>

or put the OpenID in the same place, since it leads to RSP

<item>
...
<author OpenID="sdownes.livejournal.com" />
</item>

this is dead simple and introduces agency to the (semantic) web. Numerous graphs can be generated by tracing connections between resources and authors and back again. Friend list can be *derived* from such agency, rather than explicitly created.

But if you want to create friends:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<person>
...
</person>

<fiends>
<friend rsp="sdownes.livejournal.com/person.xml" />
</friends>

or

<fiends>
<friend OpenID="sdownes.livejournal.com" />
</friends>

If you wish, you can add a typology to friends. Some examples:

<friend OpenID="sdownes.livejournal.com" relation="family" />

<friend OpenID="sdownes.livejournal.com" type="best friend"/>

<friend OpenID="sdownes.livejournal.com" topic="knitting"/>

That's it. That's the whole of the specification.

Oh, sure, you could add some obvious fields to RSP, like:

<address>
<home phone>
<fax>
<gender>

and the like. There's no reason to be really precise about this list, especially at first. See what falls out in actual usage.

And additionally, it would be possible to extend the specification using namespaces, just likie RSS. So you could add API for messages and comments, iTunes playlists, more...

<?xml version="1.0" encoding="UTF-8"?>
<rsp version="1.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:dtvmedia="http://participatoryculture.org/RSSModules/dtv/1.0"
xmlns:media="http://search.yahoo.com/mrss/"
>

I understand why things in the OpenID space and the social network portability space have become so complicated so quickly. We want to be ale to do a lot, and do do it reliably and securely.

But open and simple should be the default. Don't make the tightly secured athenbtication required etc etc version the default. Even simple things - like, say, email sha1sum, are a real pain for people who don't care to encrypt their email. Allow the use of an email sha1sum field, certainly, but don't make it the default in the format.

Anyhow, end of rant. If you did this, you'd get your portable social graph. Or conversely, to the extent that you're not doing this, you are pushing a portable social graph further and further from reality, pushing it into the hands of specialized agencies such as Facebook and Google.