Request for comments: API tax proposal

[maciej]

Hi everyone,

I've been thinking about imposing an API tax, the proceeds of which
would go into improving API infrastructure and offsetting operating
costs, structured along these lines:

1. API free to use for your own Pinboard account
2. Every API client making requests on behalf of someone else must
register an app identifier
3. $20/year tax if your app makes requests for over 100 Pinboard
accounts
4. $100/year tax if your app makes requests for over 1000 Pinboard
accounts
5. Possibly additional price levels to waive certain rate limits.

These thresholds may change, but that's the gist of it. Think of it
as a road tax that then pays for further construction, repair, and
people in orange vests.

Please let me know your comments, and if you have had experience with
similar arrangements elsewhere.

Kind regards,

Maciej

[Ed Summers]

I really like this. One thing that would be nice to see would be client stats in a report of some kind. I don't know if that's wise/doable but it would be really interesting to see if it can be made visible.

//Ed

[maxpower47]

As the developer of the leading Android Pinboard app (PinDroid), I'm very much against this.  Why would you tax the makers of the apps that help drive use of your product, rather than the users themselves?  To extend your road use tax analogy, this is like taxing the car companies for their customer's use of the roads.

I offer PinDroid as a free, open source app and have no interest in making money off it, but I also have no interest in losing money on it.  Why not offer api access as a premium account feature (like archiving) for an extra buck instead?

To be clear, if such a "tax" were to be imlemented, I will have to stop developing and supporting PinDroid and take it off the market.  That's not something I'd like to do.

Matt Schmidt

PinDroid

On Friday, March 15, 2013 11:59:38 AM UTC-4, maciej wrote:

[john mckenzie]

As a PinDroid user, I’ll just say, I would be willing to pay a couple of bucks for the convenience, and my natural expectation would be to pay for the app, rather than navigating over to pinboard.in and turning on API access.

[Dan Loewenherz]

Hi all,

I think this is a great idea, but I think the pricing structure should reward clients who do "less with more". E.g., the scheme you proposed is open to abuse by clients that make a lot of unnecessary requests. With that in mind, I think a "requests-focused" pricing strategy would be more appropriate. It's less strain on the API to serve 100 users one request each than 1000 requests to one user.

There are also a few things that I think should be added/fixed this gets put into effect:

1) Fix posts/update. As Collin wrote in an earlier email today, it returns an incorrect value for the last time bookmarks were updated. Because clients don't have correct data from this method, they need to call posts/all every time the user wants to sync. Ideally clients should only pull down the bookmarks that have changed, which brings me to...

2) Add another API method that returns bookmarks updated OR added since X time.

3) Add a updated_at attribute for bookmark related payloads.

4) Rate limit requests and provide an endpoint that displays how many requests are left for the client before it gets bumped up to the next "pay grade" in the payload of every authenticated request.

It would be nice to have analytics as well...but IMO that's a nice to have more than a necessity.

Dan

--
You received this message because you are subscribed to the Google Groups "Pinboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pinboard-dev...@googlegroups.com.
To post to this group, send email to pinboa...@googlegroups.com.
Visit this group at http://groups.google.com/group/pinboard-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[maciej]

I have two big reasons for considering charging developers rather than
end users:

1. It doesn't feel right to ask people to pay a fee to mangle their
own data.

2. A per-app fee does a better job of tracking actual API use. If
5,000 users pay to 'unlock' the API, I'll get the same amount of money
whether they sign up for one app or twenty, even though there would be
a twenty-fold difference in traffic.

I like PinDroid a lot and don't want to antagonize you, or other
people who develop cool free Pinboard apps. One thing I'm considering
is waiving the tax for free apps. The first step is to introduce app
identifiers so I can at least get a sense of who the heaviest users
are, and what the impact of various approaches would be.

M

[maciej]

On Mar 15, 9:43 am, Dan Loewenherz <d...@dlo.me> wrote

> Hi all,
>
> I think this is a great idea, but I think the pricing structure should
> reward clients who do "less with more". E.g., the scheme you proposed is
> open to abuse by clients that make a lot of unnecessary requests. With that
> in mind, I think a "requests-focused" pricing strategy would be more
> appropriate. It's less strain on the API to serve 100 users one request
> each than 1000 requests to one user.

My guess is that it's actually easier for the API to deal with a flood
of requests for one user, due to the way the MySQL buffer pool
behaves. But this is something I need to test.

