Why don't we all go back to AOL and Geocities. The problem with Twitter is that it is not clear exactly what their approach to their revenue problem might be. I understand they want to monetize their API but does that go hand-in-hand with quashing every potential competitor who happens to use the API with a modicum of success?
I'm bearish about any company that builds a data warehouse on the basis of access and open-ness and then decides to restrict that access at a later date for the sake of profitability. It's just distasteful and speaks volumes.
I wouldn't touch Twitter without a contract signed by my company and by Twitter. Any attempt to utilize their content consumers for anything other than reading content you produce has been shown to be at extreme risk of termination.
I don't believe Twitter doesn't know how they are going to generate revenue. I'm not convinced they can actually implement their ideas, but, if they had no ideas, I think they would be letting other companies throw themselves at the wall, then picking off the ones that stick via acquisitions. That they just squash them implies they think they know what they are doing.
You are right. I'm going through this exact same thing with the reddit api and chrome app store.
A lot of api providers seem to have a few limited (mostly lame) use cases in mind. Developers by their nature are creative boundry pushers. Conflict is inevitable.
I just wish api providers would take greater care in thinking about and describing what exactly is going to be allowed and not. Rather than putting something out there, having developers throw things at the wall, then banning things you don't like after the fact.
> Rather than putting something out there, having developers throw things at the wall, then banning things you don't like after the fact.
I would think that being able to operate that way is exactly the reason you want to offer an API. So that your users can come up with ideas for you. Trying to anticipate up front every conceivable use of an API and publishing it with a huge list of rules based on conjecture makes for a pretty crappy API.
> I'm bearish about any company that builds a data warehouse on the basis of access and open-ness and then decides to restrict that access at a later date for the sake of profitability. It's just distasteful and speaks volumes.
They have changed their terms for third party integration about 2 years ago (somebody correct me) and since then strongly discourage third parties from trying to leverage Twitter for their own profit. Anyone seriously betting on getting away despite the publicly expressed discouragement from 2 years ago is getting what is to be expected.
The player card is designed to handle embedding videos, which is what Ribbon initially showed, however when they launched their new feature they morphed the embedding options to display a custom in-stream purchase button / unit.
In reality, they should have just used a 'product' card (granted, they would not have the added ability to purchase in stream - it would need to link back to their website).
Using the player card was a pretty clever way to get the payments to happen directly on twitter, but it seems that it bent too many of their rules. They'll probably just have to use the product card like everyone else.
Twitter wants to validate each domain that has a card so they can approve & exert control. They cannot control what products a ribbon customer promotes via ribbon. If I wanted to sell illegal drugs or child pornography photographs, those would show up on twitter.com & twitter apps in a nice card-like experience complete with a 'Buy Now' button.
It's likely because it's all wrapped up in Twitter's web interface. To the average user, it looks like you just paid Twitter for something. If you have any sort of problem with shipping or the product itself, you're likely going to go back to where you bought it from: Twitter.
They're simply protecting themselves from a series of problems that would be completely out of Twitter's control to help in any way. Twitter would always come up the loser for any of Ribbon's mistakes. They don't even have a way to punt any support issues over to Ribbon.
Given the earlier fallout with the twitter 3rd-party clients, and similar things going on on other "platforms" I think we need a new name for these services other than "platform" (since it is not stable, it's a bit of a misnomer) but more specific than "service".
I propose "network traps", "progress sinks" or "sucker tub". I don't know but I keep getting a recurring imagery when thinking of these situations as of someone building a house on a raft, which immediately capsizes, but the buoyancy of the house causes the raft to lift out of the water.
Yes because it would be TERRIBLY hard to institue a whitelist for domains that could be issued twitter cards and have an API call to register and either allow or not allow it.
all I really mean by this that if Twitter were not being malicious here they would be able to work with Ribbon and other companies who have similar ideas that could help change the internet for the better.
Curious what happened here: the Twitter Cards Player options clearly require pre-approval by Twitter for custom cards. Did Ribbon present one thing when going through the approval process and then change the player after the release?
The preview doesn't look anything like their final implementation. That preview looks like an actual movie player, while the final card screenshots I've seen look like regular content cards with a lot of custom branding.
This looks like a clever hack of the Twitter implementation of the Player card and not the intended use. The stream and content type attributes both are empty, for example. Does anyone know if this sort of implementation is what that card is supposed to allow?
Indeed. If you look at the screenshot, it looks like they showed Twitter that they would embed a video, but if you follow the URL they're embedding, it goes to the now-banned implementation - https://ribbon.co/086f0a?twitter=true
Maybe it's just an old screenshot though. I don't know.
It's called PCI. Unless there was a contract between Ribbon & Twitter this is not at all okay since they were taking payments within the same origin of twitter.com, thus bringing twitter.com into scope of PCI compliance for Ribbon. This was a really basic mistake if there was no contract. Everyone who knows anything about PCI understands this very well.
Hope the Ribbon guys manage to get it resolved. I think it's a great use of the Twitter cards feature and am slightly baffled as to why Twitter would even give developers access to the feature, if only to shut them down immediately afterwards.
I also agree with the sentiment that building anything on Twitter is a risky proposition these days. That said, there's still an appeal in doing so given the volume of users.
So how did this happen? Did someone at Ribbon not bother to check the TOS? Did they check and just think they wouldn't get caught? The article says Ribbon is trying to contact Twitter to find out what happened, I'd think it would make sense to have somewhat closer relations with anyone who has that much power over your company, so you could find out before they shut you down.
"This is clearly something that’s good for Twitter users all over the world."
I can see how it's good for sellers, but am missing how it is so clearly good for me as a buyer (which is what I assume is meant by "Twitter users all over the world"). Is it that I can spend money without learning about what I'm buying beyond what fits into 140 chars that makes it good? Do people do that?
Does Twitter want to scare off every developer? I mean its kind of absurd to just shut down a newly launched service on the same day that it launches. It may violate their policy, fine, change your policy or be friendly with developers to really help them become compliant. This is the Apple/Appgratias thing all over again (in the same week); We don't like what you are doing so we will just shut you down, and boo if you don't like. Imagine how much trust Twitter would get if they would simply work with these app developers instead of drastically changing policy/just making things stop working. Right now, as it stands, I will never even touch their ecosystem in fear that I get more restricted, or even worse, have an entire element of my business shutdown without being able to do anything about it.
Twitter really haven't been doing themselves any favours within the developer community. If not for the constant news we hear of APIs being restricted or cut off completely, it's now the in-stream features as well. Why would any developer now want to work with them?
I just don't....get Twitter at the moment. It'd be nice to have some clarification of why they wish to pursue this draconian mindset, but that's asking too much. I'm surprised that services such as Buffer have came so far.
All hail our glorious leader Twitter, they know what's right. This isn't all too surprising, Twitter have definitely had their fair share of third party shutdowns and controversies, the problem here is that Twitter could care less about anyone else's business that uses their API, even if it means more Twitter users or even a potential offer for partnership and profit. This is an idea that Twitter themselves should have officially got behind, no doubt we'll see something like this from Twitter eventually.
It's a genius idea, but sadly Ribbon just wasted a lot of time and money building a product they can't use. A painful lesson, never build a business on Twitter.