One feature I really like a lot are the bookmarks inside of Superious. You can manually bookmark posts, but you can also let Superious "auto bookmark" posts you comment on or liked (both settings are available in the bookmarks options).

If you found an interesting post and you commented on or liked it, the post will be out of your view soon, so you may not see reactions on the post. Not when you are using the Superious bookmarks! The background synchronization service will check your bookmarks for changes, too, and will notify you if something new was detected.

If you tell Superious your delicious account (again: in the bookmark options) you can even have them outside of Superious: Any post being bookmarked (no matter if liked, commented or manually bookmarked) will be put on your delicious account conserving the tags found.

If you filter your delicious bookmarks with the tag "superious" you'll see a list like that:

This screen is an example from my delicious bookmarks. You'll notice, that all bookmarks added by Superious do have the posts tags, the tag "superious" and the hostname of the Space, so you can filter all links by Space, too.

You can even order Superious to auto remove delicious links, when you remove a post from your bookmarks (you guessed it already: in the bookmark options).

So Superious bookmarks hold "important" posts. Posts you reacted on or manually marked as important. All of them are synched to delicious, if you like, so you can handle them later on your desktop computer.

Delicious is also some kind of backup for Superious. If you lost all your bookmarks you can fill your Superious bookmark list again with all links found on your delicious account having post.ly links. If I have to reinstall Superious, I am able to restore my bookmarks in this way i.e.

This post is for users interested in some internal technical details of the Posterous API. Perhaps you are coding your own application relying on Posterous? Than this info is for you. You are a Superious user interested in technical stuff simply? Then this is for you, too.

Well..

Posterous implemented a rate limit for their API some month ago. It is implemented this way, that your application is allowed to call the API once in a second only. IMHO this is a bad design in it self, because you have to implement forced pauses between your API calls, if your application is optimized for speed (what Superious is, of course). How to do it better is shown by twitter: You have an API call contingent. X calls in one hour, after this the calls are limited. I think that the Posterous API servers are that weak that they had to do it like they did.

But the most important question on that topic is: What does Posterous mean with "your application"? How do they divide the API calls coming in for the rate limit calculation? Until today I assumed it would be calculated as: Calls from one IP or perhaps from one login. There is no other way how Posterous could divide it fair-minded.

But it seems Posterous did it in another way. The Posterous API2 allows access via an API token only. This API token is associated to a login (each Posterous login has its own API token). Once there was an API call for fetching the token associated to a login, but Posterous dismissed this call.

When I asked Sachin why they dismissed it and how to get the API token, he told me this:

You should hard code your api token into the app, not the user's. The api token identifies you as a developer.

Well fine, I did it like that. So the API token was meant as an "application key" not a login key. I generated a single API token for Superious and hard coded it into my code. All Superious installations are using the same token for that.

But here is the problem: When I use this token, I get into rate limits although I assured Superious waiting for one second at least between each API call it does. Where does this come from?

My observation is: From the moment on I use my own API token no other Superious installation is using, the API calls never get a rate limited answer and are very fast!

My conclusion: Posterous made a big mistake in how they implemented their API rate limit. They calculated it on API tokens! So any Superious installation calling the API is getting into competition with each other Superious installation! So if more than one Superious installation is doing an API call in the same second, one of them is successful, all others will get an API rate limit response!

This is why I watched API rate limits very often in my log files: Some other Superious installations were calling the API at the same time!

The only solution there is: Each installation must have its separate token (not each application as Sachin told me). But as I said: Posterous abandoned the API call for fetching API tokens, so normally the API gets useless for successful applications: The more installations there are using the same token, the harder it will be to get around this rate limiting.

Normally.. Well.. I found a way to even get around this. But it is a hack not supported officially. The next beta version of Superious will have API tokens per logins not application wide anymore. So your installation is only conflicting with other installations using the same login (what is nearly never the case).

Except from some very small hickups the new (beta) version is working really good again on my device. No(t many) rate limits and everythings feels very fluffy again.

Do you have the same impression? How is the market version performing? As I did the same fix there I hope well? But I'm not using it currently, so I don't really know..

Oh wow! I debugged the reason, what's happening with this not responding API calls the last days:

Each Posterous application has an API token, identifying it at the API. When I use the Superious API token I get a "Rate limit exeeded" no matter how long I pause between the calls. If I use my own token everything works just fine and fast!

So it seems, Posterous is setting the Superious token to "exeeded" sometimes. o_O

I don't want to think about, *why* this is the case,but it's bad in the moment, when I even changed the market version to respect the pause Posterous is demanding.

That means now: Everybody should use their own API token (instead of application tokens as Posterous is suggesting). Of course the tokens are that cryptic that you don't want to enter them as configuration on your device. And as Posterous closed the call for getting the users API token, I have to hack something again.

Oh boy how I hate this stuff! >.<

I did an update to the market version. This update is not the beta version we are testing here, but a fixed version of the old market release 4.09.

It fixes the API limit problems mainly, so that market users can do complete data loading again.

Changelog:

• Posterous introduced an API call limit, making it impossible to fetch some stuff the way Superious was implemented (it was too fast). Superious is respecting this now.
• Shorter timeouts in order to make Superious detect a blocking API faster.

I will do a beta update today, too, with some minor improvements and fixes. Seems to be very stable! :)

Could everybody please have a look at if this version is stable? Click around and test stuff, I think this could be a market version. So this is the official release candidate #1! :)

• Added Popular posts on Posterous. You can switch them off if you like in the presentation settings.
• Assures square but still crisp thumbnails now. Some images had very extreme dimensions resulting in very thin or flat thumbs.
• Bookmarks having comments waiting for moderation did trigger an alert again and again.
• Fixed bug loading 200 posts when 150 was configured.

Download the beta, if you don't have it yet (else Carotine should have informed you about the update already).

As Posterous is dying and its contributors are turning their backs to the once loved service, my subscriptions getting more and more empty. So I'm getting more and more bored and was searching for fresh stuff.

But as searching is not really available on Posterous anymore, I had a look at the posts, Posterous thinks are "popular". You can see them on your desktop webinterface of Posterous, but they are available at the API too.

The popular posts list is some kind of "Reader", but not filled with posts from your subscriptions, but with post other people think are hot. I don't know, how Posterous calculates what's hot and what's not. It seems they are using view counts mainly (what we know are not very meaningful at the moment). But there are some nice posts in it indeed. Most are American of course, but I also found a post of an important German blogger in it for example.

So it may come handy if you are looking for new fresh stuff to subscribe to. As it is very similar to the Reader, it was easy to add the popular posts reader to Superious.

What you will notice first: The newest post in the popular post list is dated 05/11, what says: Posterous is not very busy filing this list anymore or there was no "popular post" for more than a week. Both conclusions would be bad. But well, I liked to explore the posts on Posterous a little more, so there you go. :)

Of course you can switch off the popular posts in the presentation options and define how many posts should be loaded at max to save some memory.

The popular post reader will be added to the next beta version.