Tag Archives: rss

Gizmodo on RSS

David Nield of Gizmodo has a sort of re-introduction to RSS, with an overview on why it’s more useful than ever:

One of the main reasons RSS is so beloved of news gatherers is that it catches everything a site publishes—not just the articles that have proved popular with other users, not just the articles from today, not just the articles that happened to be tweeted out while you were actually staring at Twitter. Everything.

Obviously I’m a fan of RSS. Micro.blog has great support for it throughout the platform. But even though I subscribe to hundreds of feeds, I even caught myself recently loading a few favorite news sites manually instead of using the feeds. Doesn’t hurt to be reminded that there’s a better way.

Fake news on Apple News

I don’t use Apple News very often. I much prefer reading blogs in Reeder and Micro.blog, with a daily check on the other news sites I pay for. But last night I noticed a headline in the iOS today screen and tapped over to a few stories in Apple News.

Scrolling down in the “For You” tab about politics I was surprised by a couple news stories about a plan by Democrats to “silence non-liberal media” (People’s Pundit Daily), and another on the Trump-Russia “collusion fantasy” (The Daily Caller). These were right-wing opinion pieces sprinkled with conspiracy theories, yet placed next to reputable news organizations like The New York Times, CBS News, and Politico.

Apple News screenshot

I thought Apple News was highly curated and better than this. Personal essays are fine in Apple News, because that’s part of blogging, but they shouldn’t be suggested to a mainstream audience looking for real news.

Apple podcast spec changes

At WWDC last week, Apple introduced changes to their RSS feed extension for podcasts. Before reviewing the session, I was worried that Apple would be moving to Apple News Format instead of RSS. That would’ve been a major setback for the open web, since Apple News Format is such an app-specific, closed format, controlled by a single company. Luckily the actual changes Apple introduced are pretty minor and shouldn’t upset the status quo much.

There are 2 sets of changes: support for supplementary episode types, like bonus content; and metadata for show seasons, likely influenced by popular shows like Serial, where people new to podcasts might be confused about where to start listening. There are a few new tags for these types of shows under the itunes RSS namespace.

Episode type is the simplest change. It looks like
<itunes:episodeType>full</itunes:episodeType>
and can have values “full, “trailer”, or “bonus”.

For seasons, the episode number and season number can be split into separate elements. It’s compatible with the traditional RSS title, so there’s little downside except extra clutter in your RSS feed. Here’s an example:

<channel>
  <itunes:type>serial</itunes:type> <!-- or "episodic" -->
  ...

  <item>
    <title>S01 Episode 01: The First Episode</title>
    <itunes:title>The First Episode</itunes:title>
    <itunes:episode>1</itunes:episode>
    <itunes:season>1</itunes:season>
    ...
  </item>

</channel>

Jason Snell’s first reaction to these changes was positive:

I’m excited by these changes because, yes, some of my podcasts are seasonal and are best consumed from the first episode onward. I’ll be adjusting my own podcast feeds to take advantage of Apple’s extensions as soon as it makes sense to do so.

Ben Thompson covers the extensions briefly and then focuses his weekly article on analytics and podcast advertising:

The new extensions are a nice addition, and a way in which Apple can enhance the user experience to the benefit of everyone. As you might expect, though, I’m particularly interested in the news about analytics. Problem solved, right? Or is it problem caused?

After reading Ben’s take, I don’t think these changes are significant enough to have much effect right away. That should be a relief to all of us who love podcasts and don’t want a shake-up.

When designing JSON Feed, we resisted adding everything that Apple Podcasts needs to the official spec. Now that more podcast tools have adopted JSON Feed, I expect there to be a discussion among developers about the best path forward for podcast-specific extensions in JSON Feed. That discussion should now include support for show seasons, too.

JSON Feed for podcasts

JSON Feed includes an attachments array, which is similar to the enclosure element in RSS that enabled podcasting. We love podcasting and included an example podcast feed in the JSON Feed specification. However, because the Apple podcast directory and its RSS namespace are so central to many podcasting tools, it wasn’t clear how quickly podcast apps would adopt JSON Feed.

The answer is: pretty quickly. This week we’ve seen announcements from Breaker, Cast, and Fireside. Actually not just announcements, but working implementations to parse or generate JSON.

