Essentials

• Overview
• News
• Use Reptile Now

Installation

• Overview
• Release Notes
• HISTORY
• Download
• Portability

Developers

• Actions
• Content Controls
• Database
• Libraries
• Parameters
• Settings
• Tasks
• Tomcat
• XML
• XSLT
• Notes

P2P (content distribution)

• OCS and RSS

Search Infrastructure

• Search
• Providers
• Search Service

Services

• Search
• rss2html
• RSS Content Parsing

Proposals

• JXTA
• P2P Protocol Handlers
• Next-Generation Subscriptions
• Rendezvous Nodes
• HTCache
• Publication

Resources

• Download
• Browse CVS
• Bugzilla
• UML Class Diagrams (SVG)
• UML Class Diagrams (PNG)
• UML Class Diagrams (HTML)
• Javadoc
• Mailing Lists

Mark says :

It's a "B-link". Well, Heather called it "currently reading". Michael Barrish calls his "choice cuts". Leslie simply calls hers "elsewhere". It's a link to a site, seemingly random, generally obscure, quirky, maybe not the sort of thing you'd expect a person to link to. (In Dean's case, what changes is not the link but the picture--of his dog, in this case. There are certainly other variations.) Regardless, it's set apart from the main content; it's its own thing really. A blog within a blog.

Dave says :

Based on a feature request by Mark Pilgrim, I designed my first RSS module today, called blogChannel. It was fun. Scripting News already supports it.

This functionality has been available within RSS 1.0 for about 2 months now thanks to my mod_link and RSS mod_subscription specs.

Of course mod_link goes above and beyond the call of duty and allows a lot of very complex link relationships.

I am working with Ian Davis and Bill Kearney to possibly merge OCS and mod_subscription into an updated format to support mod verbose subscription relationships.

I created an RSS 1.0 feed for scripting.com... assuming anyone wants it :)

I just uploaded the recent output from my offline RSS aggregator named Offnews . On a machine with a large LCD panel it won't be very compelling but use your imagination and imagine this on a 240 x 320 LCD.

I have been thinking the design of an RSS 1.0 module for the syndication of payment metadata which allow weblog users to discovery payment and donation systems. This module can be used to support ad hoc transfer of funds (possibly as a reward for positive behavior).

This is specifically for the use of peer-to-peer exchange of small micro-payments within the weblog community.

The system is based on the concept of a 'payment provider' such as Paypal or Amazon (with hopefully more to come).

Users register that they support payments by using the 'payment:donation' element. This provides meta-info about the payment system and a description of why micro-payments are being used.

The user then specifies which payment systems are supported (providers). Initially it would make sense to support both Paypal and Amazon. Both these systems are REST style services and should be easy for user agents to implement.

Users can specify the cost for items with the 'payment:cost' element. We can also specify whether these are mandatory or simply requested payments. Descriptions are also supported here so that users can provide a reason for the payment.

I don't know how we would enforce mandatory payments. I think this is going to have to be a dependent of the resource. Assuming it is a URL resolves to a web application we can then prompt for the mandatory payment and redirect to another location. I don't know it this is perfect but I don't want to head down the path of Digital Rights Management within RSS.

I am also not sure how we would represent currency systems. How does one represent $10 US vs. HK? (I have to do more research here).

The use of 'roles' can be used so that we can provide multiple individuals with ways to receive funds from one weblog. For example a blogger hosted weblog could receive funds with a 'developer' role and the author could receive funds with the 'author' role (note these will be URIs).

Multiple individuals for the same role should be supported with descriptions of why each role is necessary.

There are a number of security issues here. At the very minimum one could assume a man-in-the-middle attack (by someone like the mafia) which could be used to rewrite the RSS file so that the payment identity is changed to redirect money into a different accouunt.

At the very minimum SSL needs to be used for the transfer of payment metadata. The only exception is if the user uses a well known identity (burton@peerfear.org) within the payment provider. The only problem here is that this is still open to attacks such as the recent unicode URL attack within Internet Explorer (using a different charset for a DNS name which looked the same as the original URL).

If the site can not support SSL then it can not take advantage of payments. User agents are not going to use payment metainfo discovered through non-SSL mechanisms as this money could just be used by nefarious people (mafia, terrorists) instead of going to the intended recipient.

Here are some examples of the format I was thinking about:

