June 06, 2003
Keeping tabs on your comments and threads?
I've commented about this before. I'd like to see a system evolve that helps me keep tabs on threads to which I've commented. I'd like a way for something under my control to be able to receive something from distant sites that helps this process.
Where to start?
For one, there needs to be a lightweight way for a user to give the remote site "something" that helps get the ball rolling. When I visit a site and want to make a comment on a thread I'd like to be able to give that site a URI or something that helped that site figure out how to proceed. If it could be driven in a semi-automatic fashion it would that'd be great.
Now that the remote site has been given this 'key' it should return something to me that notes my participation in the thread. This alone would be a great help. I'd be able to keep my own internal list of things I've commented on. The idea being that at some point I might care to revist those threads and see how the conversation has evolved.
That brings us to the next step; keeping up to date. Which side should bear the burden here? It's tempting to think the remote site should endeavor to tell me when something new has emerged. This is a possibly unreasonable request, for several reasons. The most significant of which being the site may not have the resources to ceaselessly broadcast these updates to what could be a HUGE number of participants. As the saying goes "it doesn't scale". Then there's also the fatigue factor, who says I want to have something constantly sending me messages? The possibly distraction here is enormous.
So how about a way for my side of things to reach out and keep tabs for me instead? Something on my end that, having gotten the initial participation notices, would endeavor to check in with the remote sites. That'd allow me to reign in the potential distraction risks. It'd also free the remote site from having to keep trying to reach out to me (and the hassles of the inevitable error checking that goes along with this).
This leads to the idea that the initial participation notice the remote site sends me should contain something that tells my receiver how, where and when to stay informed. A site that's willing to put up with being constantly polled could say so. A site interested in managing it's bandwidth could request that I not check back too frequently. Sort of like RSS, eh?
Where this could get more interesting would be for the remote site to be able to adjust this checking interval as time progresses. The thought being that some threads will either die down or be closed to further particpation. No sense in having my site harassing the hell out of the remote sites if the threads are no longer active. My site would still know that I commented on the remote site but would stop bugging it at some point.
This adjustability, by the way, is something CDF had built-in.
So let's think about this, what can I give a remote site that would help get the ball rolling? What should that site be able to send to me? How should the on-going conversation between the sites take place?
Yes, a lot of this would be reinventing what's been done before.
Some parts of this are like e-mail. The trouble with using SMTP for this process is that it'd require yet-another-email address to receive the messages. Either that or some hideously messy bit of filtering that would undoubtedly fail to be cross-platform.
One could consider using NNTP for such a thing. The trouble here is that users can't readily operate their own NNTP servers. If just for it's use of sub-1024 privileged port 119. Hmm, perhaps something that took NNTP semantics and bolted them up to HTTP POST would be workable. A lot of what newsgroups can do is applicable here. Find a way to make personal NNTP services come to life while being as easy as setting up web pages and it might be interesting...
Mailing lists, being somewhere in-between are likewise a possible tool to utilize. The trick would be in getting the remote site to be able to send your personal list a message without exposing the list to spam risks. Then there's also the same hassle of needing yet-another-email address and setting up such a list. If you set up a list specifically designed to receive such notifications it might work. Given that MIME support would allow inclusion of XML data it could be quite useful. The list would have to be moderated. This way any notifications would have to be approved. This would help stave off spamming. Likewise it could be secured using PGP or other PKI systems. This way your list would only accept messages that had been digitally signed by sources you've configured it to accept. A secured whitelist of sorts. The trouble here is, again, the setup efforts. Getting a mailing list running, especially one with this sort of integration, is not a trivial task at the present time.
One other tangent could be use of Instant Message systems or group chat, like AIM, MSN or even IRC. This would also incur it's own setup issues and would probably require yet another account as you probably wouldn't want the alerts coming back into your personal messaging account. Couple this with a 3rd party service and it might kill several birds with one stone. You could listen for items of your own interest. Others could likewise receive the same messages if it was a group chat style setup.
What's obvious here is the same issues keep surfacing every few years. Fortunately with the passage of time the tools are getting better and better. The solutions are becoming more closely connectable. It certainly feels like an awful lot of this is finally reaching a point of convergence. Some might say it's about time!