I’ve also pushed up a change to the WordPress plugin on GitHub to add support for attachments. After some more testing, I’ll update it in the WordPress directory.

Update: FeedPress also just announced support for JSON Feed. This is another important one for bloggers and podcasters. It effectively gives a JSON version to everyone using FeedPress, even if the FeedPress customer’s site is still backed by an XML feed.

Dave Winer on title-less posts

Dave Winer posted today about NetNewsWire needing better support for title-less feed items:

These items have no titles for artistic reasons. The author did not put them there. You, as a software developer, are not entitled to add them (haha that’s a pun).

I agree with Dave on this. Titles are clearly optional in the RSS 2.0 spec. The fix for the “Untitled” text that some feed readers use isn’t for authors to add titles where they aren’t needed, it’s for the UI in feed readers to improve so that they gracefully handle title-less posts.

(And this is not to pick on NetNewsWire. I’ve seen other apps and feed syncing services with the same assumption about titles.)

When I wrote about defining a microblog post, blank or missing titles was one of the fundamental points. If we want to have blogging software that’s as easy to use as a modern social network, titles can’t be required.

I’m hopeful that as feed readers adopt JSON Feed, developers will dust off their older code for feeds and make improvements for title-less RSS items as well. This is why we highlighted microblogging as a use case in the JSON Feed spec.

JSON Feed

Really excited to announce JSON Feed today with Brent Simmons. It’s great to see all the feedback and links to new feeds. Special thanks to everyone who contributed to the spec, debating field names and requirements over the last few months.

The premise was simple: the time is right for a JSON-based approach to feeds. We hope that JSON Feed is straightforward enough to be implemented quickly, and capable enough to push the next decade of blogging software forward. We love RSS too and tried to learn from its success.

Micro.blog already supports JSON Feed nearly everywhere. There are feeds for hosted microblogs and your timeline, and the Micro.blog custom JSON API itself is actually just JSON Feed with Micro.blog-specific extensions.

I’m looking forward to seeing what everyone does with this. If you’ve shared any code or templates for JSON Feed, or if you’re working on apps to support it, let us know.

Where I post everything

My content is all on this blog or linked from it, but if you’re following RSS feeds or Twitter it’s not as obvious where everything is posted. Here’s a summary to clear things up.

Microblog posts: Posted here and in a special RSS feed. Also automatically cross-posted to Twitter and App.net, with some occasional truncation.

Longer posts: Posted here and in the default RSS feed. Also automatically cross-posted to Twitter and App.net with the title and link. Twitter cross-posting is handled by my upcoming Micro.blog platform.

Photos: Posted to Instagram and then copied here using this workflow. They don’t show up in either of the RSS feeds above. They’re not cross-posted to Twitter.

Timetable: Posted to timetable.fm which has its own feed. Discoverable in your favorite podcast client.

Core Intuition: Posted to coreint.org. I’ll usually post a link here on the blog for each new episode.

All posts: Switching to WordPress brought a new global RSS feed, but I redirect it to the longer posts for now. There’s a new everything RSS feed which contains all posts: microblog, full posts, and photos. Enjoy!

An open Twitter starts with the web

Dave Winer wants an open alternative to Twitter:

I want it to be friendly to Twitter, because as a user and a shareholder, and a developer who uses their platform, I want to see it thrive. But I also strongly believe we need the open system, the Central Park to Twitter’s condo buildings on Fifth Ave and Central Park West.

John Biesnecker, reading Dave’s post, suggested XMPP because it’s an open standard and federated. But as great as XMPP is for messaging, it seems too different from the web; it would be like starting over. The nice thing about building on independent microblogs is that we can leverage the existing open web infrastructure: all the WordPress installs, RSS feeds, and new work from the IndieWebCamp.

That’s what I’ve tried to do for Snippets.today. Learn from the UI innovations of Twitter — the fast timeline experience, the effortless posting — but without skipping the important first step of independent web publishing.

The evolution of linkblogging

In my posts about defining what makes a microblog post and guidelines for RSS, I talked a little about links but didn’t explore linkblogging. While many blog authors post primarily long essays, shorter link blogs are a common approach for bloggers who want to post new content several times a day.

