IM and the RSS Cloud
Originally published at Sean Reiser. You can comment here or there.
At Dave Winer's meeting about bootstrapping the Rss Cloud someone (I don't remember who, sorry) asked about the possibility of using the cloud as an opensource peer to peer IM network to replace Jabber/XMPP (there was a little discussion around how difficult it is to implement XMPP securely and correctly). As I'm working on my cloud I've gotten to thinking about how to implement IM. I have no time to lead this for real, so this may be just a mental exercise. But if someone does have to the time to implement it I'd love to help.
The Initial Handshake
Here's the initial handshake flow as I see it:
- John Decides he'd like to Start IMing Mary
- John's CloudIM client sends a message to his CloudIM Server which creates John2Mary.rss and makes a call to Mary's CloudIM Server sending the URL to the RSS file and a URL to John's Public PGP Key
- Mary gets the invitation sent to her client, she decides to accept and her CloudIM Server sends URLs for Mary2John.rss and mary.pgp back to John
- Now John and Mary can use the RSS Cloud to IM back and forth.
- John and Mary date for a few years, get married and have a bitter divorce, but that's a story for another day.
I'm pretty sure that the initial handshake would require a separate procedure, we would need different parameters passed back and forth and at the end of the day, this is entirely the opposite of the cloud element instead of "I want to follow this", you're sending "I'd like you to follow this and tell me what to follow". However once that initial handshake is made you are open to use the cloud as a communications platform
Security Thoughts
As I hinted above PGP could be used to encrypt the items, allowing you to have a publicly accessible RSS file that anyone an subscribe to but only can be read by the people involved in the communication. Minimally, I think all of items sub-elements should be encrypted with the possible exception of the GUID. Assuming the GUID is clock based and not URL based, I see no data leaking with the GUID and, as a benefit, if you already have a message, there will be no overhead in decrypting it.
Part of me is thinking it might be preferable to have the PGP keys available in the feed which seems more graceful than needing some sort of key expiration in the process. This either requires either specially keyed items with the PGP keys as enclosures that the client can filter out or defining PGPKeys and Fingerprints at the channel level in a namespace.
The Client
There would be some differences between a standard RSS Cloud subscriber and the client required for IM
- As one would expect in IM, the conversations would show threaded and have separate windows for different converstaions.
- The client would be responsible for decrypting the message
- The client would be responsible for notifying the user when keys change to prevent man in the middle attacks.
- The client should interface with PGP or GNU PG, if installed and take advantage of all the security goodness inside.
This is the ramblings of a man at 3:30 AM. I'm probably missing a lot. I'm thinking it's just a conversations starter. Feel free to rip me a new one, if I'm oversimplfying things.