Tag Archives: microblogs

RSS for microblogs

RSS is solid. It’s lasted a long time with very few changes, and forms the foundation for subscribing to weblogs and delivering podcasts. It’s huge and the open web is a much better place because RSS exists.

But even if RSS doesn’t need to change, some types of apps would be better off if we took a fresh look at the elements in an RSS feed. What is really needed, and when faced with multiple “correct” options, which should we choose? As more writers embrace microblogging, it’s an opportunity to simplify our feeds and tools.

This is my proposal for a bit of housekeeping around microblogging. It’s not a new format. It’s just a guide for producing the best RSS. I’d divided this proposal into 5 sections below.

Minimum viable elements

Look at the average RSS feed and there’s a lot of junk in it that most RSS readers ignore. While there’s nothing wrong with including extra XML elements, we should strive for a feed that is simple enough to be easily read. The fewer redundant and unused elements, the more consistently that different RSS readers will interpret it.

Here’s an example of an RSS feed whittled down to its essential elements. Most feeds should look like this by default, and only add additional elements from the RSS spec or RSS extensions when it’s absolutely required (such as the enclosure element for podcasting).

<rss version="2.0">
        <title>Manton Reece</title>
        <description>Manton's weblog.</description>
                <p>Hello world.</p>
            <pubDate>Fri, 04 Sep 2015 15:32:32 +0000</pubDate>
            <guid isPermalink="true">http://www.manton.org/2015/09/3007.html</guid>

Title is optional

The existing RSS spec says that title is optional. In fact, in the early days of blogging, tools such as Radio Userland and Blogger didn’t even have titles. We got away from that with the popularity of Movable Type and WordPress, even though some modern apps like Tumblr still look at a title as unnecessary for certain post types.

With microblogging, the title will frequently be empty or missing. Do tweets have titles? No, and neither should short microblog posts published through a traditional blog platform. Skipping the title removes some friction in the writing process, making it easier to write a quick post and send it out.

RSS readers must be prepared for a title-less RSS item. Instead of inserting “Untitled” as the placeholder title, think about how your reading UI can accommodate microblog posts gracefully. Blank titles (where the title exists but is an empty string) are equivalent to a completely missing title element.

HTML post text

The description XML element in RSS wasn’t originally intended to support HTML. It was often a text summary or opening paragraph of an article, rather than full text. With microblogging, you always want the full text inside the RSS feed, including any styled text or inline HTML links.

Some feeds will include the plain text version of a post in the description element, and the HTML version in a content:encoded element, as specified by this RSS namespace extension. This should be avoided in favor of a single description element with the full HTML, using CDATA syntax to avoid escaping characters.

In modern apps, rendering simple HTML is common. If an RSS reader can’t show HTML, it should strip out the HTML tags itself. It’s not up to the feed to provide multiple versions. If both description and content:encoded are present in a feed while parsing, for compatibility it’s acceptable to prefer whichever includes HTML.