With regard to the API shortcomings you point out, the tax stuff would
correspond to a v2 release of the API with much saner behavior. The
current API is based on a pretty terrible design whose one virtue is
backwards compatibility. The biggest shortcoming is a lack of any way
to ask 'show me stuff that has changed since X'.

The posts/update bug is one I'll try to fix this week.

> > email to pinboard-dev...@googlegroups.com <javascript:;>.
> > To post to this group, send email to pinboa...@googlegroups.com<javascript:;>
> > .
> > Visit this group athttp://groups.google.com/group/pinboard-dev?hl=en.
> > For more options, visithttps://groups.google.com/groups/opt_out.

[maxpower47]

"It doesn't feel right to ask people to pay a fee to mangle their 
own data. "

Understood, but they'll still pay for it implicitly (and more than necessary) by not having any free app options.  Since minimum app pricing is $.99 in most stores, users would be paying $1/app instead of $.10 ($100 / 1000 users in your proposal) to enable access to all apps they want to use.  Unless...

"One thing I'm considering 

is waiving the tax for free apps."

...you do this.  I would obviously support this :)  Maybe even take it a step further and only exempt free open source apps.

"The first step is to introduce app 
identifiers so I can at least get a sense of who the heaviest users 
are"

Definitely a good idea.  It'd make a nice blog post too.

Matt Schmidt

PinDroid

[cori schlegel]

"One thing I'm considering is waiving the tax for free apps."

This would satisfy my concerns, I suspect - anything I would develop would be a web app that I wouldn't charge for....

[Dan Loewenherz]

One thing that I forgot to mention is that if this is carried out, I'm probably going to switch Pushpin to a subscription model ($x / year) with a free download as opposed to a pay once for download model. I can imagine other apps that want to continue to exist will have to make similar changes to remain profitable.

> > I think this is a great idea, but I think the pricing structure should

> > reward clients who do "less with more". E.g., the scheme you proposed is

> > open to abuse by clients that make a lot of unnecessary requests. With that

> > in mind, I think a "requests-focused" pricing strategy would be more

> > appropriate. It's less strain on the API to serve 100 users one request

> > each than 1000 requests to one user.

> 

> My guess is that it's actually easier for the API to deal with a flood

> of requests for one user, due to the way the MySQL buffer pool

> behaves. But this is something I need to test.

My point here is more that it's probably preferable to you to reward efficient clients. Maybe a better example: 100 users making 100 requests each is more taxing than 100 users making 1 request each.

Dan

[kijin]

The basic idea sounds good. But I'm not sure what is meant by "API free to use for your own Pinboard account". Few people use bare curl to make API requests. Most people use one or another API client software, whether it's a consumer-oriented Android app or a developer-oriented PHP/Python/Ruby library.

There are also a lot of unusual use cases out there, e.g. I recently saw a Habari (blogging software) plugin that uses the PHP Pinboard API Client (open-source) to pull a person's bookmarks into his own blog. Does that count as accessing one's own account? Should the plugin author pay up if the plugin is used by hundreds of others? Or should the author of the API client (myself in this case) pay? If there is to be an exception for free or open-source clients, how is the whitelist going to be maintained so that proprietary clients that "piggyback" on free ones don't get a free ride?

I suppose a lot of these questions can be answered by using a clever authentication scheme (such as the app identifier that maciej mentioned), but it still sounds needlessly complicated to me. As an open-source developer, I am generally wary of requests to embed some sort of secret identifier into my software, whether it's a reusable library or an end-user app.

On the other hand, as the other posters have mentioned, heavy use might be problematic even if it's only one person accessing his own account. So I would prefer a pricing scheme that punishes heavy users rather than application developers. Perhaps each account should only be allowed a certain amount of API accesses per month (enough for personal blog integration and occasional backups), and there should be paid tiers for accesses above that amount.

Kijin

[Luca Ingianni]

Am Fri, 15 Mar 2013 09:58:48 -0700 (PDT)
schrieb maxpower47 <matthew...@gmail.com>:

> "It doesn't feel right to ask people to pay a fee to mangle their
> own data. "
>
> Understood, but they'll still pay for it implicitly (and more than
> necessary) by not having any free app options. Since minimum app
> pricing is $.99 in most stores, users would be paying $1/app instead
> of $.10 ($100 / 1000 users in your proposal) to enable access to all
> apps they want to use. Unless...
>
> "One thing I'm considering
> is waiving the tax for free apps."
>
> ...you do this. I would obviously support this :) Maybe even take

