Preface
We understand NoseRub not only as an application, like what is running on
Identoo.com and which everyone can
download and install on their own servers. We want even
more freedom for the people who want to use NoseRub.
That means, that we want to give a user the possibility to choose their NoseRub application. Right now, only one version is available, which was implemented in PHP. Others might prefer other languages or might want to have a different approach to how the application should work. We encourage that and therefore want others to implement their very own version of NoseRub.
After a
long week in Berlin, a lot of new input needed to be processed and the new idea of the NoseRub protocol is no longer what currently is used in the version presented on Identoo.com.
Right now, only NoseRub-IDs can be used as an
endpoint for a contact, even when someone has a blog where he/she lists all his/her other web accounts in XFN or FOAF. I want to make use of that and allow people to connect through this, too.
What still is true about the Noserub protocol, regards the three main parts of NoseRub:
Identity-URL +
Profile +
Contacts = NoseRub
What will be described here, is not the current implementation, but the implementation of how it should be and how it will be in NoseRub 1.0, although there is no release date set for that.
Identity-URL
The Identity part for NoseRub is a single URL, under which the all information about the user can be accessed. It should be an OpenID, but that also can mean, that OpenID login can be delegated to an already existing OpenID. An example for such a URL could be
http://identoo.com/dirk.olbertz/. SSL support for the Identity-URL should be available.
Each Identity-URL can be endpoint of a contact relation.
There must be some kind of metadata on that page, that identifies itself as a NoseRub-Identity-URL. That should be similar to how OpenID works.
Profile
In the metdata or content area of the page that can be accessed through the Identity-URL, profile information as XFN/Microformat and/or FOAF should be accessible - either embedded or referred through further URLs.
For XFN, all links where the rel-Attribute contains "me" are regarded as web-accounts for that Identity. In FOAF, the tag
foaf:OnlineAccount will be used for that kind of information. All other FOAF- and microformat-data should be used as proposed by the appropriate standard. (
List of full usage for the fields to follow!)
All web accounts hold a specific type to be able to filter and categorize them. Currently, there are nine account types:
- Photo
- Video
- Audio
- Link
- Text
- Micropublish
- Events
- Documents
- Locations
(
Full list of web accounts like flickr, del.icio.us and twitter, along wth their type to follow.)
Open questions
- How should things like the "About" text be stored in FOAF/microformats?
- How should RSS-Feeds be specified with the account types above? (In FOAF and XFN)
Contacts
In the metdata or content area of the page that can be accessed through the Identity-URL, profile information as XFN and/or FOAF should be accessible - either embedded or referred through further URLs.
All links with the rel-attribute, that do not have "me" as part of the rel-attribute, will be considered as contacts.
This will be the table of contents for the documentation. The Protocol
Tracked: Nov 19, 21:19