I feel like he has no intention of implementing this. It's all just justification for it to not hit up against an regulatory objections to combining the companies.
We currently support Stripe, Braintree, WePay and Zendesk. PayPal & Help Scout are in the works! We've got several paying customers onboard already through organic channels :)
Twitter recently stopped apps from offering any kind of bulk management services for Twitter accounts. We completely support Twitter trying to stop spam, but this action does nothing of the kind. Here's my full thoughts; http://blog.manageflitter.com/twitter-drowning-spam-why-thei...
Anyway the point of this service us just to point out how ridiculous the restrictions are. We will really be delivering it, however - the economics work. We're just finalising how we'll prove it's real people, most likely with a live stream going at all times.
> Just by measuring a few simple indicators, and plugging them into a baysian probability algorithm, we've been able to detect spam accounts with a very high accuracy.
slight nitpick: the word is "Bayesian", not "baysian"
We use Braintree, but it's a payment gateway in Australia not a full stack solution. You still need to provide your own merchant and account and deal with the endless hassles that come with it. Merchant accounts are really the hard part of accepting money in Australia at this point.
This is a great post. I'm currently building an API that's really inspired by Stripe's API. I'm trying to mimic a lot of these elements, from the easy authentication through to the really useful error messages.
One of the things I'm not so sure about is the local bindings for each language. I'm tempted to just use off-the-shelf HTTP clients or a very thin wrapper in each language and write code snippets based on them. I'm not sure I see the value in writing full client bindings - I've often found it harder to use in many cases when I use these 'opinionated' bindings in the past. You often end up with a choice of entirely following the libraries views on error handling or digging around and breaking upgrades by modifying these libraries directly. I've always preferred much thinner wrappers that have no knowledge of the underlying API calls. Would love more opinions!
As an API author, I think your goal should be to make interacting with your API as simple and robust as possible. The downside with just recommending off-the-shelf HTTP clients is that there's always a ton of logic (whether request formatting, error handling, or turning responses into first-class objects) that the vast majority of consumers of your API want and will have to write on their own. If you look at the internals of our bindings, a lot of the logic is around understanding exceptions (https://github.com/stripe/stripe-ruby/blob/master/lib/stripe...) or interstanding semantics of our API (https://github.com/stripe/stripe-ruby/blob/master/lib/stripe...), which are tasks that would take a newcomer a lot of time to get get spun up on.
There will always be frameworks where your bindings don't work (e.g. our Ruby bindings aren't compatible with EventMachine) or paradigms that they violate (e.g. using error return values in PHP rather than throwing exceptions). That's actually ok -- just because you can't support everyone doesn't mean you should support no one. Instead, we put a lot of effort into making our bindings compatible with as broad of a range of environments as possible (e.g. https://github.com/stripe/stripe-python/blob/master/stripe/_...).
So my advice would be write bindings which convert the semantics of your API to the consumer's language, but which constrain the consumer's application as little as they can. Even if people end up having to use a lower-level abstraction to talk to your API, they can probably steal code or ideas from what you've written.
That's great advice, thanks! Hadn't thought about how it improves the ability of the vast majority of developers to get up to speed with handling edge cases. That's a really good point. Perhaps I'll start with thin wrappers and progressively add deeper bindings to get the best of both worlds.
Writing bindings makes sense if people are paying you to consume your API (AWS, Stripe, Twilio, etc) - it makes it easier for people to pay you money. If not the decision gets a little murkier.
I used to use Fusion on my mid-2010 MacBook Pro and found it pretty much unusable as it was so slow. However I recently installed Parallels on my Rentina MacBook and I've been amazed at the difference. It can run 3 different OSs at once on top of OsX with barely a performance hit. It makes debugging in IE finally practical. Probably the single biggest benefit for me for upgrading my MacBook.
I think it's a great idea that will fail in this implementation.
The first barrier in social networks is people - getting enough people on your network to incentivize others to follow. Is the fact that app.net paid enough to draw people away from Twitter & Facebook? As a developer, perhaps, but as a user, I really doubt it.
A much better sales pitch would be just "you own your data". Give users amazing import/export tools from the get go. Allow third parties to fork your system and allow seamless user migration. Build a protocol, not a service.
With a business hat on, I also worry about the single silo of data in app.net. Say it does become successful, then they're a monopoly again. How can we be sure they'll fairly charge for their API usage when they realise how much it costs to hosts that much real time data? Can we be sure they won't change the playing field again?
Besides all that, I don't get why he wants $500,000 up front. If he wants to "align our financial incentives with members & developers", I would have thought he'd charge a set fee to allow revenue to scale with usage.
Also the language on the site is just so damn confusing. They have lots of ideas jammed in together. Most of the discussion about the idea has been people trying to figure out what they're on about. They need to figure out a sales pitch people can understand and stick to it.
Anyway, lots of huge holes in this implementation IMO. I doubt it'll even get funded.
