1 Reasonable privacy 2 Plausible deniability (like OTR) 3 Fast updates 4 Easily customizable 5 Client-side extensible interface (Greasemonkey style) Ab

1 Reasonable privacy 2 Plausible deniability (like OTR) 3 Fast updates 4 Easily customizable 5 Client-side extensible interface (Greasemonkey style) About reasonable privacy, the service shouldn't be able to read content. The provider can tell Alice (user on IP 1) sent something to Bob (user on IP 2) but the message content itself shouldn't be compromised. In particular profile-identifying details should be reasonably safe. This requires client-side encryption, of course. Plausible deniability isn't that tricky, it mostly requires careful use of protocols at design phase and there is OTR to borrow. With AJAX or dynamic JS scripts updates should be fast. The intersection of updates of contacts could be done in a single API call with multiple parameters (server-side intersection of data.) Or more scalable but a bit slower by doing multiple calls to separate server clusters (could even be calls to fetch plain files on CDN containing latest updates, aka "the wall".) I've played a bit with zero-knowledge technologies (similar to Clipperz) and I think it's very doable. The big problem problem lies on images and video. Last year I played with HTML5/canvas with encryption but the CPU and delay is prohibitive since it requires to work on decompressed images pixel-by-pixel. It would be nice if the major browsers started giving encryption and compression primitives to JS. And even nicer if there was an API to manage images, audio and video. Chrome NaCl looks also very promising for this kind of disruptive technology. Of course, the non technical problems of getting traction with users and making it commercially viable are still there just like in any other kind of social network service.