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.
From my blog (here
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".
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):
Check out the specification, and feel free to share your thoughts in the OInvite discussion group or on the Diso list.
- Open: Communications Relationship ("CR") requests can be send to users with identifiers in unaffiliated domains or federations.
- 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).
- 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.
- 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).