> it a step further and only exempt free *open source* apps.

I'm with Matt on this one.
I like the idea of only waiving it for open source apps - everbody else
can be assumed to have some kind of (at least future) financial
interest. And if you want to go that route, the pricing appears
reasonable to me.

It actually feels like, quite uncharacteristically for you, you didn't
think the issue of free (as in whatever) apps through.

BTW, as Kijin addressed, I'm genuinely interested to see how you
solve the question of authentication.

Best regards
Luca

[Stephen Darlington]

I'm curious about the motivation behind this. Do API users consume a disproportionate amount of resources?

Would it not make more sense to provide a better API and rate limits rather than "taxing" people who help build your "ecosystem"?

(Full disclosure: I'm not entirely impartial here, since I make Yummy.)

Cheers,
Stephen

> --
> You received this message because you are subscribed to the Google Groups "Pinboard" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to pinboard-dev...@googlegroups.com.

> To post to this group, send email to pinboa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/pinboard-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

------------------------------------------------------------------------
Stephen Darlington (www.zx81.org.uk)
"The sea monkeys have my money."
------------------------------------------------------------------------

[maciej]

These are good points.

I'm inclined to be very lenient about what constitutes 'using your own
Pinboard account'. In my mind, developer libraries and plugins that
you host and run yourself don't count. Pretty apps that you buy on
the app store count. Websites that let you link in your Pinboard
account (and whose server interacts with the API) count.

I have always resisted having price tiers on Pinboard. I feel it
imposes a cognitive load on people that is out of all proportion to
the benefit. No one should have to care how many bookmarks they have,
how many API calls they make, and so on.

The app identifier is not a secret of any kind. It is basically a
less error-prone version of the user agent string that almost all API
clients already send. One of the main reasons I want to introduce it
is so I can track usage patterns. This will give app/plugin/site
authors useful feedback about how their stuff is getting used, and it
will help me find ways I can make the API more responsive.

[maciej]

On Mar 16, 1:04 am, Luca Ingianni <luca.ingia...@gmail.com> wrote:

> I'm with Matt on this one.
> I like the idea of only waiving it for open source apps - everbody else
> can be assumed to have some kind of (at least future) financial
> interest. And if you want to go that route, the pricing appears
> reasonable to me.

My goal is just not to penalize people for doing cool stuff with
Pinboard. I don't really care about the open source angle (in this
specific context).

> It actually feels like, quite uncharacteristically for you, you didn't
> think the issue of free (as in whatever) apps through.

Oh, not thinking things through is quite characteristic of me.

> BTW, as Kijin addressed, I'm genuinely interested to see how you
> solve the question of authentication.

I'm not sure I understand this.
>
> Best regards
> Luca

[maciej]

The basic problem is, I have strong disincentives to expand the API.
Let's say, for example, I exposed search via the API. The immediate
effect would be to DDOS the search engine.

Every improvement I make to the API creates a huge additional
workload, to handle the new clients that pop up to use and abuse the
feature.

I've talked to other projects and it seems to be the universal
experience that an API endpoint gets hammered in a way the actual site
never does. People will, through neglect or indifference, throw up
scripts that try to make thousands of calls a minute.

An API tax would create a dedicated revenue stream I could pour
directly back into the API, both by adding hardware and hiring
contractors. And I would not feel like I was taking resources away
from other parts of the site to do it.

Does that clarify my motives a bit?

