webfinger protocol is relavant here.

Clearly a system flexible enough to allow any IDP to integrate into a commenting system is necessary. Since different IDPs may identify their users by different means, each user for an IDP must be identified by a URI. Ex:

mailto:user@provider.tld
http://provider.tld/user/unique-id

Additionally, this URI needs to be as close to a "permanent" URI as possible, so that users will consistently be referred to as themselves. Things such as twitter usernames should not be used in these URIs as they are subject to change - but of course, this will be up to the IDP to implement properly. This field would also, by default, be private - and doesn't necessarily have to be required, though I presume most blogs would prefer a confirmed identity.

As these identities would be tied to URI's, I imagine a spam system against what I've described here would contain a white list of URI protocols, and could query a blacklist based on those protocols (such as email domains, websites, etc).

This isn't necessarily any more effective than the current state of the net, but it could certainly be effective.

Additionally, to help curb spam consider implementing a <captcha> tag. I would imagine it would look something like <ns:captcha><link href="https://loc.tld/captcha?tok=142631&type=img" type="image/png" /><link href="https://loc.tld/captcha?tok=13652&type=audio" type="audio/mp3" /></ns:captcha>

Alternatively, these could be specified within the current scope by using link's rel:
<link rel="captcha" /> and <link rel="audio-captcha" />

thanks for taking the time to reply.

Custom domain namespaces are all well and good, and VERY good for coverage - but using something like PURL would insure that the web address will always be there, even in the event that the community falls, the admin overseeing loses interest, etc.

"Zot is a framework for secure delivery of messages on the web based on
webfinger and encapsulating salmon.

First read the salmon and salmon magic envelope specifications. Zot also
makes use of webfinger and ActivityStreams and several concepts from RFC822
(email). Zot encompasses the zot delivery framework and the zid remote
access protocol.

Complete re-write of DFRN. Zot is now an extension of and encryption wrapper for salmon and provides a foundation for openid based access control for any web resource to any webfinger identity. It is designed to be upwardly compatible with both OStatus and Diaspora and represents a model for a web based messaging infrastructure which can ultimately bridge traditional email with web based social networks.

MIME messages and the bridging of SMTP with webfinger and social networks aren't completely specified in this first release but are noted as this is where the specification is headed. There are some details to work out on the necessary extensions to rfc822 and its derivatives (when used on the web) which require broad concensus."

I was looking at some of my code and I see that I was also experimenting with Semantic PingBack:
http://aksw.org/Projects/SemanticPingBack
I might revisit that.

I'm also thinking about Magic Envelope and possible alternative approaches to auth layers. I try to ask.... What would Dave Winer use?. Only because he is a fan of the simple. And truthfully, that is the point of this effort. Not to rewrite Salmon but to think about simpler approaches without sacrificing too much on spam, fraud and attacks.

http://www.youtube.com/watch?v=M5BMIQm7o4Y
http://youtu.be/M5BMIQm7o4Y

I for one do like the Salmon Protocol and followed its draft progress. I also like Webfinger. But I have some concerns about complexity and that is why I started thinking about more light-weight simpler methods that could be used on top of RSS feeds.

I am going to review the Salmon Protocol again so it is all fresh in my mind. I'd also like to examine implementations such as status.net and others, if any. A year ago, their was much excitement about Salmon but these days I have not seen much in the form of implementation. Please comment here with good reference implementations. I recall cliqset but they are closed down.

A precursor to this effort can be found in a blog post that I wrote in Aug 09' here:

"conversations in the cloud"
http://vocal.ly/blog/2009/08/25/conversations-in-the-cloud/

The key quote in that article:

"So to reiterate, all we have is a feed inside something like Google Reader being read by someone who wants to reply to one of the feed items. How do we get it done? One curious thought I have had involves the RSS channel sub-element called “textInput”. Here are reference links:

http://cyber.law.harvard.edu/rss/rss.html#lttextinputgtSubelementOfLtchannelgt
http://www.w3schools.com/rss/rss_tag_textinput.asp

As it states, it is basically support for a simple form submission. Dave Winer noted at the time of writing (~2001) the following:

The purpose of the element is something of a mystery. You can use it to specify a search engine box. Or to allow a reader to provide feedback. Most aggregators ignore it.

Can this be used for handling conversations across the rssCloud network? Possibly. Let’s delve into it’s potential for a minute."

I went on to propose utilizing textInput with the value of a base URL to an input script to POST replies to along with necessary item level parameters including the guid. Might as well read the article in full. This is where things started, albeit not very aggressively (writing this post 2+ years later).

That is still the basis of this effort except now instead of using the textInput element, it seemed to make more sense to utilize a new Namespace altogether for more flexibility. After all, I have never sen a feed with textInput defined so if you are going to ask people to enhance their feeds you might as well be thorough and take advantage of why Namespaces exist to begin with. Although I like the idea of baking in the textInput element because it is part of the RSS 2.0 spec and it can be done in a
minimalistic way, I have to get beyond my own semi-obsession with that mentality.

So a Namespace was born! It was about a year later that I had email exchanges on this topic with Brian Hendrickson. He was focusing on the Federated Social Web efforts too and is an RSS advocate. So this is what he came up with for Swat0:

#Swat0 and a Salmon-like flow for RSS
http://brianhendrickson.com/2010/09/swat0-and-a-salmon-like-flow-for-rss/

While that simmered for about a year, I had began developing rssgarden.com and the companion service inreplyto.me.
My intention was to continue thinking about and integrating the inReplyTo Namespace into an actual social blogging/bookmarking/podcasting web app (rssgarden.com). I came up with a different recipe but not necessarily a better one. Just different. And I thought that I would have several other versions to refer to by now but I shifted focus onto other projects. So my implementation has also been simmering for about 10 months now with no changes. I never even officially documented what I did end up with. That is the long-winded point of this post.

I am going to add some screenshots and URLs to show my implementation now.

Example RSS Item with replies:
http://rssgarden.com/u/sull/ChangeLog/item/1298660180768
Screenshot of RSS XML:

Example RSS Reply Feed for the Item shown above (from inreplyto.me web service):
http://inreplyto.me/get/inbox/_4d64afa605278-650/1298660180768
Screenshot:

Note: The inreplyto.me web service was used to demonstrate how their could be 3rd party middle-man services to facilitate the reply transactions on behalf of a feed. This is similar to how their are realtime feed hubs like SuperFeedr.com that can be leveraged to enhance your feeds. But feed owners can just as easily host the code themselves. That could be in the form of a WordPress Plugin or natively baked into a web app or even RSS Readers/Aggregators.

Moving forward, I would like to improve upon these earlier efforts and do things in a more intuitive way if possible. I would also like to add features that would be similar to Trackbacks so that feed owners can have Reply controls such as:

• Notification of Replies (Skinny Pings)
  
• Auto-Approve Crosspost of Replies (Fat Pings)
  
• Moderate a queue of Replies
  
• Blacklist or Whitelist Feeds/Sources/Users to form a Trust Network

The methods and technologies to make these enhancements a reality need to be discussed. Spam needs to be avoided or at least minimized drastically (be no worse than Twitter @mention spam) and spoofing is a concern as well. Their is also the issue of whether or not to bake in Identity references into this Namsepace (as I have in my example) or not. Webfinger might be worth consideration here. I prefer to avoid OAUTH2 but am open to it as long as things remain simple.

http://devfiles.myopera.com/articles/591/nsnamelist-url.htm

I'll start with this site's own URL and wait for feedback and revisit later.

xmlns:inReplyTo="http://xmlns.inreplyto.me/"

The other reason why I was enticed to install this script was so that I could eventually work in the inReplyTo Namespace to the forum's own RSS feeds and represent the tree threading structure. This would be a demonstration of a localized set of feeds and can be tested in RSS Readers that support the inReplyTo Namespace. That's pretty meta!

So, this forum made sense as a way to collaborate and discuss the Namespace while also implementing it here as we go. And eventually testing it on feeds across the web. Thats my thinking.

Atom Threading:
http://datatracker.ietf.org/doc/rfc4685/
http://www.ietf.org/rfc/rfc4685.txt

RDF Threading Module:
http://web.resource.org/rss/1.0/modules/threading/

Ryan Tate - RSS killer feature - Replies, via in-reply-to element:
http://thehack.webmasher.com/2007/11/rss-killer-feature-replies-via-in-reply.html

#Swat0 and a Salmon-like flow for RSS
http://brianhendrickson.com/2010/09/swat0-and-a-salmon-like-flow-for-rss/

Salmon Protocol
http://www.salmon-protocol.org/
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html

Domain Federation Protocol
http://specs.mart.me.uk/dfp

Zot! Social Communications Protocol
http://dfrn.org/zot-protocol.txt

Prototypes With Custom Implementation of inReplyTo Namespace:
http://rssgarden.com
http://inreplyto.me
http://vocal.ly/blog/2011/02/17/rss-garden/
http://vocal.ly/blog/2011/02/17/inreplyto-me/

My name is Michael Sullivan and I am the initiator of this casual working group in the hopes of drafting out a simple spec for an RSS namespace called 'inReplyTo'. The goal of the namespace is to allow for conversations to happen on top of RSS feeds and for new innovative RSS centric software and services to integrate and support the namespace that will be drafted here (hopefully).

I think it would be good to collaborate on this and to avoid any proprietary and/or app-specific methods that won't easily be interoperable with other RSS software and services. If we can gather together interested developers who are focusing on RSS and related formats, and discuss how to move forward the vision of loosely integrated, federated and distributed solutions for open data flow, including the social layer that permits conversations (comments/replies and @mentions), then we can quickly evolve our technology solutions and the passionate developer community that builds them.

It is my opinion that RSS will experience a resurgence in the coming months/years and not only remain relavant but become even more relavant than it has ever been before. The open pipes are increasingly important in a time where corporate giants are mastering their silos. One way to assure the continued use of RSS is to enhance it with the social layer that it currently lacks. Their is prior art. And maybe a new namespace is not necessary in some people's opinions. But I've learned that starting fresh can be an accelerant and often can result in a more streamlined simple version of what was previously envisioned and worked on.

Such details can be discussed in the forum so I will not get into all the details in this particular welcome/intro post.

Thanks,

@sull