Tag Archives: adn

App.net archive

App.net officially shut down last night. As I wrote about earlier this year, App.net was an important milestone in the move to more open social networks. I’m glad the platform existed and I enjoyed participating there as a user and developer.

Linkrot and the lack of permanence on the web is a recurring theme for this blog. In the final days as App.net was winding down, I wanted to put my money where my mouth was. I spun up a couple new servers and wrote a set of scripts to essentially download every post on App.net. It feels like a fragile archive, put together hastily, but I believe it’s mostly complete. I’ve also downloaded thumbnail versions of some of the public photos hosted on App.net.

I’ll be making the posts available somewhere, although I don’t know exactly what form the archive should take yet. I’ll also be considering whether to integrate it with Micro.blog, for anyone who wants to migrate to a new microblog and didn’t have time to manually export their posts. (I’ve already built a similar feature to import from Twitter’s .zip archives.)

To my Kickstarter backers, thanks for your patience as I took an unexpected detour this week. Major work on Micro.blog continues. I have a big announcement for next week and invites should be ready the following week. I’ll post an update to Kickstarter soon.

App.net is shutting down

Dalton Caldwell and Bryan Berg announced the official shutdown of App.net today:

In May of 2014, App.net entered maintenance mode. At that time we made the difficult decision to put App.net into autopilot mode in an effort to preserve funds and to give it ample time to bake. Since then every dollar App.net has charged has gone towards paying for the hosting and services needed to keep the site running. Unfortunately, revenue has consistently diminished over the past 2+ years, and we have been unable to return the service to active development.

As I wrote about just last week, the founders of App.net deserve our thanks for trying something very difficult and succeeding beyond what anyone expected. I’m still amazed at everything they were able to do.

So, what now? I believe the next step for the open web and Twitter-like services is indie microblogging.

Thank you to App.net

Even before announcing Micro.blog, I’d get asked about App.net. It may surprise you to hear that there’s still a community there, 2 years after the service was put into maintenance mode. All my microblog posts are cross-posted automatically, and I’m always happily surprised to continue to get replies on App.net.

I was an early believer in App.net. I wrote in 2013 that it was not just a Twitter clone but an amplifier for applications that couldn’t be built before. It came along at the right time, took off, and then faded. The App.net founders deserve significant credit and thanks for trying something risky and succeeding to grow a community that lasted so long.

Now, with social networks broken in ways we didn’t fully acknowledge before, the time is right for another shot at a more open, ad-free microblogging platform. That’s why I’ve been working on Micro.blog.

I could use your help to spread the idea of independent microblogging. We don’t need just another Twitter or Facebook clone. We need a new platform that encourages blogging on the open web. You can learn more on Kickstarter here.

Here’s a Twitter feed

Whenever someone says “I don’t read RSS”, I actually hear “I don’t read Manton’s blog”. I could give plenty of reasons why they’re missing out by ignoring RSS — it’s still the best way to keep up with bloggers you like who aren’t linked or retweeted often enough to bubble up on Twitter — but some people won’t be convinced.

Over three years ago I stopped posting to Twitter. I know it was the right move on principle because there was a real cost in exposure, with fewer people actively keeping up with what I’ve been working on. As I’ve said before: it wouldn’t mean anything if it didn’t cost me anything.

And yet, many people get their news from Twitter. Since I started microblogging on my own site, I’ve had time to reflect on the role of indie microblogging and cross-posting. I think the IndieWebCamp has it right: publish on your own site, syndicate elsewhere. I wrote more back in July about cross-posting.

Most importantly, as I work on a microblog publishing platform of my own, how can I develop a solid cross-posting feature if I don’t actively use it myself? I’ve recommended IFTTT to beta testers, but only by using it myself can I know where the gaps in functionality are.

So I’ve been experimenting. All of my posts now go out to the Twitter account @manton2. This was an account I created 6 years ago for testing. Except for a few of the first tweets, I’ve cleared out the test content and given it a new life.

