OInvite: Open Invitation Protocol WAS: Re: Open Friend Request Protocol?

[David Fuelling]

Hey All,

I had some free time this past weekend, and put some more effort into exploring the notion of an open "Friend Request" protocol to lay the groundwork for cross-domain social networking interactions.  It's too much content to simply put into another email, so I'll provide some links below, as well as some copy from my blog.

Please share feedback, criticisms, ideas, etc.

Thanks!

David

• Some Background: The case for an Open Invitation Protocol
• Link to a very-draft OInvite spec: http://oinvite.googlecode.com/files/oinvite-core-1_0--1.html

=================
From my blog (here)...
=================
<Some Context>
A while back, I posed a question to the Diso mailing list wondering if there was any work being done to enable cross-domain "friend requests" in the context of social networks and other systems that have the notion of "friend lists".
</Some Context>

As I soon found out, this is a pretty involved topic, so I collected my thoughts and shared them with the world in a blog post here (I recommend reading that post for a lengthy--if surfacey--background relating to the issues surrounding friend requests, open vs. closed communications relationships, and my general musings on this topic).

At the same time, I formalized some more thoughts surrounding this idea into a spec I'm calling OInvite. Perhaps "spec" is too formal of a word. In reality, I just like to use the xml2rfc tool, so it was more enjoyable to try to hone my ideas in the confines of a specification. To say that this document is anything close to a spec would be an understatement!

:)

At any rate, the idea behind OInvite is to codify an open protocol that helps facilitate the creation of unsolicited "communications relationships" (i.e., friend requests) between various parties in unaffiliated domains without the worry of spam.

Some key attributes of OInvite (see my musings post here for more background on what these terms mean):

1. Open: Communications Relationship ("CR") requests can be send to users with identifiers in unaffiliated domains or federations.
   
   
2. Bi-Directional: OInvite assumes all CR's are two-way, meaning information can be sent and received by both parties (so long as participants can elect to ignore messages from a particular sender, uni-directional relationships can be simulated in a bi-directional CR).
   
   
3. One-to-One: OInvite always involves a CR's between only two participants (a.k.a., cardinality) because this greatly simplifies the spec, yet still supports one-to-many communications.
   
   
4. SPAM-Free: OInvite provides support for a pluggable mechanism to guard against "first-contact" spam, which is the only type of SPAM available in a white-list type communications environment, such as a social network (in systems like email, this pluggable model is not sufficient to prevent spam due to the implied "all senders are good" principle underlying the design of SMTP).

Check out the specification, and feel free to share your thoughts in the OInvite discussion group or on the Diso list.