What is Sproingg and why should anyone care?

So what exactly is in a Sproingg node?
-------------------------------------

Sproingg is a project to bootstrap a richly featured text communication system over CouchDB using 
the following apps and CouchDB features collectively referred to as a Sproingg node

a) A CouchDB database as message inbox with a CouchDB database URL as an address for sending messages (Reqd)
b) A CouchApp that is a forum app (Optional)
c) A CouchApp that is a wiki app (Optional)
d) A CouchApp blog (Optional)
e) A CouchApp that is an intelligent address book (full details to be written up) (Reqd)
f) Use of _changes feed to create adhoc chat sessions 1-1 or n-m (Reqd) [[ sync communication ]]
g) Use of CouchDB replication to move text messages between two Sproingg endpoints (Reqd) [[ async communication ]]
h) A framework to identify Sproingg endpoints and apply permissions (strong identity, access control) (Reqd)
i) A set of views that expose my forums and my wiki to the world in read-only mode (Reqd, if forum and/or wiki exist)
j) A set of URL's that are write-permissible to some Sproingg peers I trust (Reqd)
k) A database that saves all my sync chats (Reqd)
l) Private views to browse all forms of my text (Reqd)

-------
future:-

* a gateway to incoming and outgoing email
* an interface to webmail and other mail address books.
* an interface to twitter friends/followers/DM
* an interface to facebook friends and inbox
* interfaces to linked-in, quora, 4square, gowalla
-------


A Sproingg peer, in its current incarnation, is envisioned as a Swiss army knife of text based CouchApps that 
communicate with other such CouchApps on other Sproingg nodes via CouchDB replication - a single HTTP based protocol. 
We move chunks of text from one peer to another based on what the recipient peer has allowed and 
what is known to the senders smart addressbook.

To be able to bootstrap Sproingg we need to be able to find and connect to other nodes.   
For this we need to bootstrap an address book by one or more of the following methods

a) direct p2p group replication of address records between a trusted group 
    (we did this in a "replication party" at CouchCamp)
b) extraction from public address books (TBD as replication parties grow)
c) 1-1 exchange of address book data between mutually trusting peers - needed to seed viral growth


This is all very fine but how exactly is this supposed to be useful, or new or worth doing?
-------------------------------------------------------------------------------------------

I'd like to illustrate what you can do with the Sproingg network with a couple of example scenarios, 
one for a small company and one for a group of people at a cafe.

Assume the existence of a rich and active network of Sproingg nodes connecting CouchOne employees globally.  
Also assume that each Sproingg node has a public component 
that is hosted at couchone.com (the public facade for a Sproingg node)

Small Company Scenario:-
----------------------

Nitin is in a live text chat with Chris using a chat app that uses the _changes feed of CouchDB. 
Nitin thinks of some new crazy idea that's a paragraph long in text. Rather than putting it all in the chat 
he posts it locally to his own Pages wiki app. He gets a URL to it, posts the URL to Chris in the chat. 
Chris is on the trusted list in Nitin's smart address book so when Chris clicks on the link he sees the content 
on a web page on Nitin's Sproingg node. 

Chris, being Chris, immediately wants to conceptually fork the idea so he clicks the <clone> button 
and receives a copy of the text into his own wiki via CouchDB Replication.

He then works the idea into his own thinking and posts the result on his local blog which is generally visible 
only inside CouchOne. CouchOne employees who have subscribed to Chris's blog will see a notification in their 
Sproingg inbox that there's new content, with a link to it.

This post though is important enough that he chooses to "publish to world" so he "repl push"es it to his public 
CouchDB instance. (== his public Sproingg facade).  On the internal copy he also adds annotations for CouchOne folks 
and puts it on his own forum app for internal commentary, discussion nad eventual use in the knowledge base.  

Finally he tweets a link to his public post and also uses his Android Sproingg node to send an SMS message with the same link to 
a friend who refuses to be on Twitter/Facebook and doesn't like all that social junk.  His friend receives it on an iPhone and 
reads it on the iPhone webkit browser leaving comments on the post that then get replicated to the internal copy. 
Note that internal comments don't automatically replicate out.

One comment is particularly insightful and so Nitin, on reading it, clones the comment.  He makes an internal CouchOne-only 
post on his own blog but also sends the a link to the post and a separate link to the original comment to 
CouchOne Product Management where it then gets posted to their "nice to have" features list.

Note that all this rich multi channel, multi protocol, multi app text communication is done without 
cutting and pasting any text. This is due to the power of CouchDB replication and the existence of 
CouchDB on the mobile phone.

Sproingg has sprungg!

Note how in the description of this scenario, the focus is on the text content and how it makes its way across the nodes, 
internal and public.

Note also how the applications and the protocols are in the background and do not end up silo'ing the text 
- it is free to move around in text form from app to app because all Sproingg apps store their content in granular form as 
CouchDB documents. A post is a document but so is each comment, each line of text chat and each wiki page are documents,
making interoperability trivial.

To be able to move text around, CouchDB documents need some routing information in the form of a set of headers called 
Sproingg headers, and there needs to be some code that understands how to interpret these headers and 
move the related document around. 

Note that the above scenario can be implemented today with some code for validation functions and use of 
CouchDB auth system.  It uses couchone.com hosting and does not need discovery to be working because in this scenario 
everyone knows everyone else and are easilly connected via a company wide "address book".  
But when you are out in the wild and want to connect up with a group of people spontaneously you need 
more networking capabilities. Macs have them working out-of-the-box and Windows/Linux/BSD can become interoperable 
using Bonjour downloaded and installed.

Wi-Fi Cafe Internet Scenario (needs zeroconf/bonjour for service discovery) :-
-----------------------------------------------------------------------------

Nitin is working on his laptop at a very popular local coffee shop, as he does on weekends, 
along with 15-25 other regulars.

He often wonders what brings all these people together, what makes them tick.  He's always wondered if he could 
create a chat with only the people at the cafe - a spontaneous chat room that doesn't need any 
server software to be installed by the coffee shop owner. 

And today, he's finally going to be able to do it - he's made his laptop into a Sproingg node 
and has convinced some of the others at the cafe to try it out too, by putting all the software on a USB stick.

He starts with looking for the other Mac laptops on the local Bonjour network and uses Bonjour Service Discovery to find 
those that have Sproingg chat enabled - a few clicks and they're off. 
Now the rest of the folks in the cafe are getting curious and there's a lot of peeeking over the shoulders and excited curiosity.
Soon all the Macs in the cafe are on the chat and it's buzzing.

It so happens there's a Windows programmer who wants to know how to get Windows comuters networked in to this chat.
Nitin tells him about Bonjour for Windows and it's pretty clear the chat is going to get bigger in the next week or so.

Sproingg has sprungg!! Yet again.