It’s worth noting some advantages and disadvantages to this:

  • I can write at my domain name and own my content, but have it automatically sent to Twitter for folks who are there. Unlike how I’ve been treating these cross-posts to App.net, I’m not sure whether I will stay engaged and answer replies on Twitter. We’ll see.
  • Most of my microblog posts are around 200 characters. These will get truncated on Twitter, with a link back to my site. Full essays get a nicer title and link. I’ll continue to improve this.
  • I’m effectively starting over with zero followers, compared to the 5000 followers I left @manton with. I have no plans to resume using my original account, though. Think of the “2” in @manton2 as a reminder that this is a mirror of my posts, and an imperfect one.

You can follow @manton2 on Twitter. Thanks for reading.

Riposte push server crowdfunding

Back in April, the App.net app Riposte was removed from sale. Riposte wasn’t just the best client for App.net; I think it held its own against even the best Twitter apps, too. The push notification server for Riposte (and its messaging app complement, Whisper) was to keep running for some months and then shut down this summer.

Even if App.net is slowly fading away, like many users I still have Riposte on my home screen. I cross-post all my microblog posts from this blog to App.net. When I get replies and mentions on App.net, I like to see them as push notifications in Riposte. I can reply in the app easily, or skim through the timeline to see what else is going on.

Now the developers have launched a crowdfunding campaign to keep the Riposte server running. Their goal is a modest $500 per year to cover AWS hosting and time to keep everything running smoothly. Even if you’re not very active on App.net anymore, consider donating as a thank-you for everything Riposte did for App.net, and for what it did to advance the state of UI design in social networking apps.

Retiring App.net support for Sunlit

Sunlit 1.3.1 shipped today. It’s a minor update focused on fixing bugs, but it is also the first version to remove App.net support. Existing users still have access to all the App.net features — the code still exists in the app for now — but the App.net sign-in button and settings have been removed for new users to simplify the requirements and UI.

It was difficult to let go of the App.net-specific features. A significant amount of the codebase was around syncing and collaboration features via App.net. There was also some great location check-in support built on App.net locations and compatibility with Ohai. I had to remove screenshots and prune down the App Store description to account for the removed features.

What’s left is an app that has fewer features but which feels light and simple again. Maybe this should have been our 1.0 version all along.

Two years ago, I wrote about waiting for App.net’s killer app:

“The promise of App.net is bigger than one type of app. App.net isn’t just a blank slate; it’s an amplifier. It’s waiting to power the next new idea and help it grow into something big.”

This vision didn’t pan out. But I’m proud that we gave it a shot and put a lot of effort into the platform even after others had given up on it. Now that we’ve finished this “reset”, of sorts, we’ll move forward to build other features we always wanted in Sunlit.

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.

Goodbye Riposte

Jared Sinclair announces that Riposte will no longer be available:

“As part of an agreement reached over an alleged trademark infringement, Riposte (the App.net app I made with Jamin Guy) will be removed from sale on the App Store. We’ll also be taking down the riposteapp.net homepage.”

Even today, Riposte is arguably the best social networking client out there. It pioneered consistent gestures for navigation. It will remain on my home screen for some time to come.

Preservation State and App Stories

I was the guest on 2 podcasts recently. First, on Preservation State with Philip Mozolak and Christopher Radliff, we talked for an hour about App.net, Beats Music, and more. It was fun to do a longer podcast that’s free to kind of meander through different topics, and I think we covered a lot.

Next, on App Stories, Vic Hudson interviewed me about how Sunlit came to be. We talk about App.net, design choices in Sunlit, and the future for the app. There’s a lot in there that I’ve never talked about before. Hope you enjoy these episodes!

Frozen in time

Many people have written about App.net this week, but I think my favorite line is from this essay by Pete Burtis, while talking about how the API and apps are years ahead of other platforms:

“If App.net is to be frozen in time, at least it’s to be frozen in the future.”

Sunlit 1.2

Sunlit version 1.2 is now available in the App Store. It includes a few minor improvements and one major change: you can now use the app with only a Flickr account. It no longer requires App.net.

We hope this will allow more people to try the app. At any time, you can always add your App.net account to the app’s settings and it will unlock the more advanced features: syncing, sharing stories to other App.net users, and multi-user collaboration so that anyone can add photos and edit text in a story.

Making App.net optional instead of required meant rethinking what the minimum features were that all users should have. Obviously you have to be able to create stories, add photos, include text descriptions, and use filters. But we also kept coming back to one thing: we could not ship without also supporting web publishing. The bulk of work on Sunlit 1.2 was creating a parallel implementation for publishing that would seamlessly work with exactly the same UI, with or without App.net.

Some people may ask why we chose Flickr instead of creating our own user accounts system, or simply having no registration. To support publishing, it helps to have some unique username for a user, and a secure way to authenticate them on the server. It won’t surprise anyone to hear that a lot of people have Yahoo accounts. With a redesigned web and mobile experience, plus 1 TB of free photo storage, Yahoo’s giving Flickr something of a new resurgence. There’s a lot we could build on the Flickr API.

At the same time, Sunlit’s App.net support is a powerful differentiator and we’ll continue to improve it. It lets you own your data, share it with other apps like Ohai, and sync to multiple users. I still believe in the App.net API and user community; it’s too good a platform to give up on.

The risk of a small platform

Marco Arment responds to my comment that developers should have seen the potential of the App.net API as something much bigger than Twitter. I wanted my post to be short, but Marco makes good points that are worth following up on. He writes:

“Building an app on someone else’s API, rather than making your own, is a huge risk: it usually only pays off if the service provides a huge existing userbase and hard-to-duplicate functionality. App.net never offered either. They started out facing the typical social-network chicken-and-egg problem, put a huge paywall in front to prevent any growth, and tried to alleviate that by adding more chicken-and-egg problems to their offerings.”

Building entirely on App.net for Sunlit was indeed a huge risk, and one that we expected would take time to pay off. It was a bet on the future. We are incredibly proud of our app and the response it got in the App.net community, but our goal was always to make an app that appealed to everyone, not just a small niche of tech folks. We’ve actually been working for over a month on a new version of Sunlit that expands the reach of the app beyond App.net, and coincidentally it just went into review at Apple this week.

But I think the chicken-and-egg problem was solvable. The main issue with iOS apps is that they couldn’t sign up a new user directly in the app. This made sense when App.net was a paid-only service, because you’d run into in-app purchase issues with Apple, but it became more technically feasible when the free tier launched.

The App.net founders also seemed receptive to the idea. There just wasn’t time to make it happen. I believe this single roadblock prevented any potentially-mainstream killer apps built on App.net from getting off the ground. If it’s not easy to open a third-party app, create an account, and start using the service, too many people will give up. (Our numbers showed that only 40% of Sunlit downloads actually signed in to use the app for real.)

However, building our own backend for the app would also be very challenging and expensive. We are not syncing small bits of data around. It’s a photo sharing app, so right off the bat you’ve got big files that have to be hosted somewhere. On top of that there’s collaboration features, so you need not just user accounts but private sync channels that have specific read/write access to certain users. Plus all the metadata and formats to support syncing text, photos, and location check-in information. Not to mention publishing HTML, thumbnails, and maps. It’s daunting.

(In fact, it’s so daunting, I don’t think there’s a single app in the App Store that has feature-parity with Sunlit. The app simply could not have been built by a tiny team of 2 part-time developers if building a whole backend infrastructure first was a prerequisite.)

Marco closes with this:

“As much as App.net wanted to be — and eventually was — much more than a Twitter clone, it got the vast majority of its initial funding, enthusiasm, and developer support from people’s anger at Twitter’s dickification. But internet outrage doesn’t last long. Since App.net never became the new primary place where our friends all hung out, most of us never left Twitter — we all just accept that they’re dicks now, and we forgot about App.net.”

There’s an argument to be made that App.net’s core mistake was building the Alpha web interface only far enough to match Twitter’s features and then moving on to other things. Instead, they could have kept improving Alpha until it was significantly better than Twitter, so good that it couldn’t be ignored. By doing so, maybe they would have also more effectively demonstrated the power of the API underneath.

I assume that App.net chose not to do this so they wouldn’t compete with developers. After all, the service was founded on the idea that developers should be respected and given every opportunity to succeed. Finding the right balance to showcase the platform with first-party apps without stepping on developers is not always easy. We can argue about which missteps were the most costly, but the founders never wavered on their original principles and they promoted every app that launched on the platform. That means something.

As for outrage not lasting long on the internet, Marco’s totally right. I just don’t forget that easily.

App.net niche

Justin Williams covers several aspects of this week’s App.net news, comparing it to his own Glassboard service. On finding a profitable niche:

“Finding an audience of people interested in your platform is challenging. This isn’t Field of Dreams where if you build it people will magically appear. Once you find that niche of users, you’ve got to ensure they’re also the type of folks that are willing to pay to support your platform. If they aren’t, you keep looking for a niche that will sustain your product.”

He also hits on the main thing that was probably holding App.net back: the stigma that it was just a Twitter clone. I’m more than a little disappointed that fellow developers didn’t get the power of the App.net API. Does Sunlit look like a Twitter app? Give me a break. App.net is hands down the best API of its kind.

So now we figure out what’s next. In the short term, not much changes. Tomorrow I’ll read my App.net timeline, make a few posts, reply and star as usual. Next week I’ll do the same. At WWDC I’ll use App.net messaging apps to coordinate meeting up with friends.

There’s no shame in shooting for the stars and missing. I’m thankful that even as the founders tried a few things outside micro-blogging over the last year, they never compromised on their original mission for the service. They never sold out users or developers, and the servers hum along in testament to that fact, as if nothing that’s good will ever really change.

Would I go back to Twitter?

Before some of the recent discussion about the future of App.net, Colin Pekruhn asked a question, directed at Ben Brooks and me, about whether we’d go back to Twitter if App.net failed. My answer (and his) was a very clear “no”. Here’s what I said:

“I’m very stubborn and not going to reverse my decision on Twitter. If ADN fails I’ll blog more.”

The stubbornness deserves a little more explanation. Because programmers are pretty opinionated folks. When we feel strongly about an approach — to languages, to UI design, to backend architectures, anything — we’ll plant our feet in the ground and argue with coworkers about the right way to do things. And it’s easy to dig in, start coming up with more justifications for a choice before taking a second look and seeing if it’s actually the right thing, or whether we’re just fighting for something because we want to get our way.

I put a lot of thought into no longer posting to Twitter. I often bring up my low Twitter user ID (#897) because I think it helps underscore that I’ve been on the service a long time. I get the history of it. I was there when it was all done over SMS with my dumb Nokia phone. I had fun with early experiments on the platform, like my sadly abandoned @story140 account, my @wii codes service, the Tweet Marker API, and of course the two products I continue to support to this day: Tweet Library and Watermark.

I stopped posting because at some point the anti-developer attitude at Twitter became too much. The limits on user auth tokens, which have already killed a few popular third-party Twitter apps; the problems with shutting down IFTTT recipes; the guidelines that restricted how you could use your own tweets. This is all fairly well documented and I’ve written about it before. I leave my personal account silent as a small protest.

I knew leaving would be difficult, so I set up a series of posts to discourage my future self from ever joining again. My final tweets were timed to go out on the anniversary of Steve Jobs’s death. They’re a collected moment, a tribute to both Steve and how great Twitter could be. I like that they’re forever pinned at the top of my profile page.

The best programmers aren’t so proud that they won’t admit when they’re wrong. There’s a time to fight for what you believe in — your coworkers don’t agree with how you want to build that feature, but maybe they just don’t see it clearly yet — and there is a time to admit you made the wrong call and move on. Saying “I was wrong, let’s do it your way” is a powerful statement and moves a project forward. I never want to ignore Twitter just because I’m so stubborn I refuse to admit I overreacted and that it’s time to crawl back to Twitter and accept defeat.

But here’s the thing: I wasn’t wrong. Every reason I gave above for leaving Twitter is still valid. I have friends at Twitter doing great work — it’s truly incredible what they’ve built, from scaling the backend to how the iOS app works — but Twitter is too big and successful to change now. We can’t rewind the clock to when Twitter was a tiny company that cared more about developers than advertisers, so I won’t be back.

Snippets

Right after publishing yesterday’s post on mirroring content, I added a link to IndieWebCamp’s POSSE, a project from Tantek Çelik to provide a framework for mirroring posts to different services. It looks like that group is doing great work to identify microformats that will make this a more open standard.

Noah Read also rolled his own solution for writing posts on his site first and then letting them flow to Twitter, App.net, Flickr, and other services. He calls them Snippets:

“Microblogging and social sharing will survive, whether or not the current players do. So I wanted to take control of the things I publish on these networks, without abandoning the great things only they can provide, the conversations and reactions to what is shared. So Snippets are the way I will post to these services from now on.”

Check out Noah’s snippets feed. I especially like the name. As a programmer I’m used to thinking “code snippet” when I hear it, but with enough use it’d be easy to reclaim its normal non-code definition.

Firesid.es chat with Bill Kunz

Yesterday Bill Kunz was interviewed on Firesides, talking about his app Felix, and life as an indie developer vs. at a startup. Bill was especially open about how he used his own savings to build Felix, and some of the planning problems he ran into:

“One thing I would do differently – and this is probably going to come out wrong – but I would have stuck to my guns on my own plans better. I added quite a few niche features that ultimately ended up not being used, when I could have spent that time on the core of the app, or other projects. I burned a lot, lot, lot of time on things I ultimately didn’t need to.”

Firesides is a very nice use of App.net. You can browse chat transcripts from previous guests without signing in, or sign in with App.net to ask questions when there’s a chat taking place. It’s a little like Reddit’s Ask Me Anything, but more readable and visually appealing, and built on the App.net messaging platform.

Sunlit sync and publishing

It was Macworld Expo in 1997, and Steve Jobs had just come back to Apple. Somehow I was lucky enough to get a seat in the keynote, and I sat there with a big grin on my face as Steve came out to talk about NeXTSTEP, which would eventually become the foundation for Mac OS X. He likened developing an app to constructing a building, one level at a time. A good OS allowed you to build higher.

Microsoft’s DOS gave you very little, so you had to start at the ground floor. Developing for the Mac and Windows was like starting out on a 5-story building. But the developer tools from NeXT were like starting out on the 20th floor, because they were so advanced, because they “lifted the developer up” and let apps be developed more quickly than if you had to deal with all the basic foundational stuff every app needs.

I think the App.net API is that same kind of advancement for apps compared to most other web APIs. It is significantly more consistent and full-featured than anything else out there.

Sunlit syncs stories and photos with App.net, using your App.net private file storage (for storing photo data) as well as private channels and messages (for syncing story titles, permissions, and other metadata). We like this solution because everyone who signs in to the app with their App.net credentials gets sync automatically. It also means that if you authorize other apps to see your App.net files, you can manage the data Sunlit syncs there, or get it out again without us having to directly build an export feature.

(Although we do offer a number of export choices in Sunlit, such as saving photos to your camera roll, sharing them on social networks, or sending them to any app that supports “Open In”. We do this with OvershareKit.)

Publishing in Sunlit is another feature that utilizes App.net file storage. It allows you to take a story — photos and text — and publish it to a URL. The URL is public, but it’s not linked from anywhere unless you directly share the URL with someone. This makes it convenient for quickly publishing a set of photos and sending the link to family, for example.

Here’s what the published stories currently look like: http://sunlit.io/manton/nationalparks

On the surface this may look like Sunlit is uploading photos and other data to sunlit.io, where it’s probably stored in a relational database or on the server filesystem somewhere. But that’s not how it works at all.

The iPhone app actually uploads all photos to App.net file storage, marks the new files public, then generates a static HTML page and also uploads that to App.net. It then registers the story with sunlit.io, which caches the HTML just to make things a little faster. We never store any photos on sunlit.io itself, instead merely referencing their public URLs on App.net. (View source on the page to see the proof.)

This difference means you can move the site anywhere just by copying files from App.net, with any number of available file management tools. Or just copy the HTML file to your own server to serve the page from your own domain. The CSS and JavaScript is all bundled inline in the HTML, except jQuery, which loads from a URL.

We think this approach makes the whole system a lot more flexible and open. Your data is never hidden inside the app and your published pages are never locked behind a server.

Several months ago I wrote this about App.net:

“The promise of App.net is bigger than one type of app. App.net isn’t just a blank slate; it’s an amplifier. It’s waiting to power the next new idea and help it grow into something big.”

I still believe that. It’s making apps easier to build and more powerful, just like NeXTSTEP was. There’s really no other web platform like it. That’s why we picked it for Sunlit.

No coincidence

We released Sunlit yesterday and the response has been really great. It’s so amazing to see all the replies on App.net, emails of encouragement, and tweets telling people about the app. I think 1.0 is off to an excellent start. We’ll keep making it better.

I was a little anxious about the release, though. It was a challenging app to build, and it’s different enough from other apps that it’s hard to predict how the market will react. I was also surprised that the same morning we shipped our app, Storehouse was released. This is a beautiful iPad app from Mark Kawano and his new team. The interactions are extremely polished and it’s getting justifiably good praise and lengthy write-ups from Techcrunch and elsewhere.

(Of course, we think Sunlit is pretty awesome too. I’ll be writing more about what makes it special in future blog posts, especially highlighting how it leverages the App.net API, the URL schemes support, and why we use Mapbox.)

At first I was stunned by Storehouse. How could it be that we were both working on a similar idea for the last year, and both apps were finished at the same time? The apps have different UIs, and a different approach, maybe even different goals, but they both create stories, revolve around photos, and publish to the web. I’ve seen a lot of people compare the apps, and I think that’s fair.

To be honest, for a few minutes I was a little bummed out. If I had seen this tweet from Jackson Harper at the time, and not later in the day, I might have been nodding in agreement:

“Having a somewhat similar free app from a funded developer launch the same day as you must be a little disappointing.”

That doesn’t really capture it, though, because I’m also really happy for the Storehouse team. I’ve known Mark for years. I’m confident that his app is going to be one of the most impressive apps on so many people’s iPads.

And they have a full-time team. Jon and I are just two guys, working in our spare time to build something — something we think is new, something for us to use, but also something ambitious in how big it could be.

It seems like a big coincidence that both apps shipped with a similar set of features, but now I realize why it happened. Sure, it’s funny that the release days were identical, and not a few days or weeks apart. But the general timing shouldn’t be at all surprising, because this is an idea whose time has come. There are photo “album”-type apps popping up all over the App Store, such as Cluster, Albumatic, and Heyday, all of which Apple has featured. Plus there are web-based apps like Exposure and Medium, which was recently updated with great photo support as well.

It’s no coincidence; it’s just a good idea. And it’s a huge market: everyone who loves writing and taking photos. That understanding gives me a lot of confidence to double down on our plans for Sunlit 1.1, 1.2, and after. 2014 is going to be an awesome year for sharing stories.

Why we built Sunlit

Montreal

You have that feeling when hanging out with friends — everyone snapping pictures of their surroundings, of people, events, food, anything — that photo sharing should be better. That years later, you should be able to go back to that time, to see the best photos collected together from several people. And not just photos, but maps of where you were, and text to describe its significance.

One afternoon before Çingleton in 2012, this subject came up as Jonathan Hays and I were taking photos around Montreal. It seemed remarkable and disappointing to us that there was no easy way to put those photos together. And I liked the idea of buildling a new app around photos, with the same themes of curation and preserving past events that are so important to my other Riverfold products.

So we let the idea sit in the back of our minds, and later we wrote a little code as time allowed. At the App.net hackathon before WWDC 2013 we dove into the project in earnest, figuring out how it would sync, then over the summer took some more time to think through the user experience.

Sharing a single photo has been done a hundred times on iOS. Instagram was an important app to nail the timeline UI, and Favd is currently my favorite way to post and browse new photos (it’s really great). But hardly anyone has even attempted to tackle photo curation, group sharing, and publishing, let alone gotten it right. Sunlit 1.0 is our first pass at this and we couldn’t be more excited about trying to solve a new problem with photos.

They say you should spend money on experiences — on memories, not things. Sunlit helps you put those memories together, share them as a group, and rediscover them when it matters. The first version will ship tomorrow. I hope you like it.

New tiers for Watermark

My account in Watermark right now has 805,182 searchable tweets stored in it — tweets from everyone in my timeline, App.net posts, favorites, and of course my own tweets. When I launched the service, I wasn’t sure how long I’d be able to keep storing these. I initially promised 1-2 months, then upped it to 3 months, and then 6.

Today I’m happy to announce that I have a more formal system in place for storage. The default $4/month plan will officially increase to 1 full year, storing every tweet from anyone in your timeline starting when you sign up. Your own tweets and favorites are kept forever.

If 1 year isn’t long enough, there’s a new unlimited plan for $10/month. Every tweet or App.net post in the system for your account will be kept forever. After a year or two it becomes a really massive and interesting search database, tailored just to your account.

The new tiered plans are live now for new accounts, and I’ll be rolling out a method for switching between plans for current customers soon. You can learn more about Watermark here.