Tag Archives: rss

Microblog timelines, Project Lightning, and River.js

I said that one important facet to microblogging is the timeline experience. This is a basic foundation to Twitter’s success, although they continue to de-emphasize or twist it. Their upcoming Project Lightning will attempt to curate and deliver tweets to you that are important regardless of who you’re following. From Mat Honan’s scoop on the project for Buzz Feed:

“Launch one of these events and you’ll see a visually driven, curated collection of tweets. A team of editors, working under Katie Jacobs Stanton, who runs Twitter’s global media operations, will select what it thinks are the best and most relevant tweets and package them into a collection.”

David Pierce wrote for Wired with further speculation on what it could mean for Twitter. David starts with the premise that Twitter is basically full of junk:

“Sure, yes, everyone’s Twitter is different—that’s one of the service’s best aspects, that you can follow anyone you want and see whatever you want. Unfortunately, this only works if everyone on Twitter isn’t terrible most of the time. They are.”

The essay continues, describing Project Lightning as the death of the Twitter timeline as we know it:

“With this change, Twitter doesn’t have to look like an endlessly flowing, context-free stream of tweets; instead, you can see a hand-curated set of tweets, links, images, and videos related to what’s happening right now. You see one at a time, swiping through them until you get to the end. And there’s an end!”

Since I haven’t seen this new feature, I can’t tell whether it’s a major shift in how Twitter is used. Federico Viticci is optimistic about it:

“This is another example of Twitter moving beyond Legacy Twitter and the belief that Twitter is still only a timeline of tweets in chronological order. The company has been enhancing the service with media improvements and design changes aimed at making Twitter less static – the opposite of a traditional timeline. If anything, they’ve been moving too slowly in this area.”

I agree with Federico on the value of curation and surfacing great content. But also the timeline must remain at the heart of Twitter, just as a reverse-chronological list of posts has been on every blog home page since the term weblog was coined 18 years ago.

Dave Winer calls these timelines “rivers”, and last week he open-sourced a browser for the River.js timeline files. Formatted as JSONP, you can think of River.js as conceptually the same as an RSS feed, except that it’s easy to display with HTML using only JavaScript.

I plan to fully support outputting River.js in the project I’m working on. For the last few years, Twitter has had a monopoly on the timeline. We need to break that up. The first step is encouraging microblogs everywhere, and the next step is to build tools that embrace the timeline experience. If you’d like to see my take on this, please sign up on the project announce list.

Apple News and RSS

Daniel Jalkut has an optimistic take on Apple News. He doesn’t think it is comparable to centralized publishing systems like Twitter or Medium for one important reason:

“Because the content doesn’t live on Apple’s servers. This is a key distinction in my mind. Apple’s News App serves primarily not as a source of information, but as an amplifier of it.”

Any technology that invokes “amplifier” in a review is something I want to pay attention to. I used the same word in the closing paragraph of my pitch for App.net. That service is fading away now, of course, but it’s just another reminder that even the most well-intentioned platforms are dangerous if they distract us from controlling our own content and hosting it at a custom domain.

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.

How to start a microblog

All my short, microblog-style posts go to my own weblog first, and also get cross-posted manually to App.net. You can view them in a special category and RSS feed.

I think owning your own posts on the internet — even if they seem unimportant and fleeting — is a valuable contribution to the health of the open web. By loosely following some simple conventions, we can build stuff that goes beyond what purely centralized web apps like Twitter are capable of.

Getting started is easy. I recommend one of 3 approaches right now if you want to play in this emerging ecosystem:

  • Tumblr. Microblog posts don’t need titles, and Tumblr has never cared much for titles itself. Some of Tumblr’s post types fit the style of a microblog very well. They also provide custom domain mapping, so that if you want to move your site later you can do it without breaking links.
  • Radio3. The latest version of Dave Winer’s tool can cross-post to Twitter. The setup couldn’t be easier, and because it has it’s own RSS feed, it will be easy to plug into future apps or get your data out.
  • WordPress. I use the self-hosted version of this. Just give microblog posts the “status” post type, which many WordPress themes can render with a tweet-like style. If you also put these posts in a special category, you can provide RSS feeds just for certain post types, or filter them out of your main feed.