Essentially two types of link blogs have evolved since the early days of blogging. The most traditional link blog can be seen in Dave Winer’s posts (click on the Links tab). These are links with a very short commentary. Many tweets are like this. In a way, this format is the purest form of microblogging.

The second type of link blog starts to fall outside the limits of microblogging. Instead of just including a URL, authors use a quote from the linked material as the foundation for the post. The majority of Daring Fireball posts adopt this format. While John Gruber is known for his full essays, those longer posts are infrequent today. He keeps his site active by linking to other interesting essays and tacking on his own brief opinion.

Daring Fireball has become so successful that Gruber’s approach to linkblogging has been copied by many other sites. MacStories, Six Colors, One Foot Tsunami, John Moltz’s Very Nice Web Site, and Marco Arment’s blog are just a handful that follow this pattern. All of these sites post the occasional essay, but most blog posts link away to an external site in the RSS item, not back to their own site.

At a technical level, this difference can best be seen in the RSS feed’s <link> and <guid> elements. These elements will contain URLs that either link back to the main site, or link away to an external site.

Here is where this evolving approach to link blogs starts to break down. Let’s take an example from Six Colors, one of my favorite sites. (I recommend subscribing. The members-only secret podcast with Jason and Dan Moren is really fun, and the email magazine is great too.)

In a link post about Hulu’s pricing, Jason Snell actually writes 4 paragraphs of commentary (plus a footnote). This is more like an essay than a short link post that points to the external site.

Another example is when MacStories linked to Twitter’s launch of Moments. A few paragraphs of quoted text, 5 paragraphs of MacStories commentary. The commentary is as important or even more important to read than whatever Federico is linking to.

Sometimes we read sites like MacStories, Six Colors, or Daring Fireball more for the commentary than for what is being linked to. But when using an RSS reader, there is too much confusion about where an item’s link goes when clicked if the site’s feed isn’t consistent about linking everything back to its own site.

And in fact Jason Snell acknowledges this problem by offering two separate RSS feeds: the default one, with a mix of links back to Six Colors for essays and pointed elsewhere for link posts; and another feed with everything linking back to Six Colors, where the commentary lives. He also attempts to minimize confusion on his own site by giving each type of post its own icon in the site design.

The less clear-cut the distinction between essays and link posts, the more confusion we introduce to readers. In some ways, this mixed approach really only works for Daring Fireball, because his feature essays are so long, and so obviously different in format to the rest of the link posts.

Good conventions for blogging have been at a standstill for years. While part of the appeal of indie blogging is there’s no one “right” way to do it, and authors can have a strong voice and design that isn’t controlled by a platform vendor, we must accept that Twitter has taken off because it has a great user experience compared to blogs. It’s effortless to tweet and the timeline is consistent. For blogging to improve and thrive, it should have just as straightforward a user experience as social networks wherever possible.

Luckily, RSS already has everything we need for clients to visually distinguish between link posts and regular ones. If the <link> element points to a domain other than the one for the site, it’s probably a link post. If the <link> and site domain match, it’s a full post.

I’ve adopted this in my new microblogging platform by exposing the domain in the UI itself, at the end of the title or microblog post whenever it’s a link post. If it’s a full post, the link isn’t added. And for either type of post, the timestamp links back to whatever was in the <link>.

Here’s a screenshot from one of Dave’s posts. Note that the link was not in the RSS text. It was added by my app automatically:

linkblog example

This has been a long post, but it boils down to two simple recommendations:

  • If you’re a blog author and you’re adding any significant commentary, the RSS feed should point back to your site.
  • If you’re an RSS client developer, the difference between link posts and full posts should be exposed in the UI.

I believe that adopting these will bring more consistency to blogging. Users won’t need to hover over links, or guess what will happen on a click or tap. It’s a small change that will make reading blogs a little better.

Dave Winer on Instant Articles

Maybe I misjudged Facebook’s Instant articles. Dave Winer is a supporter, because it builds on RSS:

“Facebook is using open web technology to power Instant Articles. I’m not sharing anything that isn’t already publicly documented on the Facebook developer site. People have trouble understanding this, I assume, because it seems so out of character for a big web destination like Facebook to care about the open web. It’s kind of a miracle. But there it is. The open web is about to get a real shot in the arm from a most unexpected place.”