On Mar 16, 5:38 am, Stephen Darlington <step...@zx81.org.uk> wrote:
> I'm curious about the motivation behind this. Do API users consume a disproportionate amount of resources?
>
> Would it not make more sense to provide a better API and rate limits rather than "taxing" people who help build your "ecosystem"?
>
> (Full disclosure: I'm not entirely impartial here, since I make Yummy.)
>
> Cheers,
> Stephen
>

> On 15 Mar 2013, at 15:59, maciej <mceglow...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hi everyone,
>
> > I've been thinking about imposing an API tax, the proceeds of which
> > would go into improving API infrastructure and offsetting operating
> > costs, structured along these lines:
>
> > 1. API free to use for your own Pinboard account
> > 2. Every API client making requests on behalf of someone else must
> > register an app identifier
> > 3. $20/year tax if your app makes requests for over 100 Pinboard
> > accounts
> > 4. $100/year tax if your app makes requests for over 1000 Pinboard
> > accounts
> > 5. Possibly additional price levels to waive certain rate limits.
>
> > These thresholds may change, but that's the gist of it.    Think of it
> > as a road tax that then pays for further construction, repair, and
> > people in orange vests.
>
> > Please let me know your comments, and if you have had experience with
> > similar arrangements elsewhere.
>
> > Kind regards,
>
> > Maciej
>
> > --
> > You received this message because you are subscribed to the Google Groups "Pinboard" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to pinboard-dev...@googlegroups.com.
> > To post to this group, send email to pinboa...@googlegroups.com.

> > Visit this group athttp://groups.google.com/group/pinboard-dev?hl=en.

> > For more options, visithttps://groups.google.com/groups/opt_out.

[Dan Loewenherz]

This was my first assumption and is the main reason why (even as a developer of a popular-ish app on iOS) that I am very strongly for this proposal. There are a lot of feature requests I get that at the moment I have to turn down since the API isn't able to fully replicate the web experience.

+1

Dan

[Mohammad Badi]

It sounds totally good but for a certain moment, Twitter Tokens movie was brought back to my mind. I don't know if this has anything to do with that you're thinking to do or not.

It's a nice idea but there is an even greater one I'd love to share. How about you develop a "Paid" app for iOS and Android? This way, the revenue of Pinboard clients will go to Pinboard, the official app is always the more trusted in terms of feature addition and continuos support by people. And yes, keep charging third-party developers but lower the price. More revenue, more developers working on Pinboard clients/integration as the tax is inexpensive, we users happy.

Good luck with whatever you pick.

[maciej]

I would enjoy that, but I lack the resources to do it.

[mzehrer]

Hi,

I'm the developer of crofflr and I think I'm a "light" API user (would be interesting to see the statistics that would be part of app keys). 

A yearly tax would be OK for me, but what about a one time payment to unlock some kind of API barrier beyond personal use?

One time payments work for Pinboard users, why not for developers? And for super heavy users you could make a yearly tax, analog to the archive option for users.

Michael

[kijin]

Thanks for the clarification. In fact, I think it would be very useful if library/app developers could register their user agents (or a more specific identifier) and get detailed statistics about their use. If the reports are detailed enough, it might also help library/app developers optimize their code and avoid costly requests.

Still, I would like to suggest a **gradual** introduction of any fee structure that you might have in mind, rather than setting up arbitrary fees before you even have any concrete and mutually agreed-upon data points. Give people a few weeks to sign up for app identifiers and track actual usage. Once most apps are on board and you have enough data about the usage patterns of various apps and their impact on your systems (for example, 100 requests for posts/all should probably carry more weight than 100 requests for posts/get), you can combine that data with the cost of administration plus reasonable profits to come up with a fee structure that most people would agree is fair. As several others have pointed out, the initial proposal seems to be too crude given that some apps only ever call posts/add whereas other apps regularly make much more resource-intensive requests. Even though the amounts in question are trivial to most people, a gesture of commitment to fairness and data-based decision-making would go a long way toward avoiding a Twitter-like controversy, which some people seem all too happy to stir up at every opportunity.

BTW, I would also like to repeat what some other posters have also mentioned: please provide quirk-free alternatives to posts/update and similarly quirky, Delicious-era API calls. As long as the API is backwards compatible with Delicious, I don't think anyone would miss forward compatibility with Delicious. I'm sure a lot of developers will be happy to take advantage of such improvements to make their apps lighter on your resources. That looks like a win-win to me.

Kijin

[Amy]

This makes a lot of sense to me (both charging for most API use, and charging developers rather than end users).  I could see that you might end up tweaking the proposed pricing structure further.

[Paul Walker]

Hi Maciej

One thing that I think a few people have touched on but not really brought up strongly - if an app is open source, how do you stop another developer simply taking the app ID? Any situation where you're reliant on client behaviour is going to be vulnerable. This may or may not matter in general, but as soon as you start involving cash it does. For example, taking PinDroid, if there's an source repo with the app id in it, and I want to develop and sell a client without paying the pinboard API tax, how do you stop me from doing that without killing all access to pindroid as well?

>
> Best regards
> Luca

--
You received this message because you are subscribed to the Google Groups "Pinboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pinboard-dev...@googlegroups.com.
To post to this group, send email to pinboa...@googlegroups.com.
Visit this group at http://groups.google.com/group/pinboard-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Paul

[Dan Loewenherz]

On Mon, Mar 18, 2013 at 9:45 AM, Paul Walker <ara...@gmail.com> wrote:

One thing that I think a few people have touched on but not really brought up strongly - if an app is open source, how do you stop another developer simply taking the app ID? Any situation where you're reliant on client behaviour is going to be vulnerable. This may or may not matter in general, but as soon as you start involving cash it does. For example, taking PinDroid, if there's an source repo with the app id in it, and I want to develop and sell a client without paying the pinboard API tax, how do you stop me from doing that without killing all access to pindroid as well?

I think the solution here (like most other open source applications that rely on third parties) is to not include the application ID in the open-source distribution, and only include it when submitting to the app store it lives on.

[Trung T]

I agree if it is a mobile app. Afterall whoever submits it to the app store must sign it with a private key which should not be in the public repository.
Thing can get muddy if it's an webapp or an webapp plugin, say an open source WordPress plugin which anyone can install and use in their personal blog. Each installation of that plugin must require a separate app id. OTOH there's some value in knowing all those installations actually use the same code base that doesn't use the API in the most efficient way.

Trung

[Marsh Gardiner]

This is a fascinating question, and I'm enjoying the discussion so far. 

As I understand it, the implementation steps to  would be something like:

1. Issue an appid to every API client. 
   
2. Promote usage of appids by clients.
   
3. Turn off access to non-identified clients. (Twitter does a great job with their migration approach to these problems.)

A couple potential problems:

1. What happens when a developer doesn't pay in the following year? If you shut off access for that app, you end up punishing users.
2. Once you tie payment to usage, you incentivize some undesirable behavior. Application credentials are hard to keep secret, since they are included in every request and are in every app's code on mobile devices. How will you or devs know when an appid has been compromised? 

In contrast, why not ask all users to pay a one-time amount, say $5, to unlock access via the API? If you were to implement OAuth, then you could present the API "upgrade" the first time a user is brought to the consent flow. You would get the visibility into API usage per app. It also helps break the password anti-pattern.

If you don't opt for OAuth, then consider something like "certifying" client applications who do pay. Once an app has paid their annual fee, they appear on the list of officially licensed apps, and you encourage clients to link directly to that page on pinboard.in. Then the fee becomes about mutual trust in the pinboard ecosystem rather than a toll (grant additional benefits rather than extract rents).

Marsh

[maxpower47]

The only reasonable way to keep the api keys secret is to use them in some sort of cryptographic signature on the api call that is made, kind of like oauth, rather than including it as a plaintext parameter in the call.  I'm planning on keeping my key out of github, but that wouldn't stop anyone from grabbing it out of the call with wireshark or something unless its encrypted somehow.

Matt Schmidt

PinDroid

[Collin Donnell]

First: as a developer of an app, if you've decided someone has to pay, I would much rather it be us than users. Charging users for API access is only going to significantly limit the number of people I can sell to, and would probably end up costing me a lot more than $100/year.

While I’d rather developers pay than users, I do have some issues with the idea of charging anyone at all, though. 

First I think that having good client apps out there promotes Pinboard, so we’re already providing value to the service. I've heard from a lot of users that they had bought Pinboard, and were not using at all until discovering my app. I’ve also heard from others who’ve only paid for Pinboard after finding out that an app like mine exists. I’m not sure it makes sense to charge developers who help promote your service and provide value to your users for doing so.

My other concern is around support. I think if you’re going to start charging developers, you’re making us customers, and that changes the relationship. Specifically, I would expect anyone I’m giving money to offer some level of support, both in the form of offering a clear channel of communication to which I can expect a timely response from, and also in actively developing the API and fixing bugs when they’re reported.

If you are set on the idea of charging developers, I think that showing some good faith by becoming more responsive to them and fixing bugs in the API up front for a period of time would soften the blow significantly. That being said, I feel as though I’m already providing value to Pinboard and it’s users and think that’s reason enough to do those things.

[maciej]

I think the thing I have in mind is more cooperative than most
commenters realize. I'm not going to shut apps out if they don't pay
the API tax. Rather, I'm relying on the fact that 1) it's not a lot
of money and 2) it funnels directly back into API development.

