Twitter's DM Third-Party Client Issues

Avatar

Share

 • 

2 years ago

 • 

View on Twitter

Everyone wants a standalone Twitter DM app, so why is nobody building one? A breakdown of the problem, all possible workarounds, and what I consider to be the optimal solution 👇

Twitter has an API and endpoints for retrieving & sending direct messages. However, the API only provides access to the last 30 days of DM history. No app (except Twitter's apps) can access messages (or entire chats) sent more than 30 days ago.

So, what if you absolutely need to support DMs? The "intended" method is just accepting the limitation and providing a client that can only read the last 30 days of messages. This is, for example, how @tweetbot implements DMs.

Now, @tweetbot follows the intended route, but with a caveat. They cache retrieved and sent messages so that you don't lose them after 30 days. This makes a decent client, but are there any better solutions?

We could just make a better UI on top of Twitter's existing UI. This is what @thekitze did with twizzle.app! You get access to all messages, but there's little value to add (notifications won't distract you when you go check your DMs, but you still can't fix search)

There's also the reverse-engineering path. Have the user log in with Twitter on a controller browser, then grab the cookies and use the same APIs the Twitter Web App uses. This is how texts.com (by @KishanBagaria) works.

This is a pretty good option in general (if you ignore probably going against Twitter's terms), but the issue is bringing it to mobile. It's relatively easy to create a window where the user can log in to Twitter and later grab their credentials in Electron, not as much native.

Honorable mention: if your issue is getting distracted with Twitter notifications while checking DMs, you could use a VPN to block all of Twitter's API endpoints except the ones related to DMs. This is similar to how @withopal operates (though they block the whole thing)

Finally, how here's how I'd implement it: If I had to build this, I'd take an approach very similar to @tweetbot's (using the official API and storing all the messages we do have access to), but I'd also have users export their account data and upload all of their previous DMs.

This way, you are using official APIs (and hopefully won't get shut down) and also have access to all historical data. Plus, having your own database, you're better off implementing better search and other niceties.