I guess one question is whether there will be any other RSS readers that support Instant Articles. If we can get some of the benefits of Instant Articles, but outside of Facebook, that is something.

Typed.com progress updates

The folks at Realmac have been blogging about their progress with Typed.com, a new blogging platform that successfully raised $120k on Indiegogo last year. In the latest monthly report, they announce a new free tier:

“With this new free tier, people can sign-up, use the service, take their time. They can blog for free, for as long as they want, and when they need or want the extra features we offer they can upgrade to a paid account. We also think this will be free marketing for the service, the more blog out there that are hosted with Typed.com then more people will find out about the service.”

This blog is in the spirit of Buffer’s open blog or Ghost’s Baremetrics reports. It’s especially great to see a company sharing numbers when they know they still have a lot of growth ahead of them to get where they want to be.

If you’d like to start a new blog but aren’t sure where to host it, check it out. Typed.com has a well-designed admin UI that is refreshingly simple compared to much of the more bloated web software out there.

It’s also possible to use Typed.com as a microblog. I pointed to some tips for this last year. Since the title of a post can’t be blank on Typed.com, I suggest using a date/time for the title. My new microblog platform is smart about treating those kind of short posts correctly when reading from an RSS feed.

River5 and twtxt

Two new microblog-related services have launched. This week, Dave Winer announced River5:

“So I decided it was time to do a restart of my JavaScript RSS aggregator, and it’s now ready for Node users — it’s called River5. […] This is a foundation for developers to build on, but it’s also possible for an adventurous user to set up their own rivers.”

River5 is built on a few XML and JSON formats, including River.js. I’m pretty interested in River.js as a format for aggregating multiple feeds together, so I’ve supported it in my new microblog platform. As a next-generation RSS, though, I prefer the proposal I wrote about in a post called RSS for microblogs.

Next up is twtxt, which attempts to recreate Twitter as a distributed, command-line based system with self-hosted text files:

“Instead of signing up at a closed and/or regulated microblogging platform, getting your status updates out with twtxt is as easy as putting them in a publicly accessible text file. The URL pointing to this file is your identity, your account. twtxt then tracks these text files, like a feedreader, and builds your unique timeline out of them, depending on which files you track.”

I’m less sure what to think of twtxt. The simple plaintext format is nice, but we already have a good infrastructure for this with RSS. And as I’ve noted before, having HTML in RSS with inline styles and links is nice for microblogs, and it’s not clear to me whether that would fit well with twtxt.

If you want to start an indie microblog, my suggestion remains to use existing blog software that can generate simple RSS feeds. Short posts, no titles. This is a widely-deployed format that we can continue to work with for years to come.

Dave on short blog posts

Dave Winer gives 3 reasons why you should be posting short items to your blog, including:

“Maybe your blogging software doesn’t support short items? Don’t worry, if people post more short items the software will adjust.”

I’m counting on this. I have a separate RSS feed for microblog posts, and it doesn’t look great in some news readers because the title is blank. Some folks have asked whether I should include a fake title there — the first few words of the post, or a timestamp. But the RSS spec is clear that title is optional. Only by breaking things a little will RSS readers improve to gracefully support title-less short posts.

A diverse community through writing

I read a lot of weblogs. RSS is a great way to keep up with sites that update infrequently, or that aren’t popular enough to bubble up on Twitter with dozens of retweets. But the Mac and iOS community has grown so much over the years. I know there are many new writers who haven’t been on my radar yet.

Brent Simmons has posted a great list of tech blogs by women that I’m going through now. There should be something there for anyone interested in development or design:

“I made a list of some blogs I already knew about, and then I asked my friends for more, and they totally came through.”

The list grew to include over 50 blogs as suggestions arrived to Brent via Twitter. I’ve already subscribed to a bunch and look forward to discovering even more.

One of my favorite new blogs is the travel blog complement to Natasha The Robot, which made Brent’s list. Natasha was recently hired at Basecamp, runs the This Week in Swift newsletter, and writes on her new blog about working remotely. From a post about taking her laptop to restaurants in Europe:

“The nice thing about this is that I get a really cool and inspiring office for a few hours – each cafe or restaurant has it’s own vibe, people, music and I don’t feel rushed internally knowing that I need to go back to my apartment or coworking space to actually work.”