Since last year I’ve been working on something new that is all about microblogging. I hope that it will encourage many more microblogs, but there’s no reason to wait until then. You can start a microblog today with one of the above apps (or dozens of other blogging solutions), and more fully control your own presence on the web.

Snippets category paging

Today I fixed some URL-related issues with this blog since moving to WordPress. Clicking through multiple pages of posts in a category now works again. I tweaked the category links slightly, dropping the .html extension, but all the old URLs are preserved through redirects.

Also a reminder if you’re subscribed to the RSS feed: my shorter, microblog-style posts go into the Snippets category, which is not included in the main feed. If you’d like to subscribe to those as well, just add the Snippets RSS feed to your news reader. I also still cross-post them to App.net.

Making RSS real-time

One of the critiques of RSS feeds in a world dominated by Facebook and Twitter is that RSS just isn’t fast enough. You can’t hope to achieve what Twitter calls “in-the-moment updates” and “watch events unfold” if your client is polling each web site’s RSS feed once an hour for new microblog posts.

Luckily this was solved years ago. Many blogging apps (including WordPress) have a setting to “ping” another server when a post has been published. When it receives this notification, the other server can request the RSS feed and make note of the new post right away.

There are a few flavors of this, such as just passing the URL of the updated feed, or sending an XML-RPC request, or passing the actual post content along with the ping as JSON. It may not be the most efficient or elegant solution, but it works well, and it’s significantly better than frequent polling. You could build something on this.

Some distributed Twitter clones try to come up with something more clever instead. And there are attempts like PubSubHubbub with significant traction. But adopting any new technology is hard, and this ping system is surprisingly well deployed already. Worse is better wins again.

RSS reading and writing

I’ve received so much feedback about microblogging that I haven’t had a chance to reply or blog about each one yet. This post from Dave Peck is especially interesting:

“For some time now, I’ve wanted a new kind of RSS client: one that reads and writes. Today’s RSS apps artificially separate us from the content we read. If we want to reply — if we want to participate in the conversation — we’ve got to use an entirely unrelated set of tools.”

MarsEdit of course was famously spun off from NetNewsWire. Early versions of NetNewsWire did three things: reading blogs, organizing ideas in a notepad outliner, and writing new blog posts. I think Brent was on to something with combining all these features, but I also totally understand wanting to simplify so that each component is as good as it can be. MarsEdit wouldn’t be as full-featured and polished today if it hadn’t been given that room to grow as its own app.

Also, don’t miss the last half of today’s Core Intuition. Daniel and I talk at length about microblogging and owning your own content.

Return to open APIs

In 2014, web app APIs basically look like this:

  • JSON or XML API layer for a web site’s content and functionality.
  • Potential client developers must register with the web site and get some kind of API key for access.
  • OAuth is used to grant access without giving out passwords.

A more cynical view of that last point could be rewritten as: OAuth is used to control and limit access so that the API is inaccessible without approval from the web site.

This all seems fairly normal today. I required an API key for Tweet Marker because that’s just what you did, especially if you wanted to charge or limit an API. But it didn’t always used to be this way — remember when you could hit the Twitter API with just a user’s password? — and it doesn’t have to be this way forever.

For my next web app I’m going to have an API that is more open, requiring no app registration. Instead it will be user-centric, with password tokens that a user can paste into their favorite compatible app for authentication. (My web app doesn’t have traditional passwords at all.)

Not having API keys removes a whole set of complexity: no need to write all the backend code to support managing them, no need for developers to register, no need for me to judge who should get access. Whenever possible, APIs should be nearly as open as the normal web, where Safari and “curl” don’t need to register with a web site just to download its home page. Users are in the best position to know which apps should get access to their account anyway.

If we can loosen APIs, I think it makes the web better. Dave Winer takes it one step further:

“What we really need, and I hope to help make happen, is a network based on open syndication of content. Then there is no one to ask for an API, because there’s no one in charge.”

I’ve been calling my latest project halfway decentralized. I’m still in charge, but just barely.

Updated feeds

