dtsingletary

Definitely would suggest going beyond the Klout Score and implementing a mix of topics, topical scores, interest and influence into the Klout calculation. The raw Klout Score is a bit broader than necessary for lead qualification and relevance.

Also worth investigating is http://apis.io/ , a growing repository for API interface design patterns.

What sort of options do you have for curation, filtering? How do you find the wheat from the chafe?

Why? It protects the user's privacy, unlike Facebook. Ask them for their email address after they authenticate and make it an act of volition.

This is silly. You've licensed nearly every game you ever bought since the 90s, likely even before that. You've never owned it; you just felt like you did. Server-side storage and 'online-only' gaming just solidifies this in a technological sense, not a legal one.

This is my next YC project.

Instagram's Terms essentially say you have to respect the copyright and license of the photos.

However, their API doesn't provide any mechanism to know what those licenses and copyrights are yet, which makes it pretty difficult to honor it. Still, you're bound by the terms, not their execution. If it's a business you plan to make money off of, you should probably consult legal advice and plan ahead to lose it.

Which is why it behooves you to contact them and get clarification, exception, etc. The same rules don't apply to everyone equally if you can make the right case. Simply displaying their content is not likely to get a pass, but having a way to brand it well and drive new content creation often will.

Contacting them is your best option. Find some one to talk to, explain what you'd like to do, and how the terms restrict you, and see if you can't find a way to have an exception, clarification, or some other way around it.

The spirit of that is most likely: "You won't resell or grant your access to the API to other people, or allow someone else to to resell or grant access to the API."

Not generally the content you're getting from the API (although you wouldn't be selling or providing that to others, either, you'd be creating some derivative of it).

Twitter does make money on its API. It's done through channel partnerships. Is it as much as advertising? No. But still significant.

Twitter's API is still sufficiently open. There's plenty of data to be had. The limitations and constraints breeds creativity, and we'll finally see new integrations and ideas that do something new rather than simple enhancements and user-annoyance-fixing-as-a-product.

This is clever. At my last startup we were building a tweet-based mechanism for buying and selling goods and services over Twitter. We'd use procedurally-generated haikus, along with unique hashtags for location.

The haikus would have particular forms for buyers and sellers, but also create unique creative content on Twitter. The idea is that it would create an artform out of transactions.

Really like the thought behind this (at least until I start thinking about security...).

Playing entirely by the rules tends to put one at a competitive disadvantage in social these days.

"c. You must not incentivize users to Like any Page other than your own site or application, and any incentive you provide must be available to new and existing users who Like your Page."

Not entirely dismissive of it, at least! Likes are ok.

Not to be negative, and you've likely done some research here, but keep in mind the social network policies on incentivizing sharing and social actions:

FB: "You must not incentivize users to use (or gate content behind the use of) Facebook social channels, or imply that an incentive is directly tied to the use of our channels."

While you can see this data from Facebook--and yes, that's jarring-- what you're allowed to do with it is something different. You can't sell it, you can't sell it to an ad network/exchange, you can't retain it after the user revokes permission; you can't even sell derivatives of the data.

Facebook Connect is the most benign of these sorts of things there are-- it's access to data, and the implementors of its widgets and API-- have an onus to protect it.

Now, of course, there's plenty of bad actors out there, and I'm sure it's sold and exchanged, but technically and legally speaking, you're forbidden from doing so.

Yes, it is. There are ways to build authentic engagement and attention. The only usable situation for this is for prototyping at scale: if youre software needed to stress test reading through a fan page with x number of fans or likes in order to understand how it works.

Otherwise it's no different than fixing your books, cheating on your taxes, modding your console so you can have better performance in leaderboards, etc. And activity like this will put a black mark against your startu for years to come.

An 'ad' isn't the only activity Starbucks would post. We're in a less traditional paradigm here. Starbucks can do ad-hoc market research, community building, announce products... Lots of things. Some of the other commenters build on this further through competitive analysis and predictive modeling. Over the next few years we'll see this go further as they better understand the cooperative nature of brands and likes.

I'm happy to answer questions in regards to Klout as far as I can. We utilize GNIP and Datasift both for different situations, but we're working on a different side of data than you are, it sounds. Feel free to email me at api@klout.com.

Singly's big offer isn't just the federation of identity and identity services/authentication (that's just a value add and a sourcepoint). It's treating content as collections of their social objects (status, photo, video, location), and being able to retrieve and manipulate them irrespective of which network they came from.

When there are thousands upon thousands of 'partners' integrating their API, how does a consumer, or a business, sift through that shit and find the gems?

How does Twitter even know about or be aware of apps that are either violating their terms (before or after any terms change), or are awesome and solve a unique problem?

They're big enough now that this is a required means of developer communication, verification, and management.

This applies to any platform after a good length of time and adoption. It probably should have come sooner-- it may have even better telegraphed their hand before the blog posts did.

I understand the grammar of it, but the question is: if one implies, and you don't infer the implication-- did the implication exist? It's basically the tree falling in the forest. I've never read anything from Facebook that implies this. If they inferred it, they did so incorrectly.

Where exactly is this 'implicit promise'? It's implied. Implication is in the eye of the reader/understander, not the stater/provider.

... Which you could them pull into a database and filter with your Regex after the API. What does the noise cost you? It's a solvable problem. true, the expanded results may keep you from getting relevant tweets due to rate limiting.

Thanks for mentioning the Klout API docs (http://developer.klout.com). They're a work in progress, but we lean heavily on Mashery's I/O Docs solution for self-documenting response and request formats. I continue to work on expanding out more detailed docs, but I generally feel strongly that API docs should be entertaining and tell a story. This aligns fairly well with how Dwolla (http://developers.dwolla.com/) aimed their portal at both business and developers.

As an aside, we use Swagger internally to manage and self-document here, and then I/O Docs on the third-party developer side. It's a nice separation of concerns.

It actually resembles Whit.li (http://www.whit.li/) a lot more than Klout.

Parse's portal gets a great melding of form, function, and philosophy. http://www.parse.com

FullContact's portal has some nifty navigation on the documentation: http://www.fullcontact.com/developer/docs/

An honorable mention should goto the creativity behind Twitter's Field Guide: https://dev.twitter.com/docs/platform-objects

TweetDeck is now a Chrome-hosted app. I haven't missed any feature changes between it and the old AIR app.

Urban Airship. Parse.

I think the point you're missing is including a technical one: for a good number of users, getting a tweet history "hits the disk." The limited history is in part due to what's in memory on their servers and easiest to serve.

The historic tweet providers don't have this problem-- they (currently) can monetize to offset the cost of the servers to store the data in a necessary way, or by being for analysis only, the fetch-speed (if from disk) isn't as much of a concern.

Building a business on Twitter doesn't require using one of the other providers, unless that business is analytics.

Rate limits aren't some boogeyman. They're a financial and technological necessity to dissuade abuse and plan for capacity. Serving data isn't free (as in money). Have we had a semi-public API with as much data served in the past? How do you offset that "cost-center" right now?

This is one of those products that seems like an obvious compliment to the "digital album", in that additional content-- interactive communication, behind-the-scenes recordings, alternate takes, and all of that goodness can accompany the output of any release.