http://www.peerfear.org/download/mod_payment/example-donation.xml

http://www.peerfear.org/download/mod_payment/example-cost.xml

Are these guys serious? Blogwalking? Do they actually own a Zaurus? Ha!

The keyboard is totally unusable. I don't even want to type 'ifconfig' and I couldn't even imagine writing this blog entry on the Zaurus!

I just released version 0.9.0 Offnews, an offline RSS aggregator for PDAs.

Essentially, this is just a very thin version of Reptile with some glue to make it run and some different XSL to render very thin HTML designed for small LCD panels.

It is pretty stable. There are some bugs with HTML export but about 70% of the available HTML looks just fine when exported.

The HTML mod_content export code (RSSContentSerializer) has a few bugs (the algorithm is complicated) but I am working on fixing these for 1.0.

The other day I blogged about Secure GUIDs within RSS.

The technique used here relied on a SHA1 hash of the URL(of the feed.) + triple after it was ran through XML canonicalization.

This isn't a perfect scenario for providing 'secure' GUID generation. There are a number of attacks here including traffic redirection, man-in-the-middle, etc.

Ideally we would sign the RDF triple with the private key of the peer (owner of the RSS channel) and then use the Base32 encoded value of this as the GUID.

The reason this would work is that (assuming you have the correct public key of the peer) you can look at the signature and verify that it is indeed correct. With just a normal channel URL based hash someone could MiTM you and rewrite the content with new GUIDs (they are easy to generate) and you wouldn't be able to tell. With a public key mechanism you could look at the signature and it would fail to verify because the attacker would not posses the private key required to generate the correct signature.

The only problem here is that we have to build out a public key distribution mechanism over RSS and I think that might be pushing the envelope a bit.

If the hash mechanism is accepted within the community the same mechanism can be used with cryptographic signatures in the future when we have the technical capability and clients which can handle this.

I am somewhat pessimestic about the potential here. We have needed cryto within mail readers for a long time now and it has never happened.

I really wish we we could have a future with crypto deployed in all RSS readers. I really need this for my reputation system (in a perfect world).

... time will tell.

Also, supporting both mechanisms would allow for paranoid (and rightfully so) bloggers in 3rd world and politically sensitive situations (me!) to use signatures instead of the standard SHA1 hash.

One of the great things about living in San Francisco a lot of smart people live and work within the area (South Bay, Silicon Valley, East Bay, etc).

This means that is very easy to randomly meet Internet and within computing circles. All you really have to do is have a few friends within the computer industry or hang out at the coffee shops and that is all you need.

This happens all the time for me. I bump into someone online and realize that they live in San Francisco so I drop them a line and we meet up.

Tonight I had dinner with about 30 friends and colleagues of mine. Past dinners have really fun with some great conversation.

Tonight I show up and notice that Dave Winer is sitting at one of the tables.

My initial thinking was that this could be a Good Thing. There has been a lot of recent talk about RSS 1.0 vs RSS 2.0 and future development and I figured this would be a good time to have a constructive talk.

The only thing I was worried about was that maybe Dave would become defensive and not realize that I really wanted to have a constructive dialog.

The first thing I did was introduce myself. I don't think he realized that "Kevin Burton" is the same "Kevin Burton (burtonator)" from the RSS 1.0 Working Group. I guess this is acceptable, after all what are the odds that we would randomly bump into each other while the (Userland?) RSS 2.0 spec was pending finalization.

Right off the bat we started talking about RSS. I wanted to talk about "The End of RSS Innocence" article that I blogged about the other day and that he linked to from scripting.com

The thesis of the article was that RDF integration within RSS was inevitable. I think I did a very good job proving this and I wanted to see what he would say.

His basic response was just that RDF was a joke and the Semantic Web developers are doing a terrible job. I was somewhat offended by this statement and tried to clarify my position in that some of us (under rss-dev) are trying work to towards making the SW more usable and realistic.

...

The conversation kind of stopped at this point... I didn't want to go down this path, I wanted to keep everything constructive.

...

I decided to offer a few olive branches between RSS 1.0 and RSS 2.0. My thinking was that my mod_link [2] proposal and recent GUID ideas would be really nice within RSS 2.0. I certainly wouldn't have a problem seeing this happen.

The second I mentioned rss-dev and mod_link Dave started to become visually agitated and said some very insulting things. Here are some choice quotes:

"You took my work and put *your* name on it"