When I migrated to WordPress and started a microblog section on this site, the RSS feeds didn’t transition very well. While the old feed continued to work, WordPress’s new default /feed URL returned both full posts and snippet posts.

I’ve fixed that today. Here are the official feeds on the site:

  • /rss.xml: All the main posts (like the one you’re reading right now), but none of the microblog-style snippet posts.
  • /snippets.xml: Just the microblog posts. These don’t have a title and will (eventually) be more common than the main posts, so you’ll need to subscribe separately if you want to see them.
  • /feed: Now redirects to /rss.xml.

If you want to see everything I write here, subscribe to both the main feed and the snippets feed. If you want to see only the longer posts, just keep the main feed. Thanks for reading!

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.

Twitter or RSS

I use Feed Wrangler as my RSS service, but I like this quote from Feedbin’s Ben Ubois:

“Twitter and Facebook are often cited as the reason for the decline in RSS usage. Where does content originate though? Right where it always has: on blogs and websites that probably have an RSS feed.”

It’s a great point. If you had to choose between only reading Twitter or only reading weblogs, which would you choose? Losing Twitter would be a bummer for a lot people, but losing weblogs would decimate the web. We should do more to strengthen weblogs and RSS because they are the foundation for so much of the most important writing on the web.

NewsGator and Sepia Labs

Great post from Brent Simmons, recalling his time at NewsGator. On trying to get Nick Bradbury to join them at Sepia Labs, the spin-off that was building Glassboard:

“I loved working with Nick in the past, and — even though Nick was an iPhone user and Delphi programmer — I wanted him as our Android developer. Nick was not eager to be on the NewsGator payroll again, but he accepted since we were spinning out into a separate company. And he quickly turned into a great Android developer, as we all knew he would.”

There’s plenty more, about the different stages the company went through from Brent’s perspective. I love posts like this. It’s important to capture the history and culture of tech companies, before our memory fades. And it’s not unlike what Brent has done on a bigger scale for his podcast The Record with Chris Parrish.

5 years until automation

For over 5 years and 122 episodes, every time we released a new episode of Core Intuition, I manually added the episode to the RSS feed using BBEdit. There was enough tedious XML copy-and-pasting that it was silly not to automate this process, but we kept putting it off. Finally last week, we switched over to an RSS feed generated by WordPress.

What surprised me is that until it was automated, I didn’t realize how much time I had been wasting editing and uploading the file manually. It was a small but very noticeable win last week when I could just upload the MP3 and click Publish, and that was it.

I’m not sure what the lesson is here. I never automate a task too soon, but 5 years was a long time. Maybe it’s just this: it’s never too late to get a better workflow.

More blogging, week wrap-up

My blog posts have always come in waves, ever since I started this blog 11 years ago. I’ll post for a few days straight, then nothing for weeks. And every couple years, I’ll declare that I’m determined to fix this broken pattern, and I’ll start blogging again nearly every day. It doesn’t last.

What I finally realized is that I have to be serious about posting every single day. If even one day slips by, the whole thing breaks down and I’ll fall back into ignoring it, because there’s the added friction of wanting to post something “great” to make up for the missed days.

If you subscribe to the RSS feed, you’ll notice that I’ve now been posting once or twice every day for about a week and a half. I don’t link to all of these posts from App.net, so here’s the recent ones you might have missed:

App Store old app maintenance:

“But if apps are an art form, an important part of our culture, then it shouldn’t require so much work to make sure they don’t disappear forever, so quickly.”

Smartphone religion:

“I got into the Mac in the 1990s during the lead-up to Apple’s certain doom, so I spent quite a lot of time arguing with Windows users.”

Moving off SendGrid:

“So it’s a good time to move away, to a company that I can pick based on merits and attitude and not just because it was the default choice.”

No new Apple products yet:

“Apple’s aggressive releases add even more anxiety about updating apps to keep up with the latest APIs and hardware.”

Start small:

“It’s a reminder to me that great things can start small, unambitious. I never would’ve guessed that a web comic artist starting so plainly would later produce a single strip that’s so incredible.”

Three ADN clients for iPhone:

