Atom Feeds, APP, LLUP, and Conversations

[M. David Peterson]

When I first came up with the generalized idea behind LLUP and began brainstorming with Russ on how we would go about refining and implementing it, one of the core driving points was that of utilizing your personal blog as your own personal data store to store everything from public blog entries to personal conversations and everything else in between.  Want to add a web site to your favorites list?  Just click a scriplet link on your toolbar and automatically add this as an entry inside of your link collection.  If not obvious, the reason why Atom became the obvious choice in regards to storing, adding, editing, and deleting data was due to the primary areas of focus of creating both a data format as well as a publishing specification that matched perfectly with the notion of maintaining collections of data.

I find it interesting that both Danny Ayers and Jason Kolb recently made comments that are related to this same general area,

Danny[@ http://norman.walsh.name/2006/10/20/lifeAfterEmail#comment0011]
Just use blog comments..?

Jason[@http://www.jasonkolb.com/weblog/2006/10/browsing_person.html ]
Someday in the near future it'll be just as easy for me to look up what I got my Mom for her birthday last year as it is for me to find my Beatles songs on my iPod.

A key area that Russ and I originally focused on was that of viewing all communication from the standpoint of a conversation (yes, I realize this is how GMail terms things, though Russ and I started chatting about this a year or so before either of us would ever even see the inside of a GMail account.  Then again, the idea of a conversation is obviously nothing new and/or revolutionary, so for what its worth, there ya have it ;), using the concept of subscribing to an Atom feed that each person involved with that conversation would maintain their own side of this conversation, subscribing to each person you may have interest in conversing with.   There are three primary benefits to this type of system,

 - Regardless of the interface such as IM, email, IRC, or inside of a forum like setting, each person maintains their own data from this conversation inside of their own atom feed, and therefore they always maintain control over this data.
- Conversations become threaded by default, and the notion of having side conversations becomes a piece of cake -- i.e. two people want to hash out a particular idea without forcing everyone within the conversation to receive a copy, yet at the same time, anyone who wants to join in on the side-conversation and have a complete copy of that conversation from the start can do just that.
- If you think of a comment to a blog entry in the context to all of this, then you should be able to immediatelly understand how this can be directly applied to maintaining a list of comments you have made across the blogosphere such that you never lose track of something you have interest in keeping up on, while at the same time reserving the right to unsubscribe to a particular conversation if you decide you no longer have any interest.

I recently began to think about this in the context of Kamaelia, utilizing the various pieces mentioned above to implement a community-based anti-SPAM system.  My thoughts on how this might work in general follow below,

---
Similar to that of the blogXast server Russ has spoken too several times, the generalized idea is that of placing the focus on a community driven, dynamic weighting approach to flagging the originating URI of the content as spam, and therefore doesn't require any actual processing of the text to determine if it matches any known patterns.  In other words, this is all human driven filtering as opposed to machine driven, and because the content remains at the originating URI, once it has been adequatelly determined to be spam, (i.e. enough humans have glanced over the message header, and/or queried the server for a snapshot of the content and have determined it to be spam), the system will simply not allow messages from that location through the system, and therefore there isn't any need for a machine-driven filtration system.  This works even better from the reverse, where a true, non-comment spamming human can be given extended privileges based on a white list weighting system in which will continue to provide more and more trust to those URI's in which have a higher ratio of real comments/SPAM complaints, and as such, a system that doesn't require any sort of personal identification beyond that of a particular URI can be implemented.

Connecting this with Kamealia, in a nutshell, the generial idea is that of developing a decentralized commenting system built on a combination of Kamaelia, Atom, and LLUP, in which the comment is actually created and posted on a local instance of your personal weblog (or on the hosted instance of your personal weblog for that matter), a blip message is sent out via a delivery system built on top of Kamaelia, of which the creator of the blog entry in which you commented on can then subscribe to a web feed of comments for each of his/her entries, appropriately adding them to each entry they relate to as either a short summary or the entire comment with a link back to the referenced comment.  The idea would be that with this type of system in place, you could keep all of the content you created in one centralized location, and as such, utilize a simple communication system in which you can monitor either comments to your comments (that others posted to their blog and then sent out via a blip message over the same system), or additional comments to the original thread, viewing them locally as a threaded conversation.  To follow-up a comment, instead of visiting the site, just click a reply button via whatever application you choose to view each thread with, and publish it via another blip message such that others in whom are not already subscribed can easily find this conversation, subscribe, and have a complete history of this conversation, while maintaining their own portion of the conversation on their own system.  A third-party caching mechanism could be easily implemented, and in fact would represent a solid foundation as a business model for those who did it correctly.

Extended the notion of a community-based SPAM tag system, for those in whom choose to share their SPAM tag list, this data can collectively be used to make determinations as to what is likely to truly be SPAM and that in which is less likely SPAM, and more likely someone in whom is trying to make somebody they may not like, look to be a SPAMMER out of spite.  In many ways, this could be applied as an analogy of the human immune system, which uses a defensive mechanism to collectively combat disease, resulting in an increasingly strong defense system in which can locate that in which is disease and that in which is not due to the "oh, we've already seen this one, and as such, already know how to kill it, and therefore are (somewhat) immune to it as a result.
---

Thoughts, comments, criticisms, suggestions?

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354