"You hijacked my Intellectual Property"

"They ripped off my ideas"

"You guys are thieves."

These were probably the least offensive things I can blog ... There really wasn't any profanity used but I certainly didn't find them friendly.

...

This was about 60 seconds into the conversation.

At this point you have to remember that I have never met Dave Winer before. We talked for a few seconds a the Emerging Technology Conference when he "objected" to something a friend of mine said about Microsoft (objected is being polite).

...

After this I tried to make it clear to Dave that I really wanted to stay productive. This meant interrupting him in mid-sentence and explaining my situation at which point he again became visibly upset...

This is about 90 seconds...

...

The conversation calmed down again (that is good). Then I tried to bring up my recent thoughts on secure GUIDs [5] and reification within RSS 1.0 and RDF (I think this is huge).

You see RSS 2.0 has a GUID element based on the permalink/URL concept. My recent idea are that we need a better GUID implementation (read the blog entry for more info)

Dave basically said "RSS 2.0 has GUIDs", and I said "but they are not secure and aren't really GUIDs".

Dave basically said that "I don't care about security", and then I jokingly said "Yeah, who cares about security?! This is only the Internet!" (making it clear that this was a joke - at least that was my attempt).

At this point Dave basically "lost control" (for lack of a better description)

"How dare you! Who the hell are you to question me about security?!"

At this point I basically ended the conversation and moved to the other table with my friends.

I then heard Dave continue to briefly talk about the issue when I was sitting at the other table. I distinctly heard "That guy is an idiot!" ...

Total elapsed time: around 5 minutes.

...

For the record (for people who have never met me in person), I am a very easy person to get along with. It is a rare occasion for me to be involved in a something like this. I am usually able to find a common ground with anyone so that constrictive communication can take place.

...

So what the heck happened Dave? I really wished we could have had a decent conversation. It would have been a great opportunity to interact and move forward and exchange ideas. I really tried to take the right path and stay constructive and I wish you would have done the same.

3. http://www.purl.org/rss/1.0/modules/link

A number of people have suggested that RDF and RSS need to support GUIDs for RDF/RSS triples.

RSS 0.94 has support for a GUID. Bill Kearney (Syndic8 creator/developer) has mentioned that he needs GUIDs for RSS. Reptile needs GUIDs to refer to RSS items. In short a lot of RDF/RSS software needs support for GUIDs.

I would like to propose a method to support GUIDs within RDF/RSS that is:

Explanation

Why do we need GUIDs when we have URIs?

Are these the same?

<item> <title>foo</title> <link>http://www.foo.com</link> </item>

<item> <title>foo</title> <link>http://www.foo.com</link> </item>

(answer - yes)

How about these:

<item> <title>foo</title> <link>http://www.foo.com</link> </item>

<item> <title>bar</title> <link>http://www.foo.com</link> </item>

(answer - no... they use the different titles)

The second set is not identical and using the link as an identifier will fail and result in unusual behavior when used within RSS aggregators and RDF agents.

One could say "hash the whole item"... that may work. One would need to use the dsig canonicalization method.

The only problem here is that what if the user adds metainfo:

<item> <title>bar</title> <link>http://www.foo.com</link>

<dc:description>

Break the hash by adding new data.

</dc:description>

</item>

This would break a hash if it were used as a GUID.

This means we need a GLOBAL unique identifier. This has to be generated from the RSS source when publishing. The only problem is that humans are terrible at managing this GUIDs with the required amount of entropy:

"Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. (They are also large, expensive to maintain, difficult to manage, and they pollute the environment. It is astonishing that these devices continue to be manufactured and deployed. But they are sufficiently pervasive that we must design our protocols around their limitations.)" - Kaufman, Perlman, and Speciner quoted in Anderson's 'Security Engineering'

I am using UUIDs in my peerfear.org feed :

<item record:uuid="1030570664">

One solution for this problem is to use the SHA1 message digest algorithm (hash) to compute the GUID.

SHA-1( channel/rdf:about + item/rdf:about + item/title +? item/description )

Of course this would need to happen on every RDF schema/vocabulary that exists (only a problem for vocabulary developers). The channel/rdf:about element is added to localize the GUID to a specific channel.

This would allow GUID generation within user agents but wouldn't place the burden of management on the user.