“In this post I’m going to briefly review 3 of the most popular iPhone clients: Netbot, Felix, and Riposte. You can’t really go wrong with any of these three apps.”

Little Outliner:

“Yesterday Dave Winer and Kyle Shank launched Little Outliner, an impressive JavaScript outliner that uses HTML5 local storage.”

Apple and the impression of being small:

“But too many voices also creates noise, and noise makes simple things messy, confusing. Apple still gives the impression of being smaller than they really are because our view of them is heavily filtered.”

iOS text cursor swipe:

“While I was writing my review of ADN clients, I wondered aloud if Riposte or Felix or some other app entirely was the first to support swiping to move the text cursor. It seems a nice enough trick that someone should get credit for trying it first.”

iCloud sync narrative:

“Pretty sure we hit a tipping point in the iCloud just doesn’t work narrative this week. Whether that judgement is fair or not, Apple should drop everything to focus on making iCloud totally robust in time for WWDC.”

Climber for ADN:

“Toward the end of this week’s Core Intuition, we talked a little about the App.net file storage API and mentioned the new iPhone app Climber.”

Register a domain name:

“Using Facebook or Twitter or LinkedIn exclusively for your content is like an artist who picks their own colors but still stays within the lines of a paint-by-numbers kit. A domain name is your own canvas.”

Hotline servers:

“This article from Macworld is important because it will serve as a sort of Hotline software ‘about page’ for future internet searchers.”

Searchpath invoices and automation:

“Then life and other work got in the way, and weeks later I still hadn’t shipped it. I wanted it to be completely perfect and automated, so that I never had to think about it.”

I also got tired of the non-retina (and outdated tag-line) of the old header. I’ve started over with a plain blog design, finally dropping HTML tables for layout (!) in favor of Bootstrap CSS. A more complete new design will follow later.

Replacements for Google Reader

With the success of Tweet Marker, several people suggested I should build a sync server for RSS. This was last year and earlier this year, before Google Reader officially shut down, but after it was clear that we needed something better. I jotted down some notes for a couple ideas but ultimately decided not to do it. I’ve already got my hands full with my current shipping products!

Luckily many great developers are now on this. Feed Wrangler from David Smith, hopes for a possible NetNewsWire Cloud, more interest in Fever, and other established web apps like NewsBlur and Feedly. As Marco Arment said, this could end up being a great thing for innovation in blogs and RSS again.

But just because I’m going to watch on the sidelines for the server sync part of RSS, doesn’t mean I’m going to completely skip building better RSS support into my own products. There’s a lot I’d like to do with client-side RSS support in Watermark.

File format legacy

Last year I had to migrate the news blog section of the Staple! site from an ancient version of Movable Type (version 2.x) to Blogger. Even though Blogger has recently dropped features and seems mostly deprecated in favor of Google+, for this site there were a ton of existing users on Blogger. Upgrading just made sense.

However, what a file format mess. Export in Movable Type’s custom text format; import in Blogger’s Atom format. So first step is to find a service that’ll convert between the two, then manually fix up usernames so it imports properly. I exported, tweaked, and imported this file at least a dozen times before getting it right.

I was so frustrated because this wasn’t just accidental bugs. Developers made conscious choices that led us to this compatibility dead-end. They bet against Dave Winer and lost at a pivotal time in the development of blogging.

We had a format that was perfect for both blog syndication and as an interchange format between systems: RSS. Instead, some developers criticized RSS, then proceeded to create new products that have not been well cared for.

That is now part of their legacy. 10 years after blogging went mainstream, the end result of reinventing the wheel isn’t better software, it’s user frustration trying to get anything to work together.

This lesson keeps playing out, as if we’re doomed to repeat it with each new generation of file formats. Here’s this week’s post from Eran Hammer declaring OAuth 2.0 a failed format:

“The web does not need yet another security framework. It needs simple, well-defined, and narrowly suited protocols that will lead to improved security and increased interoperability. OAuth 2.0 fails to accomplish anything meaningful over the protocol it seeks to replace.”

If you have a choice, always pick the old boring format that works above the new hotness that is only theoretically better.