When I quit my day job this year, it was partly so we could travel more without worrying too much about my work schedule, outside of when the kids are in school. In fact, just days after I finished writing my two weeks notice blog posts, we went to Europe and started a private family blog about the trip. So I’ve been inspired by Natasha’s blog as she shares her experience working in different cities.

And that’s a theme you’ll find in many of the developer-oriented blogs on Brent’s list. Wanting to get better, learning something new, and then sharing it with everyone else. Take this advice from Becky Hansmeyer, who wrote a daily series of posts about what she learned building her iPhone app, one post each day while she waited for her app to be approved by Apple. From day 4, on design and color:

“I think the biggest thing I learned in choosing colors and fonts for my app is not to get too hung up in making comparisons to other apps. I spent a lot of time looking at my favorite apps like Overcast and Tweetbot and thinking about the decisions the developers made, and as a result I wound up feeling like I had to make those same decisions. But that was stupid because my app is my own and is also designed for a much smaller market.”

Or this quote from Kristina Thai, who wrote a post about preparing to give a talk for the first time:

“My presentation didn’t flow, it was jagged and very rough around the edges, but I kept at it, made some changes and it got better. And better. And even better. And then I practiced it in front of a couple of friends who gave me even more feedback until I was ready.”

Kristina also gave a talk called Become a Better Engineer Through Writing. You can get a sense of the talk by downloading the slides. It covers the value to programmers in keeping a private journal, why you might write tutorials for your site, and makes a strong case for blogging.

Blogging isn’t difficult, but it’s still not yet as easy as tweeting. By creating a blog, you’re making a statement that you care about something. As I go through Brent’s list of bloggers, that’s what I’m looking for: what does the author care about, and what can I learn from or be inspired by in their writing? Because the more diverse our RSS subscriptions are — the more varied the opinions in what we read and share with others — the closer it gets us to a strong, healthy community.

Blips microblog

Jussi Pekonen has relaunched his weblog, with a new focus on microblogging:

“I want to own all content I produce. That way I can ensure that everything I write does not go the way of the dodo when the latest and coolest microblogging platform goes belly up.”

He calls the short posts “blips”. I call mine snippets, which I borrowed from Noah Read. I like both names, but even more importantly, I like Jussi’s approach to owning his own content and providing a simple RSS feed of microblog posts. (I wrote more about RSS and microblogs a couple weeks ago.)

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">
    <channel>
        <title>Manton Reece</title>
        <description>Manton's weblog.</description>
        <link>http://www.manton.org/</title>
        <item>
            <title></title>
            <description><![CDATA[
                <p>Hello world.</p>
            ]]></description>
            <pubDate>Fri, 04 Sep 2015 15:32:32 +0000</pubDate>
            <guid isPermalink="true">http://www.manton.org/2015/09/3007.html</guid>
            <link>http://www.manton.org/2015/09/3007.html</link>
            <author>@manton</author>
        </item>
        <item>
            ...
        </item>
    </channel>
</rss>

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.

JSON

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.

Authors

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.

Medium.com updates

Ev Williams announced a batch of new Medium features recently:

“There’s always another level. Another level of polish and power in our product. Another level of breadth to our content. Another level of dialogue and discussion. And another level of progress. Today, we are announcing a slew of updates to bring Medium to the next level and in the process make it more powerful, more fun, more democratic, and more essential.”

Those updates include new mobile apps, @-mention support, a publishing API, and editor improvements. There’s also a new logo. (I know they put a lot of thought into this, and it’s a strong idea, but to me the logo’s design is so clever it’s actually kind of distracting. A little more subtlety in how they’re using depth could improve future iterations.)

Daniel Jalkut blogs about what’s included (and what’s left out) in Medium’s new API:

“One of the most unique aspects to Medium’s API is the provision for specifying a canonical URL and license on a post being submitted to the service. The canonical URL refers to another web location that should be considered the original, or most authoritative version of a post, while the license designates whether the post’s copyright terms stipulate a post is sharable as public domain or under a particular Creative Commons license. These attributes together indicate that Medium expects and encourages users of the API to contribute content that is not intended to be exclusive to Medium.”

While I generally think the trend to centralized writing platforms is bad for the web, I’m happy to see these changes from Medium, especially the API and expanding custom domain support. Medium has grown very slowly and carefully. I expect we’ll see quicker iteration on these new features now that they’re officially out.

