New APIs to power customer engagement in Direct Messages • Hacker News Board

Re: New APIs to power customer engagement in Direct Messages

#51

Post by [deleted] » Thu, Apr 06, 2017, 5:54 PM UTC

saurik wrote: post #45

electic wrote: post #23

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities. Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themse…

Twitter also did something that I find particularly interesting: they somehow convinced developers that you needed them to bless your app and provide APIs to build a client that accesses their service, even though those credentials must be distributed to the public with your client . To people like me who are old enough to have dealt with AOL, the idea that developers are willing to buy into this fiction is absolutel…

[deleted]

Re: New APIs to power customer engagement in Direct Messages

#52

Post by woliveirajr » Thu, Apr 06, 2017, 5:54 PM UTC

It would be a good thing if, with this announcement, Twitter made a commitment for how this would have a support for the future.

Like "this will be available for x months/years, you can make x requests per minute/hour/day, you can buy a plan offering x for $x dollars" and so on.

Yes, that can limit some better offer in the future? Perhaps. But that make things more stable, and people would commit more to twitter.

Can you change your terms in the future? Of course. But for newer customers. The ones that sign up right now will have that promises kept. Good for everybody.

Re: New APIs to power customer engagement in Direct Messages

#53

Post by [deleted] » Thu, Apr 06, 2017, 5:59 PM UTC

sksksk wrote: post #46

electic wrote: post #23

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities. Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themse…

@replies and hashtags (one of the most successful features of twitter) came from third party apps,

[deleted]

Re: New APIs to power customer engagement in Direct Messages

#54

Post by zimmund » Thu, Apr 06, 2017, 6:03 PM UTC

andypiper wrote: post #40

protomyth wrote: post #35

Earlier quoted context omitted.

You still cannot release a twitter client that doesn't get maxed at 100,000 users. Why bother implementing ideas when it will probably meet with the same problem due to our success.

Well, the platform is not just about client apps, people use Twitter's data and features for all kinds of things. You're welcome to build on the platform if you've got a good idea.

Building a useful client is a way to build on the platform. It's giving the users an alternative to use your platform...

Twitter is so afraid of losing their users that it's becoming a self-fulfilling prophecy.

Re: New APIs to power customer engagement in Direct Messages

#55

Post by chairmanwow » Thu, Apr 06, 2017, 6:06 PM UTC

electic wrote: post #23

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities. Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themse…

I have heard rumblings about this from a few old salty dogs, but I never heard such a detailed explanation of what actually happened with Twitter + developers.

While this API does seem exciting, I'm way more hesitant to create anything given the company's history.

Re: New APIs to power customer engagement in Direct Messages

#56

Post by mschuster91 » Thu, Apr 06, 2017, 6:39 PM UTC

saurik wrote: post #45

electic wrote: post #23

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities. Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themse…

Twitter also did something that I find particularly interesting: they somehow convinced developers that you needed them to bless your app and provide APIs to build a client that accesses their service, even though those credentials must be distributed to the public with your client . To people like me who are old enough to have dealt with AOL, the idea that developers are willing to buy into this fiction is absolutel…

> As far as I can tell the only thing that enforces this is what should amount to an antitrust level of collusion between the mega-companies to restrict access to products (via services such as the Apple App Store) that do things that the other mega-companies dislike

Actually, at least in the US you could be having legal problems... you're circumventing access controls, which may or may not be a "hacking crime". Also, by using the Twitter API you consent to its Terms and Conditions, so they have legal grounds to sue you (for example via trademark law; you most likely will advertise that your app supports Twitter login, but then Twitter can sue you as you advertise Twitter compatibility while violating their T&C).

It's IIRC never been tested in court so it remains an effective FUD, even without the Apple/Google store banhammer.

Re: New APIs to power customer engagement in Direct Messages

#57

Post by kh_hk » Thu, Apr 06, 2017, 6:42 PM UTC

Omitting the obvious remarks on Twitter and APIs, this is clearly a good move. Most companies have a twitter handle and the public has already absorbed that fact, so it just seems more natural to offer a bot through twitter DM service than, let's say, telegram. I wonder what took them so long, considering that bots have also been natural to the twitter ecosystem for many years.

This can increase their growth and possibly, if a company bot goes over their future non specified limits, they can cash in. Sorry, could not help myself :)

Re: New APIs to power customer engagement in Direct Messages

#58

Post by pkamb » Thu, Apr 06, 2017, 7:41 PM UTC

andypiper wrote: post #19

cocktailpeanuts wrote: post #7

Who really trusts Twitter at this point for anything developer related? Not just talking about their API. Twitter never knew what they were doing, and that used to be fine, but the difference now is people finally figured out that Twitter doesn't know what they're doing. They keep releasing all these new features that are all over the place (AND worse than before). They should really stop, step back, and think about…

Thanks for the feedback. Can you be specific about the API features that you're referring to that are "all over the place"? I'm personally really excited about this, and this is probably the most cohesive a strategy I've seen for the API platform. We're very focused on fundamentals right now.

Ask via a Twitter Poll, and we'll answer via Tweetbot.

Re: New APIs to power customer engagement in Direct Messages

#59

Post by rhizome » Thu, Apr 06, 2017, 7:51 PM UTC

saurik wrote: post #45

electic wrote: post #23

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities. Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themse…

Twitter also did something that I find particularly interesting: they somehow convinced developers that you needed them to bless your app and provide APIs to build a client that accesses their service, even though those credentials must be distributed to the public with your client . To people like me who are old enough to have dealt with AOL, the idea that developers are willing to buy into this fiction is absolutel…

I wonder if a clean UX could be constructed around users signing up for their own API key and providing that to the client.

Re: New APIs to power customer engagement in Direct Messages

#60

Post by MaulingMonkey » Thu, Apr 06, 2017, 8:01 PM UTC

saurik wrote: post #45

electic wrote: post #23

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities. Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themse…

Twitter also did something that I find particularly interesting: they somehow convinced developers that you needed them to bless your app and provide APIs to build a client that accesses their service, even though those credentials must be distributed to the public with your client . To people like me who are old enough to have dealt with AOL, the idea that developers are willing to buy into this fiction is absolutel…

It's not necessarily that API consumers feel they must be blessed, it's that it's less hassle. And less likely to land them in a courtroom for for violating API terms of service. "Stealing" someone else's API key sounds like a great way to prove intent to do so - not good!

Baked-in client keys still have some non-security uses: The ability to control rate limiting and help trace bugs/performance issues back to their original "well behaved" clients. It also adds some minor friction for badly behaved ones (more so if everyone's obfuscating it in their clients.) EDIT: Some API docs request that you self-report about your client in e.g. your User-Agent string for similar reasons, when no "blessing" is desired.

Server-side keys don't actually magically solve any problems anyways. You're just shifting the problem from "how does Twitter prevent API abuse by unauthorized clients" to "how do I prevent API abuse by unauthorized clients". You may be in a better position to solve that problem post-shift (e.g. "I'm okay with unofficial clients - but authorized user must individually auth against their paid account!) but you might not ("I just wrote my own twitter client - I'm in no better position to prevent API abuse than twitter.")

> That said, it isn't 100% clear to me that if someone released a true Twitter client Apple would remove it

The way I see it working is Twitter's lawyers sue the author of the unauthorized user of their APIs for intentional ToS violations & circumventing protections (where all those wonderful anti-hacking laws come into play) when they ignore the cease and desist - and either nip the problem at the source when they show up to court, or get a default judgement and a court order they can deliver to Apple.

It's a meatspace solution instead of a digital one, but it works.