Microsoft has announced a draft proposal for SSE today. I actually like the proposal a lot. It seems to accomplish some very sophisticated means of aggragating information and syncing schedules and anything that you need to share. Something really needs to be done, as the current crop of tools that are scratching this itch are woefully inadequate and require too much intervention. I think that SSE is a step in the right direction. I sent the following email to their mailing list (which appears to be a fairly moderated system even if you’ve subscribed).

It seems that in a star topology, SSE would somewhat approximate what Exchange and Lotus Notes seem to accomplish as pertains to scheduling. If you used SSE in a mesh configuration, it would seem to require a peer-to-peer protocol to negotiate communication between links that use network address translation. Would Avalanche technology or another companion technology be used to negotiate mesh networked nodes? If so, why would you need to poll in the sense that Outlook and Lotus polls a server for mail and schedule updates? If SSE requires a protocol with this additional sophistication, why not use one that would allow broadcasting update metadata to all the nodes that are active on the mesh at the instant of a subcribed feed update from a publisher? It would seem that standard would even allow for this as it is not specified that you must poll outside of the FAQ. If you sent an XMLRPC or SOAP broadcast over Avalanche wouldn’t this eliminate lots of unnecessary poll packets if you scale SSE to a distributed mesh topology? Or am I missing something here?

Also, it would seem that non-endpoint feed nodes that are sending SSE feed data to or from a node other than itself could be fairly insecure when not transmitted using a secure application protocol. If such a protocol were used, it could be fairly wide security hole. Effectively, this would open up an ad-hoc mesh network where my node would be unaware of what data it is sending if it were protected via key pairs and unencrypted at the end points. This seems to be kind of a Catch 22 situation. If you don’t encrypt it, I can put my ethernet card into promiscuous mode, and gather all the packets from the phy and gain access to unencrypted xml data. If you do encrypt it, such a network would be an anonymized bittorrent and nearly like what Freenet attempts to do by distributing and anonymizing all data. I guess I’m not seeing how SSE can be implemented securely and reliably using an existing protocol. It wouldn’t take much to uuencode binary data and transmit it over a protocol intended for text-only similar to what has happened to nntp.

I think what is missing in the SSE is allowing for some type of relevance metadata. Google seems to have implemented an interesting XML Sitemap Protocol. Within Sitemap, there is a field for priority. I feel that this is a much overlooked notion in RSS Aggregators on the whole. Abandoning the schedule syncing example, say you’re syncing news feeds between SSE clients. This is almost like bloxor with automatic syncing of your opml blogroll directly or via a mesh network ala Bittorrent. Within Sitemap, the site publisher can specify what is the most important data that it serves via the priority field. If SSE were to include some type of optional relevance or priority information, then it would be possible for the users to specify what data is relevant to them to meet their own needs. This data could then be harvested, and used to benefit everyone using the network. Consider recent startups like Del.icio.us, Digg, Stumbleupon, Reddit, and Bloglines. These social bookmarking sites are a powerful way to find out the goodness metadata of news and articles based on how many people like or dislike the information. So, if you’re syncing lots of SSE feeds back-and-forth, each node effectively would have access to this information about the information. The existence of a link in an RSS feed would roughly be equivalent to what Google refers to as Pagerank. This type of information processing would be better suited in a star topology, but could be extended to a mesh if all priorities were made visible to non-endpoints and thereby eliminate server-side processing. Using priorities would also enable the implementation of automatic server-side priority calculation software (I’m currently implementing this in Ruby). This would enable each web server to automatically use popularity as a way to help the clients adjust the ordering of the RSS feed data that is being offered. In a mesh network, you could essentially farm out the server side processing that’s used to calculate whether or not something is of interest to a particular node.

You may be wondering, “WHY DO YOU CARE ABOUT THIS!!!?”. The only way that I can explain it is that I want to control the way that I consume information. It’s some sick twisted plan that I’m cooking up to automatically ignore irrelevance (mitya000 not included, because that’s some good irrelevance), and pay attention to important events, automatically.

I tried out this new Flock browser this morning, however, it appears that it unfortunately does not support running bloxor. I’m downloading their source code now….

Update: this was my bad, I was attempting to gain XPConnect privileges into Flock, but it doesn’t observe my Firefox user_prefs.js.

Update2: It still doesn’t run JavaScript code that was signed with a dummy certificate.