This would require the base (title, link, description) RDF triples and RSS items to be immutable. If one changed an RSS item at runtime it is essentially a new item (as far as aggregators that are using the GUID are concerned)

The only problem with this proposal is that GUIDs would break if the user changed the channel rdf:about (channel URL). This would only be a situation if a peer were to get a handle on old RDF/RSS triples/items without having a handle on the old RDF channel link. In this situation we would need a mechanism for including the RDF channel link of the old RSS feed. It is recommended that the channel be duplicated in whole (including channel) when syndicating cached content.

Security

Security is very important with this mechanism. UUIDs (128 bit non-colliding IDs) and automatically generated URIs/URLs MUST NOT be used. This mechanism of GUID use is not secure and it would be possible for an attacking peer to us the GUID of another triple and convince a peer to use the GUID of an invalid item.

The symptoms of an attack could range from invalid cached entries, broken reification, and even potentially harming the reputation of a producer (making a statement about a GUID that was incorrect (Alice (friend) is stupid).

SHA1 hash based GUIDs avoid this problem by placing the burden of GUID calculation on RDF/RSS aggregators. Hashes can be validated locally by an RSS aggregator and easily generated for RSS channels (and RDF) that don't support GUIDs.

No Producer Obligations

RDF/RSS producers MAY include the GUID within their RSS feed via the rdf:ID attribute but are not REQUIRED to do so. Non-RDF vocabularies MUST NOT include GUIDs unless support is explicitly added.

Note that the inclusion of GUIDs within an RSS feed will only bloat the RSS feed and should rarely be used in practice. There are a few scenarios where RSS aggregators may choose to use GUIDs explicitly so that they make it clear what GUID they are using within their own internal database.

Portable

The GUIDs generated are portable across RSS implementations, can be used within

any XML and can be somewhat easily managed by humans (note that hashes are

Compatible

This method is compatible with all versions of RSS even if they do not support GUID generation. the only caveat is that if the version of rss in question does not support modules the GUID MUST NOT be included within the rss. It may only be computed by RSS aggregators.

Mutable Statements

Statements can be mutable except for the base elements. For example you can add Dublin Core metainfo, any RSS 1.0 module, additional XML and namespaces, additional RDF all without breaking the GUID.

The only requirement is that the base elements not be modified. If they are this will generate a new GUID and a new triple (as far as a user of the GUID is concerned)

Supports (distributed) Reification

Since GUIDs can be calculated for any RDF triple we can support distributed reification. For example (remember GUIDs are verbose but optional and not required by producers):

<item rdf:ID="urn:sha1:1b17864eeb6c68294c9b2db0324a2b773401f0da0537d82626c24a7850e15ef2d6c4265dcd5e85f1" rdf:about="http://www.cnn.com">

<title>CNN</title> <link>http://www.cnn.com</link>

</item>

<item rdf:about="urn:sha1:1b17864eeb6c68294c9b2db0324a2b773401f0da0537d82626c24a7850e15ef2d6c4265dcd5e85f1">

<dc:description>CNN is a cool website that is 0wned by a big company</dc:description>

</item>

The second triple adds a Dublin Core description to the first entry.

Representation and Calculation

All GUIDs are calculated with the following method:

sha1(item)

The GUID is then represented as:

urn:sha1:base32(canon(rdf:about + BASE_CONTENT))

Note that all RDF vocabulary and RSS modules are required to specify what is included as "base" content so that canonicalization can take place. Usually this is just going to be the required elements and high use optional elements.

For RSS 1.0 this would be title, link, and description, and would support Dublin core metainfo as mutable additions.

Note that it is possible for aggregators can use their own hashing algorithm but a HASH URI is required if someone wants to refer to a specific RSS item or RDF triple in a standardized manner.

The burden is placed upon the GUID producer to use a hashing algorithm that is supported by the majority of others if GUIDs are included within the feed.

The urn:sha1 hash mechanism MUST be supported by all aggregators that support GUID.

Feedback

I would like to officially request feedback on this idea. If RDF/RSS Working Group members think this is a good idea I would like to push this towards standardization and to develop much better documentation.

There has been a lot of RSS activity recently both on the public mailing lists (syndication, rss-dev, aggregators, etc) and with conversations I have been having with people within the industry.

All of this is related around one central thread; RSS is growing, we are moving into new areas, and we are staring to experience some growing pains.

The Present

There seems to be a number of issues which desperately need some attention: