I think I caught an A/B test earlier this evening. Has anyone else seen this? Interesting re-do of the Twitter aesthetic.
Multiple sources tell the Post-Dispatch that Brett Hull will rejoin the #stlblues as a vice president with the organization.
— Jeremy Rutherford (@jprutherford) September 6, 2013
I was going to make some kind of awesome quip about how this was going to be really hard because Hull’s Twitter account is either done 90% of the time while completely stoned, or some kind of weird performance art, but the account is gone from Twitter. (Really; I was going to include some prime example Tweets. There were a lot of them.)
Example of the kind of chatter this is provoking:
@Proteautype @2ndBestHull does this mean he no longer likes boobs?
— Andrew Saunders (@ASaunders87) September 6, 2013
We’ll miss you, @2ndBestHull.
Twitter published the overview of version 1.1 of the API yesterday. Lots of space and many words have been devoted to why their changes are hostile to developers of Twitter-based applications (and they certainly are). For background on the changes and how they affect developers, the best opinion posts I have seen are this one by Daniel Jalkut on the OAuth token restrictions, and this one from Ben Brooks on what the changes indicate about Twitter on a corporate level.
I think what’s been overlooked in all this is how some of the changes—maybe the most influential and important ones—are actively hostile towards users of the service. They place burden and unnecessary restriction on the very users that Twitter is looking to court and retain to turn the wheels of their business model.
I’ll preface this by saying that I am very much a layman, so my understanding here may be flawed. If you can correct me and convince me that it’s really not all that bad, please leave me a comment and let me know.
Abandoning Open and Accessible Standards
Once upon a time, Twitter supported the use of RSS as a method for grabbing information from your timeline and even updates from one or more users. In fact, when I first started using Twitter myself and third-party clients didn’t exist yet, RSS was how I consumed timeline information.
For some time now, RSS has been pretty well hidden, but you could still access it and use it if you wanted to even though it was unsupported.
We’ve chosen to throw our support behind the JSON format shared across the platform. Consequently, we’ve decided to discontinue support for XML, Atom, and RSS, which are infrequently used today.
This is a page out of Facebook’s strategy, where I would love to be able to grab RSS feeds or groups and friends who basically use it for blogging, but I can’t—or at least I can’t figure out how. JSON is still a standard and it’s still open, but your data is getting less and less accessible all the time.
In version 1.1, we’re requiring applications to authenticate all of their requests with OAuth 1.0a. Not only will this visibility allow us to prevent abusive behavior, but it will also help us to further understand how categories of applications are using the API. We’ll apply that understanding to better meet the needs of developers as we continue to evolve the platform.
Let’s be clear; by “further understand” they mean “tightly control.”
On Twitter, your updates are “public,” but they are “public” only insofar as Twitter wants you to be able to display them. By curtailing methods of pulling data that can be used without authentication, and controlling tightly who can and cannot authenticate to the service and how many times, it allows Twitter to eventually trap your data.
I believe that even with these changes, public timeline data can be queried without authentication via JSON, but JSON tends to be less end-user-accessible than at least Atom and RSS. I can still access my timeline RSS now, but I will assume that this will change when Twitter deprecates API 1.0.
This is what a lot of the hubbub has been about from a developer standpoint, and to be fair, developers do end up with it being their problem. But users are the eventual target of this restriction.
All applications replicating the core Twitter experience, usually called “clients”, will have some new restrictions placed on them, including a 100,000 user token limit.
So when an application has hit its limit, how is that supposed to be communicated to the user who requests token 100,001?
- Wait until your token counter hits a certain limit pre-100k, then pull your app from distribution (thus alienating users who want to evangelize your app to friends and others who want to try it)?
- Display an error message to users 100,001 and beyond (who will probably blame you anyway and not use your app even if you get more tokens)?
- Furiously blame Twitter for the limit in either a status message or page on your app’s website (potentially confusing users even more)?
The point I am trying to make here is that even though the developer is the one who is hamstrung by the token limit, the users of the app are the ones who face the messaging and confusion. The users are the people who are told that their choice to use a client that isn’t the core Twitter experience is the wrong choice and isn’t permitted.
I am sure this is intentional on Twitter’s part as a nudge to get as many users as possible to use the “official” clients. (Which, let’s remember, started as third-party apps in most cases.) But from the users’ standpoint, something will just appear to be broken. Whether the user decides to blame the developer of the client in question or the Twitter service as a whole, it’s limiting choice—and worse than that, it’s limiting choice in a way that wasn’t limited previously.
A lot of users probably won’t care or notice, and I seem to recall seeing stats recently that indicate that the number of Twitter users who consume the information on Twitter via non-official clients is actually quite small. But for those savvy enough, it’s going to be annoying.
In the end, I think it’s the wrong move for Twitter, and it’s the wrong move for Twitter’s users. Personally, I am using Twitter less and less as the crazy around it increases. And I’m pretty sure I won’t be the only one.
One way to protect yourself is by declining to delegate authentication to third parties. When enrolling in a new service that offers Twitter or Facebook authentication, I usually go through the nuisance of creating a new account instead. That way I can choose a unique passphrase, and store that in my keychain. I prefer this to allowing numerous items to be implicitly added to my Twitter or Facebook “keychain.” Don’t put all your eggs in one basket, as they say. (Well, that’s what I’m doing with my keychain, but I am empowered to personally protect it and to back it up as I see fit.)
This is a strong argument against permitting multiple login “vectors” from social services to your web service. It’s a good idea to permit connecting to these services so your service can leverage things like contacts and posting access but a bad idea to permit authentication from these services.
And you should never use the same password twice across services. The last.fm/LinkedIn password craziness should have taught everyone that.
There’s lots of talk going on early this week about Twitter and their intentions towards third-party clients. Will they permit them? Will Tweetbot still be around in six months? How am I going to connect with other people if Twitter goes the Facebook route and makes me use official clients that aren’t as nice as the third-party ones I have now?
I was going to write a bunch of words about this, but in the end it comes down to something very simple.
Your blog has always loved you. Open—or at least agreed-upon and widely used—standards are not going to magically grow walls and keep you or others out.
WordPress. RSS. Comments. Pingbacks.
Digging deeper: PHP. MySQL. Apache/Nginx. Linux.
These things don’t belong to someone else. They don’t belong to a company that needs to please its investors. They don’t have reasons to keep you out or to stop you from doing what you want.
They belong to you. You use them to make great things. You contribute to them and make not only your stuff, but other people’s stuff, better. You use them to read others’ content and to enter the discussion. If your blog hasn’t been the center of your digital presence, why not?
Your blog has always loved you.
rStat.us is an OStatus-based microblogging service built by Steve Klabnik and others using Ruby, Sinatra and MongoDB. Because it uses OStatus, it’s compatible with Identi.ca and StatusNet microblogs. In order to follow someone from Identi.ca, just paste the ATOM feed from their profile into rStat.us. Theoretically this should work both ways, but I was unable to subscribe to my own rStat.us account from Identi.ca account.
Yeah, good luck with that.
WordPress and other publishing platforms work well decentralized specifically because they don’t require a single locus to function with each other. There are pingbacks and comments—and if you want to follow another site you generally do it with RSS. It’s the language of publishing platforms. You can do neat stuff with a single locus (like the social features on WordPress.com), but it’s not necessary for the ecosystem to function.
Social services like Twitter and Facebook are popular because they focus people’s attention in the same area. It’s a single place where people can find their friends and people they want to Internet-stalk, and that makes it easy to connect.
Pasting an Atom feed? It’s not going to work because that’s not the language of social services. You’ve already made it too hard.
There’s been so much discussion on Color that there are even posts talking about how much discussion there has been. Regardless of this, I am going to tell you what I think of it and why I think it’s a poor concept and why it won’t fly—at least with me. I’d love to be proven wrong (and I think Sequoia would love for me to be proven wrong as well, with a pre-launch $41 million round that’s the talk of the town), but let’s roll with this.