In the process of experimenting with Medium posting, Dave Winer shared his take on post title support:

“It seems they have arrived at what I think is the correct answer: posts can have titles or not, and the content system has to be prepared for either case. That’s where this blog was in 1999, before other blogging tools and Google Reader pushed the world toward requiring titles. And then Twitter came along not having titles at all, and the intersection between all the kinds of blog-consuming environments became almost empty.”

I’m very interested in this because microblogging shouldn’t include titles. While Medium is mostly traditional essays, clearly comments don’t need titles, and Medium’s quick-posting UI encourages short posts. I hope this approach will get more RSS readers to gracefully handle title-less posts.

The Lightbox

In 1999, I started a link weblog to collect news about animated films. I updated it for a few years, until there were plenty of other good news sources from industry writers more qualified than I was to run such a site. I was just a fan.

The site was a homegrown MySQL database and set of PHP scripts. Somewhere along the way, I lost the archive, and never noticed that the site had broken until today. To make matters more difficult, I had blocked it in my robots.txt, so the Internet Archive copy (which existed, at least in parts) wouldn’t load cleanly.

I took some time today to piece it back together as a new static HTML file and (partial) RSS feed. I’ve preserved the original design and HTML tags. Fun rediscoveries in the HTML include spacer GIFs, <blockquote> to indent the entire page, and RSS 0.91.

I called it The Lightbox. It was just a linkblog. But now 16 years later, I’ve enjoyed skimming through the old posts.

I will return to Twitter when…

As I’m catching up on some news, two posts today about Twitter caught me eye. First, very big news via Federico Viticci, that full tweet search is available even to third-party apps. Twitter’s limited search was the main reason I originally built Tweet Library. It’s fantastic that this data is now more easily available.

But it was this opening paragraph from Jason Snell’s article on Macworld about Twitter neglecting the Mac version that got me thinking:

“Three years ago this month Twitter broke its covenant with the third-party developers who helped fuel its initial growth and create some of its most innovative features. The message was clear: Twitter was in charge of its own platform, and while other Twitter apps would be tolerated, it would only be in limited fashion and for a limited time.”

It was around this time, nearly 3 years ago, that I posted my last tweet. My bet with Daniel is over whether I will return to Twitter within 5 years. People ask if I’ll come back sooner, and if I did, what it would take. I’ve often struggled to articulate those conditions, because I think we are seeing slow but consistent progress to unwind the developer-hostile decisions made a few years ago. It may be that in a couple years the environment will be much improved, but there won’t be any single decision that “fixed” it, or it may be that Twitter is doomed to have changing leadership and there will never be any guarantees.

There is one thing, though. There is one change that was made while rolling out the version 1.1 Twitter API: they removed support for unauthenticated RSS feeds of user tweets or timelines. If they reversed that one decision, the next day I would be back on Twitter.

I can pick out a single feature like this, among every other improvement that third-party developers would love to see, because the combination of removing RSS and at the same time locking down the API — those changes together best represent the move away from the open web. Any other incremental improvement short of unauthenticated RSS, no matter how welcome, isn’t enough.

Embrace cross-posting

When App.net was first taking off, many microbloggers struggled with how to decide where to post their short-form writing. Should they post some topics to Twitter and others to App.net? Should they cross-post everything to both services? At the time, there was an informal consensus that cross-posting was a cheat. It couldn’t take advantage of each platform’s strengths, and followers might often see the same post twice.

I now believe that cross-posting is a good thing. Photos, as one example, are frequently cross-posted to both Instagram and Facebook. Tweets can be sent to Twitter as well as our own blogs. Many apps like Instagram or Foursquare support and even encourage cross-posting. It’s good for developers because it helps spread knowledge of the publishing app, and it’s good for writers because it means there are multiple copies of our content.

It’s no secret that I’m building a microblog aggregation and publishing service. The goal is for us to get back to our roots with blogging — to write on our own web sites first, not as an afterthought to Twitter. Cross-posting is an important bootstrap for that.

If you don’t have a blog, start one today. It takes minutes to set up, and hardly any more time to wire up automatic tweeting via IFTTT from your RSS feed. Start with cross-posting and see if something interesting evolves from there.