On the other hand, I would be very aggressive with anyone who
improperly used an app identifier. So I don't think there will be
much incentive to misuse them.

[maciej]

On Mar 18, 11:45 am, Marsh Gardiner <marsh.gardi...@gmail.com> wrote:

>    1. What happens when a developer doesn't pay in the following year? If

>    you shut off access for that app, you end up punishing users.

I won't turn off access for lack of payment. It's not worth $100 to me
to make over a thousand users unhappy with my site. This is intended
to be more cooperative than coercive.

> In contrast, why not ask all users to pay a one-time amount, say $5, to
> unlock access via the API? If you were to implement OAuth, then you could
> present the API "upgrade" the first time a user is brought to the consent
> flow. You would get the visibility into API usage per app. It also helps
> break the password anti-pattern.

I dislike this a lot because I would hate having to pay to unlock
features as a user. Presumably the authenticating user would have
just paid for some API-enabled app, and the first thing they see is a
Pinboard paywall. That is a terrible outcome for everyone.

The second reason I dislike it is that it does not track API use.
Once you've unlocked the API for your account, you might use one app
or a dozen.

> If you don't opt for OAuth, then consider something like "certifying"
> client applications who do pay. Once an app has paid their annual fee, they
> appear on the list of officially licensed apps, and you encourage clients
> to link directly to that page on pinboard.in. Then the fee becomes about
> mutual trust in the pinboard ecosystem rather than a toll (grant additional
> benefits rather than extract rents).

