Here is a thought. If it has been done or something similar is being done somewhere, maybe I will find out in reply to this post.
Reading Lists in the context of RSS feeds is an OPML (or RSS or RSS with OPML embedded or RDF or….) file that contains a list of feeds that someone is subscribed to and is meant to be shared as a suggested feed list for others to subscribe to. Or maybe its a subset of feeds that are of a specific category or a top list of feeds etc. Theoretically, this dynamic Reading List is pulled in by other people’s aggregator software and any changes to it would be reflected (synchronized) to all users who have subscribed to the list. This last part might not be a requirement since a user could just import the Reading List (i.e. static OPML file) into their feed reader. But the idea is more about letting someone else curate a list for you. New and/or removed feeds would be the decision of the trusted Reading List Curator. I don’t know what software currently supports this besides Dave Winer’s stuff.
Today, probably the most similar thing that exists on a major centralized service is Twitter Lists. Though this could be leveraged for what I am proposing, a Whitelist used to filter replies to blog posts, I am instead more focused on decentralized solutions and the more traditional open web blogosphere. So let’s put Twitter aside for now.
First, a brief explanation of the world of RSS that I am envisioning…
Blogging tools would only output RSS feeds which would get rendered by RSS readers, aggregators and other template-based web presentation engines. In other words, RSS is the first class citizen and primary output of blogging tools. The way it is normally done is in reverse. RSS is generated as a secondary dynamic XML source that usually pulls content from a database (i.e. mysql) and outputs the latest x posts. The content is displayed on the web using database queries (and cached copies of HTML in some cases) and templates from themes. I have built things that run in a different order and priority and rely more heavily on static files both locally and archives in the cloud (i.e. Amazon S3). My most recent blogging tool, rssgarden.com, uses XSLT to render RSS feeds in the client-side browser with HTML/Javascript/CSS templates. The web server is only distributing static (and sometimes dynamic) xml files to the users web browser and the web browser’s own engine transforms that raw XML into the familiar styling of an HTML web page. This offsets some of the processing load from the web server and onto the users powerful machine.
With my vision of this stuff and the way I have developed my tools, everything is RSS. So, comments are RSS feeds as well. They are pulled in and included with other feeds that are being presented on a page via the XSLT stylesheets (document() function). Their is no comment plugin from a 3rd party company (i.e. disqus.com) or native commenting module that requires a database connection. Comment threads are just another smart RSS feed. Smart because I have added some experimental enhancements using the inReplyTo RSS namespace. Which leads me back to the topic of whitelists for replies.
Like Trackbacks, inReplyTo will suffer from spam if/when it ever catches on. The concept is similar but adapted more for the modern social web and my own interpretations of how everything works and connects together. Trackbacks have evolved in the form of federated protocols like Salmon. I may very well just support Salmon or the superset Zot!. But I am also on the fence thinking about simpler and maybe even more socially natural ways to accomplish anti-spam. So before I get all geeky and just evangelize and implement these other protocols for distributed messaging and notifications, I want to make sure that I have thought through the simpler side of it all and if something seems interesting enough, it might be worth another blog post or a prototype.
If inReplyTo is something I continue to work on and move forward, alone or with others, then fighting spam is going to be the priority otherwise the whole thing is moot. Being different than Trackback buys time but eventually, the spammers will come. So outside of the world of crypto, what can be done? The obvious thing is Whitelists (and Blacklists). This is what blogging tools natively build into their products to handle spam from comments and trackbacks. The blog author has to moderate and mark comments as spam and rely on some other optional algorithm engines such as WordPress’s Akismat technology. But what if their was a smart reference point unique to the blog author that can automate the creation of a Whitelist? That is where the idea of Reading Lists as Whitelists for blog comments comes into play.
I’m thinking that if people started making a Reading List available online somewhere, ideally within their own hosted website directory but truly it could be any public URL and even a Google Docs URL (more on that later), then that would be the basis for of a trusted network of people, of bloggers, that can be leveraged as the distributed reply system’s Whitelist (optionally). If you want to leverage this trust network, you would enable the feature in your software that supports this system and once enabled, you would ONLY receive @replies and @mentions from those who are within the trusted network formed by Reading Lists. Notice I said ListS (plural). That is because this system would take advantage of a network of linked Reading Lists. As a user of supporting software, you could create or enable a “List of Lists” that consists of many trusted Reading Lists and this could also provide something like “Inherited Trust” where you can pick a list and choose to trust all lists discovered within that list. In other words, you want to trust those who are trusted by who you trust yourself. All of these trusted sources combined would make up the master Whitelist which is used to control where distributed messaging (private, public replies, random mentions) can be received from. All other incoming messages would go into an “Untrusted” queue which you can browse at will and manually trust sources or keep as untrusted by doing nothing.
It would help if more users had their own domain names but technically, a trusted source is a trusted URL of any blog or website that is participating in this system. Occasionally, all URLs should be checked for validity and purge out deadlinks or suspected as spam (expired domains registered by spammers)
A spammer will be detected quickly and once removed from one list, it propagates and gets removed from all. This could also be a problem as soon as some trigger-happy people start marking sources as spammers and affecting others who may disagree. In this case, it might need to go through a ripple process where the change needs consensus by x sources before it automatically get labeled as legitimate spam. This ripple would start at the closest related source of the questionable source and move outward to a proper pre-determined level at which point consensus is either made and source is marked as spam or it fails and source is not deleted. Whatever the solutions are, it feels like they can be feasible solutions within the concept of this People-Powered system that circumvents (or maybe coexists with?) algorithmic-centric solutions.
I’ll be doing some research on this to find similar thinking or experiments that exist and the results etc. I doubt this is a unique idea but it does seem interesting enough to think about and warranted a blog post. Please let me know what you think. Oh and regarding Twitter Lists, i’ll write about that another time. But I am reminded of some very cool experiments that I am following and probably, now that I think of it, has inspired some of these thoughts today.
Check out punkmoney.org and GiftPunk.
Boris Mann 12:57 AM on December 15, 2011 Permalink |
I created a new user. But I’m not sure what to do next?
BTW, my account on that inReplyTo forum never got approved, either??
sull 1:08 AM on December 15, 2011 Permalink |
hey Boris. thanks for taking a peak.
you could create a newItem to post something.
i don’t know. part of user testing is to catch the confusion, bugs and feedback and think on it
btw, i checked xmlns.inreplyto.me and you should be able to login.
i think it was initially set to moderate new users and locked the user account but i unlocked it a while ago and disabled that setting for future users.
how’s rsshero going? i will provide feedback at some point. it seemed to work well with my goog reader import.