|Request for comments: API tax proposal||maciej||3/15/13 8:59 AM|
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
4. $100/year tax if your app makes requests for over 1000 Pinboard
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.
|Re: Request for comments: API tax proposal||Ed Summers||3/15/13 9:05 AM|
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.
|Re: Request for comments: API tax proposal||cori schlegel||3/15/13 9:08 AM|
Well it's good to know that smaller api consumers wouldn't be charged - that means that if I can ever make the time to work on any of my api concepts I won't be prevented from doing so by being charged a fee right off the bat.
The rates and thresholds seem reasonable, and I'm supportive of you being able to fund development, but if I were to write an app that gained over 100 users I might just have to cap it at 99 or kill it - nothing I would write would be commercial and I'm not sure that I could justify even the $20 a year for a labor of love.
Thanks for requesting comments, though!
|Re: Request for comments: API tax proposal||Ryan Bateman||3/15/13 9:16 AM|
This seems like a much better to the alternative that a few API-owners have taken, which is to levy a tax on the end-user, rather than the developer. I developed a third-party client for Instapaper and the requirement that the end-user pay a subscription fee to use third-party apps, rather than have the developer take on that cost, meant that users were wary of signing up and meant that there was an inherent cost for the app, regardless of anything I would charge. I'd have happily forked out $100 for API maintenance / expansion if it meant reducing the the hassle for a user to get my app. It also would have meant that the app could be judged on its own merits, rather than bundled with an inherent cost association that I had no control over, as well as weighed evenly by users against proprietary apps (which, granted, you're not in the business of selling.)
In short, as a developer, I think this is a great approach.
|Re: Request for comments: API tax proposal||maxpower47||3/15/13 9:22 AM|
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.
|Re: Request for comments: API tax proposal||john mckenzie||3/15/13 9:33 AM|
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.
|Re: [pinboard-dev] Request for comments: API tax proposal||Dan Loewenherz||3/15/13 9:43 AM|
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.
|Re: Request for comments: API tax proposal||maciej||3/15/13 9:45 AM|
I have two big reasons for considering charging developers rather than
1. It doesn't feel right to ask people to pay a fee to mangle their
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.
|Re: Request for comments: API tax proposal||Trung T||3/15/13 9:52 AM|
I am very much with Matt here. Pinboard is a great service. I even pay for the archiving option, not much because I need it but I'd want to help the author keep the service running for years to come. However the reality is Pinboard doesn't have huge user base. One must be crazy to attempt to make any real money off a Pinboard app. It must be a labor of love.
|Re: Request for comments: API tax proposal||maciej||3/15/13 9:53 AM|
On Mar 15, 9:43 am, Dan Loewenherz <d...@dlo.me> wrote
> Hi all,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.
> > .
> > Visit this group athttp://groups.google.com/group/pinboard-dev?hl=en.
> > For more options, visithttps://groups.google.com/groups/opt_out.
|Re: Request for comments: API tax proposal||maxpower47||3/15/13 9:58 AM|
"It doesn't feel right to ask people to pay a fee to mangle their
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...
...you do this. I would obviously support this :) Maybe even take it a step further and only exempt free open source apps.
Definitely a good idea. It'd make a nice blog post too.
|Re: Request for comments: API tax proposal||Jonathan Nelson||3/15/13 10:27 AM|
As a heavy PinDroid user, I'd purchase a donation add-on for $5 without hesitation (I promise). PinDroid & Pinboard are absolutely crucial to my positive experience with Android. You only need 20 of us to cover the proposed base cost.
In fact, I think you should add that option in any case. I pay Maciej already, but you enable a solid 0.25 of my daily interaction with Pinboard.
To both you and Maciej: thanks again. For me, Pinboard's value is in the same league as Vim and Dropbox.
|Re: Request for comments: API tax proposal||cori schlegel||3/15/13 12:15 PM|
"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....
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Dan Loewenherz||3/15/13 12:25 PM|
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.
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.
|Re: Request for comments: API tax proposal||kijin||3/15/13 11:28 PM|
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.
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Luca||3/16/13 1:04 AM|
Am Fri, 15 Mar 2013 09:58:48 -0700 (PDT)
schrieb maxpower47 <matthew...@gmail.com>:
> 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.
|Re: [pinboard-dev] Request for comments: API tax proposal||Stephen Darlington||3/16/13 5:38 AM|
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.)
> --> 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.------------------------------------------------------------------------
Stephen Darlington (www.zx81.org.uk)
"The sea monkeys have my money."
|Re: Request for comments: API tax proposal||maciej||3/16/13 10:07 AM|
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.
|Re: Request for comments: API tax proposal||maciej||3/16/13 10:10 AM|
On Mar 16, 1:04 am, Luca Ingianni <luca.ingia...@gmail.com> wrote: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
Oh, not thinking things through is quite characteristic of me.
I'm not sure I understand this.
> Best regards
|Re: Request for comments: API tax proposal||maciej||3/16/13 10:16 AM|
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
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 15 Mar 2013, at 15:59, maciej <mceglow...@gmail.com> wrote:
> > Visit this group athttp://groups.google.com/group/pinboard-dev?hl=en.> > For more options, visithttps://groups.google.com/groups/opt_out.
|Re: [pinboard-dev] Request for comments: API tax proposal||Dan Loewenherz||3/16/13 10:40 AM|
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.
> > To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
|Re: Request for comments: API tax proposal||Mohammad Badi||3/16/13 12:53 PM|
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.
|Re: Request for comments: API tax proposal||maciej||3/16/13 12:58 PM|
I would enjoy that, but I lack the resources to do it.
|Re: Request for comments: API tax proposal||Jean-Michel||3/16/13 2:12 PM|
My short answer: Yes to an API tax if you think it's needed, but it should be paid by the user not the app maker.
This model would make thing more complicated, when I pay for an app how do I make sure that the Pinboard will be paid?
If it's not, I'm stuck with a useless app (I'm guessing it will be blocked), and you don't have the money you wanted/needed to improve the API.
I would suggest a free limited API (limited in functionality and/or rates) and an extended/unlimited API the user has to pay for.
With that we are sure that the money goes where it should, and it make the life of the free app/plugin/api easier.
After all if I want some extra toppings on pizza, I just have to pay for them.
|Re: Request for comments: API tax proposal||mzehrer||3/17/13 1:59 AM|
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.
|Re: Request for comments: API tax proposal||kijin||3/17/13 8:13 AM|
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.
On Sunday, March 17, 2013 2:07:29 AM UTC+9, maciej wrote:
These are good points.
|Re: Request for comments: API tax proposal||Amy||3/17/13 1:27 PM|
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.
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Paul Walker||3/18/13 9:45 AM|
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?
On 16 March 2013 17:10, maciej <mcegl...@gmail.com> wrote:
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Dan Loewenherz||3/18/13 9:47 AM|
On Mon, Mar 18, 2013 at 9:45 AM, Paul Walker <ara...@gmail.com> wrote:
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.
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Trung T||3/18/13 9:55 AM|
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.
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Marsh Gardiner||3/18/13 11:45 AM|
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:
A couple potential problems:
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).
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||maxpower47||3/18/13 12:05 PM|
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.
|Re: Request for comments: API tax proposal||Collin Donnell||3/18/13 3:25 PM|
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.
|Re: Request for comments: API tax proposal||maciej||3/18/13 3:44 PM|
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.
|Re: Request for comments: API tax proposal||maciej||3/18/13 3:50 PM|
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.
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.
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.
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Collin Donnell||3/18/13 3:55 PM|
> This is a much better solution. I would imagine apps in good standingThis 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.
|Re: Request for comments: API tax proposal||maciej||3/18/13 4:06 PM|
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>
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Collin Donnell||3/18/13 4:16 PM|
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.
|Re: Request for comments: API tax proposal||Marsh Gardiner||3/18/13 4:46 PM|
On Monday, March 18, 2013 3:50:57 PM UTC-7, maciej wrote: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!
|Re: [pinboard-dev] Re: Request for comments: API tax proposal||Paul Walker||3/19/13 6:04 AM|
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.
|Re: Request for comments: API tax proposal||mike||3/22/13 11:51 AM|
As long as I can run my nightly pinboard backup scripts (1 per account) I won't be too put off. If I wind up somehow losing the capability to ensure I have an offline copy of my bookmarks I will be severely upset. I already paid for the lifetime service (+ archiving) for 2 accounts, I feel I am entitled to some "included" API access.
(btw it is this once per day per account)
wget -O- -q https://myuser:email@example.com/v1/posts/all | gzip -9 > /backupdir/pinboard-myuser.json.gz
The big question - how will this change for apps like Reeder? Will they have to pay? I already paid for Pinboard, I already paid for Reeder, I don't feel like it is fair to start charging Reeder more (if I understand this concept) which in turn will either bankrupt Reeder, or require them to charge their customers (me) more. I don't understand if Reeder (for example) qualifies as an "app that makes requests on behalf of someone else" or not.
|Re: Request for comments: API tax proposal||junkyardsparkle||4/20/13 5:13 PM|
On Saturday, March 16, 2013 10:16:41 AM UTC-7, maciej wrote:
Do you think you may be in a slightly unique position owing to the fact that you're running a service that has no "free" users? Without having much real insight, I would have guessed that this would enable you to cultivate a slightly deeper cooperative relationship with the user-base, setting clearly defined usage limits, the violation of which will result in throttling or whatever. But maybe I'm deluded about that. Even in the case of clients that are distributed by developers (as opposed to random user scripts) I would think that making the account holder responsible for the behavior of clients that they use would result in a pretty fast feedback loop for developers... but like I said, I have no real grasp of the issue. :)
One point about API keys and open source projects: I prefer to obtain packages for my android device through non-market sources, not having it linked to a Google account. I primarily use f-droid for this purpose, and I'm aware of at least one app that lacks certain functionality because the API key isn't included in the source that they build from. I would hope that whatever solution you arrive at would be friendly to third-party repositories of open source apps as well as the developers themselves.
|Re: Request for comments: API tax proposal||Håvard Pedersen||8/12/13 2:51 AM|
So essentially killing all freeware Pinboard apps?
Hi everyone,Kind regards,