This is a much better solution. I would imagine apps in good standing
get their place in the sun on the resources page (suitably revamped)
while others wait in the outer darkness.

>
> Marsh
>
>
>
>
>
>
>
> On Monday, March 18, 2013 9:47:28 AM UTC-7, Dan Loewenherz wrote:
>

> > On Mon, Mar 18, 2013 at 9:45 AM, Paul Walker <ara...@gmail.com<javascript:>

[Collin Donnell]

> This is a much better solution. I would imagine apps in good standing
> get their place in the sun on the resources page (suitably revamped)
> while others wait in the outer darkness.

This definitely makes the idea a bit more appealing if we're promoted more heavily for being good citizens and by the value we give to the users.

[maciej]

I agree with a lot of what you say. Client apps help the site by
attracting new customers, and by making it more appealing through the
presence of an ecosystem.

But I'd encourage you not to think of this as a customer-client
relationship. I'm asking for people who have built a business on
Pinboard to contribute a small amount of money, which I will then
spend on improving the infrastructure they rely on.

I agree with you that any API should work properly and offer decent
support channels before money starts changing hands. For the time
being, I want to introduce app IDs and have this discussion, with the
understanding that an API tax will 1) not be coercive and 2) not
happen until there are significant positive API changes.



On Mar 18, 3:25 pm, Collin Donnell <col...@albinadevelopment.com>
wrote:

[Collin Donnell]

I think app IDs are definitely a good idea, if for no other reason so that you can can shutdown potential abusers going forward.

Maybe customer-client is the wrong way to look at it. A better way might be to say that it formalizes the business relationship between developers and Pinboard in a way that does not exist now. That's not necessarily a bad thing.

We agree on the two things you mention. As long as it ends up providing more value than it costs, it's something I can get behind. I think #2 would be enough to demonstrate that.

[Marsh Gardiner]

On Monday, March 18, 2013 3:50:57 PM UTC-7, maciej wrote:

> The second reason I dislike it is that it does not track API use. 

> Once you've unlocked the API for your account, you might use one app 
> or a dozen. 

Since your system would grant the OAuth access token, it would know to which user it maps as well as to which app (and would be unique per user per app). As you validated it on incoming requests, you could look up the metadata to bucket it by user and app in your analytics. 

But I definitely agree that a "place in the sun" is a way to highlight and encourage certain behavior!

Marsh

[Paul Walker]

Hi,

Not all applications are webapps or mobile apps. If you're developing a desktop application for people to use, it's a hassle (and not particularly friendly) if the first thing they have to do when they get it is go to some developer corner of the pinboard site, register as a developer, put in some kind of app ID, get a strange string, and paste it into the application. It also stops Maciej from tracking applications properly.

Please note I'm not against the idea - I think it's useful to invest in the infrastructure. I just want to make sure that people don't make assumptions about what's going to be developed that causes grief later down the line. If this automatically penalises free software (by decreasing the usability), that's not good.

Thanks,

Paul

--

You received this message because you are subscribed to the Google Groups "Pinboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pinboard-dev...@googlegroups.com.
To post to this group, send email to pinboa...@googlegroups.com.
Visit this group at http://groups.google.com/group/pinboard-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Paul

[Håvard Pedersen]

So essentially killing all freeware Pinboard apps?