1. Protocol Evolution: Unauthenticated REST to OAuth 1.0a HMAC-SHA1

From an engineering standpoint, Twitter API 1.0 was exceptionally permissive. Developers could fetch public user timelines using basic unauthenticated HTTP GET requests (e.g., GET http://api.twitter.com/1/statuses/user_timeline.json?screen_name=jack). API 1.1 completely eradicated unauthenticated access:

• Mandatory Cryptographic Signing: Every single HTTP request—even fetching a public profile or viewing a single tweet—required strict OAuth 1.0a signature calculation. The client had to assemble a normalized "signature base string" comprising the HTTP method, URL, and lexicographically sorted query/POST parameters, subsequently hashing it with the Consumer Secret and Token Secret via HMAC-SHA1.
• Per-Endpoint Rate Limiting: API 1.0 provided a generous global bucket of 350 requests per hour per user. API 1.1 shattered this into granular 15-minute windows (e.g., only 15 requests per 15 minutes for statuses/user_timeline), forcing client developers to build complex in-memory queueing and caching layers to prevent 429 Too Many Requests cascading errors.
• Deprecation of xAuth: Previously, approved desktop clients could use xAuth (exchanging raw username and password for access tokens behind the scenes). API 1.1 deprecated xAuth for third parties, forcing users through clumsy out-of-band PIN-based browser auth loops that broke native application immersion.
• Strict Display Guidelines: Third-party applications were legally prohibited from altering tweet presentation. Displaying a tweet required rendering the exact Twitter birdie icon, timestamp link, and native action buttons (reply, retweet, favorite), stripping developers of UI/UX innovation.

The OAuth 1.0a HMAC-SHA1 Signing Algorithm

Implementing Twitter API 1.1 required client developers to execute a rigid four-stage cryptographic handshake on every HTTP invocation:

1. Parameter Normalization: Collect all query parameters, POST body fields, and oauth_* parameters (including oauth_nonce and oauth_timestamp). Sort them alphabetically by percent-encoded key and value.
2. Signature Base String: Concatenate the uppercase HTTP method (e.g., GET), the normalized base URL, and the URL-encoded parameter string, joined by ampersands (&).
3. Signing Key Derivation: Concatenate the URL-encoded Consumer Secret and Token Secret, separated by an ampersand: consumer_secret + "&" + token_secret.
4. HMAC-SHA1 & Base64 Encoding: Pass the base string and signing key to an HMAC-SHA1 hashing engine, then Base64-encode the raw digest to produce the final oauth_signature header.

2. Desktop Client Architecture: Adobe AIR, Local SQLite Caching & Tweetr

In the early 2010s, desktop clients like Tweetr represented the pinnacle of cross-platform rich client engineering:

• Cross-Platform Desktop Runtimes: Built on Adobe AIR (combining ActionScript 3, WebKit, and native OS windowing hooks), Tweetr allowed developers to write a single codebase that compiled to native installers across Windows, macOS, and Linux.
• Local Embedded SQLite Datastore: To provide instant UI responsiveness and offline reading capabilities during airline flights or spotty Wi-Fi, Tweetr cached all timelines, direct messages, and user avatars in an encrypted local SQLite database. When the user refreshed their feed, the client issued delta queries using Twitter's since_id parameter, fetching only new tweets to conserve bandwidth.
• Multi-Account State Management: Managing multiple accounts required switching OAuth token pairs and maintaining isolated local cache partitions so direct messages and mentions remained strictly segregated.

3. The Notorious 100,000 User Token Cap Anti-Pattern

The most devastating provision of API 1.1 was the user token cap:

• Artificial Growth Ceiling: Any client application that duplicated the core user experience (such as Tweetr, Tweetbot, or Falcon Pro) was allotted a hard limit of 100,000 user tokens. If a developer had already exceeded 100,000 users before the policy date, their cap was frozen at 200% of their existing base.
• The Falcon Pro Hack: When popular Android client Falcon Pro hit its 100k cap, developer Joaquim Vergès ingeniously allowed users to supply their own Twitter Developer API keys, effectively transforming every user into a distinct registered app. Twitter responded by invalidating the application's consumer keys, making it clear that circumvention would not be tolerated.
• Economic Devastation of Indie Devs: Paid native app development requires a continuous stream of new purchasers. Once a client hit 100k tokens, a newly paying customer who downloaded the app from the App Store or Google Play could not even log in, triggering 1-star reviews, chargebacks, and business insolvencies.

4. The Technical Legacy & Rise of the Open Web

The tragic lesson of Twitter API 1.1 was that building a commercial product on a centralized corporate social graph carries existential platform risk. Twitter used independent developers to popularize their network, and then destroyed those same developers to capture 100% of advertising impressions.

This betrayal ignited the modern decentralized social web movement:

• W3C ActivityPub (Mastodon): An open HTTP/JSON-LD protocol allowing independent servers to federate statuses, likes, and follows without centralized corporate gatekeepers.
• AT Protocol (Bluesky): An open federated network separating account identity (DIDs), repository storage (Personal Data Servers), and indexing/search (AppViews). Third-party clients are first-class citizens, incapable of being de-platformed by an arbitrary token cap.