I said this isn’t a new format, but we should have the option of expressing RSS in JSON instead of XML format. Back in 2012, Dave Winer wrote about producing a JSON-based RSS feed, with a very literal mapping of elements. If our goal is to cleanup some of the edge cases of RSS, though, we can further simplify it. I’d suggest collapsing a few of the elements, so that it isn’t overly nested like XML, and to JSON-ify the item elements into a simple items array:

    "channel": {
        "title": "Manton Reece",
        "description": "Manton's weblog."
        "link": "http://www.manton.org/"
    "items": [
            "title": "",
            "description": "<p>Hello world.</p>",
            "pubDate": "Fri, 04 Sep 2015 15:32:32 +0000",
            "guid": "http://www.manton.org/2015/09/3007.html",
            "link": "http://www.manton.org/2015/09/3007.html",
            "author": "@manton"

This preserves the element names and overall feel of RSS, while being cleaner and more JSON-like. Note that it’s easy to embed HTML directly in the JSON description field. Because there’s no room for an isPermalink attribute, if the guid is a URL, it is always the permalink.


A feed for a microblog platform, or a group weblog, might include multiple items each from different authors. The RSS spec says that the XML “author” element is an email address, but that is very rarely used in real feeds.

Instead, the author element value should vary slightly from the original specification to include either a simple full name, or a username prefixed with the @-sign: <author>Manton Reece</author> or <author>@manton</author>.

What do you think? I’d love to hear any feedback via email. If you write on your own blog about this, send me the link.

Future-safe weblogs

It’s a common theme for Dave Winer to write about preserving our writing on the web. Today he outlines some criteria for judging whether a web host will last:

“The concern is that the record we’re creating is fragile and ephemeral, so that to historians of the future, the period of innovation where we moved our intellectual presence from physical to electronic media will be a blank spot, with almost none of it persisting.”

I think about this in 2 parts. The first is publishing your weblog to your own domain name. This ensures that your writing doesn’t go away and links don’t break when your web host goes out of business, because you can copy your content somewhere else and map your domain to that new location.

The second is some kind of host that will last forever. This is an unsolved problem. Hosting fees need to be paid, domain name registrations need to be renewed. It may be too big a leap to ever get there, but we could settle instead for better mirroring of content. I’d like to have my content mirrored automatically to GitHub Pages, for example, and maybe even Medium.

Imagine the life of a printed book from the early 20th century that has now survived generations. How was this possible? Many copies must have been printed, because some will inevitably be lost or destroyed. And when a library or bookstore is closed, copies of the book must be transferred to a new location.

This all follows naturally with a printed book, but to adopt the same pattern for digital works, we must go out of our way to create a system of mirroring and long-term storage that tries to match what happens in the real world automatically. It’s a great challenge.

Unfortunately very little has changed on this topic since I wrote about permanence 3 years ago. But we can change that. Open formats and auto-mirroring will be a key part of my new microblogging platform.

More quick blogging workflows

I had a great conversion with Seth Clifford one night at WWDC, about writing and blogging. We all want to get better at writing and posting more frequently. As I mentioned in yesterday’s post, the best way to improve anything is to do more of it, more often.

I believe there are two important facets to microblogging. The first is the timeline experience: a reverse-chronological list of posts from your friends, like you see on Twitter. The second is that posting should be effortless: if there’s less friction between your idea and publishing it, you’ll write more often. So a big part of posting regularly is just having a system that makes it easy.

Seth updated his iOS blogging workflow by using Drafts and WordPress’s email-to-blog feature. As a nice bonus, he gets Markdown files of each post saved to Dropbox:

“Drafts allows you to send email as an action. WordPress allows you to post into the system via email. Using a combination of the action and the Jetpack plugin’s email functionality, I can go from idea to published in seconds, without touching the WP iOS app (which continues to get better, but still isn’t fast) and get my local copy stored away.”

Also this week, Ben Brooks has switched his core Twitter posting to go through WordPress. He has a standalone microblog at benb.me where the posts live. They go out to Twitter automatically via IFTTT. Posting to a blog first and then Twitter second seems like a simple idea, but it is extremely powerful. Years from now you end up with an archive of all your short-form writing at your own domain. Not as an afterthought, but as the default.

The great thing about blogging is there’s no one correct way to do this stuff. I’m really happy to see these solutions from Seth and Ben, and I know other folks are working on similar workflows.

Microblogging with WordPress

I wrote at a high level how I improved my microblogging workflow before WWDC, but I’d like to use this post to show the surrounding details. I hope it’s useful to other folks who want to control their own content.

Post formats. Newer versions of WordPress have the concept of post formats. Normal blog posts have a “standard” format, but there are also these types: aside, image, link, quote, and status. For microblogs, I recommend “status”.

No titles. As I proposed in a previous blog post, for small posts we should revisit an original feature of RSS: the title of a post is optional. In fact, early blogging systems like Radio Userland didn’t even have a title field. When you’re writing a microblog post in WordPress, just leave the title blank, and if necessary update the post template to not include the title in HTML or the RSS feed.

RSS feeds. If you create a brand new WordPress blog for microblog posts, you won’t need to do anything special about RSS feeds. But if you share a single blog for both standard and status formats, you may want to have 2 feeds: one that excludes microblog posts and one that contains only microblog posts. Just use a special category for microblog posts in addition to the post format. Here’s a section of my .htaccess file where I use the “cat” parameter to include or exclude this category for my blog’s feeds.

iPhone posting. One of the lessons from Twitter is that posting should be effortless. Using WordPress on iOS is fine, but I’ve found that wiring up a simple posting recipe in IFTTT’s Do Note app makes it trivial to post from your phone. Use the WordPress action in IFTTT but also get this WordPress plug-in. Since the WordPress action can’t yet specify a post format, the plug-in can simulate it by using a special ifttt-status category. Here’s a screenshot of what my IFTTT recipe looks like.

Tweeting. Now that you have a blog that contains all your microblog posts, you can wire it up to Twitter to automatically cross-post them as tweets. You’re writing on your own site first, but the posts still go out to your Twitter followers. Again, use an IFTTT recipe that pulls from your microblog RSS feed and sends the post content to Twitter. Since I don’t post to Twitter, I’ve set mine to post to App.net instead. You can continue to reply and favorite directly on Twitter.

I’m very excited about the potential for microblogging. For the last year I’ve been working on a new platform around this stuff. By adopting some of these tips for WordPress, your microblog will be ready for my platform, but more importantly your blog will be open and extensible. Let’s get back to our roots with RSS and see what tools and web sites we can build.

WordPress microblog posting from Do Note

I finally have a great use for IFTTT’s Do Note app. I’ve wired it up to my WordPress blog so that I can quickly publish microblog posts there. Previously, if I was on the go I could use the official WordPress iOS app, but that requires a bunch of extra taps: setting the post format to “status”, setting the category to “Snippets”, and going back and forth between screens. Now all of those defaults are baked into the IFTTT recipe. (Grab this WordPress plug-in to set the custom post formats automatically.)

I also wanted to streamline my cross-posting to App.net, which before now had been a manual copy and paste. I use a pair of RSS triggers in IFTTT for this as well, to go from my main RSS feed and my microblog RSS feed. And at the same time, I’ve updated the CSS for my microblog posts so they look a little better over the web.

Effortless tweeting is a big part of what Twitter got right on user experience. With WWDC around the corner, I should be posting to my own microblog more frequently now that I have a good workflow.

If a tree falls

There’s no denying the fact that my writing would have a greater reach today if I was still active on Twitter and tweeting links there. Posting to my own microblog feed and cross-posting to the dwindling user base that is App.net has an obvious “if a tree falls in a forest and no one is around to hear it, does it make a sound?” aspect to it. If the post is read by so few people, some might argue that it can’t be as relevant to a larger conversation.

This doesn’t bum me out, though. It inspires me. It reminds me that I believe in something ambitious that has to be built in layers, starting small — a more open microblog platform that other apps can hang on to, encouraging new writing that will last.

Dave Winer calls this process of building successful platforms a coral reef. I think it’s a forest. Only the most passionate users of the open web can hear the tree falling today, but tomorrow there will be new growth. We plant a seed with each tool we build and with every RSS feed that’s wired up. There will eventually be many forests, crowded with plenty of people listening, interconnected regions that can’t be bound in the way a closed system inherently is.

If you join in and post, maybe your posts won’t be heard as clearly today. But in the future they will become the oldest, strongest pillars around which everything else grows.

Microblog links

Brent Simmons points to my post on microblogs and asks:

“Is the web we lost gone forever? Was it a brief golden age before the rise of Facebook and Twitter and The Algorithms of Engagement?”

But he quickly follows with an alternate view: that it’s a blip and we’ll get back on track. And that’s what I believe.

Instead of accepting a common opinion that Twitter is slowly replacing RSS readers, we should flip that around. What kind of changes could be made to RSS readers to embrace microblogging and make Twitter itself less important? Because once we do that, we get back control of our own short-form content and at the same time encourage open tools that will survive independent of whatever happens with Twitter and Facebook in the future.

I received some other great feedback about defining what it means to be a microblog post. One question that I didn’t address is links. Noah Read writes:

“It has consistently annoyed me that Twitter and App.net’s links count against my character count. It seems to run counter to what I love about microblogging, carefully chosen words communicating a succinct idea. I often have a pretty good tweet composed and then I paste in the link to a site or image and have to rework the whole thing.”

And David Ely says that a microblog post…

“Contains a single thought, a link with short commentary, or a photo with a caption.”

Whereas a full blog post would often contain multiple links. Certainly a lot of what is posted to Twitter and Facebook is just a single link with short commentary.

I also noticed recently that Dave Winer’s Radio3 includes links in the text when tweeting, but in the RSS feed the text and the link are split out. The URL goes in the RSS item’s link tag. While this is easy enough to support in tools, it’s surprising if you consider the link part of the content, not metadata. (I also expect inline HTML links to become even more common.)

Defining a microblog post

I’m working on a new project around timelines and microblogs. It consumes RSS feeds, so I’ve been wondering how strict to be when accepting posts. What does microblog mean, anyway?

Wikipedia defines it this way:

“Microblogging is a broadcast medium that exists in the form of blogging. A microblog differs from a traditional blog in that its content is typically smaller in both actual and aggregated file size.”

But that’s not quite specific enough. From my perspective, a microblog post has these qualities:

  • Must have an RSS feed.
  • Does not have an RSS item title.
  • Contains short post text, 280 characters or less.

Not having an RSS item title might take some getting used to for mainstream blogging clients and readers. Most RSS apps assume that all posts have a title, even though titles are technically optional in the spec. But I think this is an important distinction because if you think about Twitter-like posting, it should be fast and convenient; making up a title first interrupts the flow of posting.

I picked 280 characters instead of App.net’s 256 characters because it’s slightly less nerdy, and feels right at exactly double Twitter’s 140. This should be thought of as more of a guideline than a rule, though — just something to shoot for.

What do you think? I’d love to hear your feedback. Post to your own blog and then send me an email.

Owning the microblog

I mentioned earlier this year that I really liked how Noah Read posted tweets and photos to his own site, calling them snippets. I’m borrowing that name and implementing something similar here. If you visit my home page, you’ll see these short posts already interspersed alongside regular, longer posts.

These new snippets don’t show up in the normal RSS feed. There’s a separate feed at /snippets.xml for them, and they get their own category for browsing on the web. I’ll also be cross-posting them to App.net.

Like the posts in Dave Winer’s new Radio3, these RSS items don’t have titles. They’ll be short like a tweet or App.net post: usually 100-200 characters.

This is the first step in a larger project that I’m working on — something fun that reminds me of the early days of blogging. But if nothing else, it’s nice to control my own content again. I should have kept all these microblog posts on my own domain years ago.