Decide on how to link expences to donations #4
Comments
|
I think the natural form, given that almost all services use a subscription model, is to have the keys expire after a certain time. That, however, requires that global api keys 'roll over' . I had always had an expiry and recurring payments in mind. That would keep the information we need to store anonymous, just token and date. I hadn't considered getting more than one key. |
|
Maybe you can add some kind of rate limit. So instead of requesting the usage just set a rate limit of API calls. That could be depended of the paid amount. So keypeer just would need to know, how much the user paid and return the API key with a rate limit to the application. |
|
Problem is that API calls are done by application directly, not through keepeer. Which is intended design as nobody wants to have a proxy for all services. This includes users, app developers, and end-services. Just imagine privacy implications of having it go through the same proxy. |
|
For sure not like a proxy. I thought more of like a counter of requests within the application. In angular for example are interceptors, that could do something like this. |
|
That would make writing applications more difficult. For example, requests could be done through some external libraries. Which would require hacking that library to count them. In addition, we would have to ensure that app would submit the counts. As target is open source, it would also require that the app code responsible for counting has not been commented out by user. Or did I misunderstand your proposal? |
|
No, I think you got it right. But I think that the counting would be in the responsibility of the developer. For example it would be in your interest, that frequently use of PureMaps would be more expensive than just occasionally use. (Or you think the usage should just be averaged for all users. Then my proposal is unnecessary. ) |
|
Ideally, we would provide each user a unique API key for the service that would be expired in few hours. Then we would be able to link the usage for that particular key and user through the provider. Some providers do allow you to generate and remove API keys. Haven't tried to do so, but see for example https://docs.stadiamaps.com/client-api/ . However, such scheme may not work for every service. |
This would make it a literal peer ;) But I think it creates a lot more complexity off the go. In terms of innovating in the api space, it's probably a great idea. If one has the capital ;) I'd like to avoid doing ANY identity capture and counting at all. But, one way or the other, we have a chicken and egg problem. In many cases we're going to need seed capital before we have any donations/payments. Waiting for payments to 'trickle in' would just lead to frustration for people who do make a proper donation. I'm thinking of this have a 'donation drive' recurring event as part of it's long term financial planning. It's often the case that if you do fund raising in this way, you'll get disparate donations. Some people will donate much more than they use and some people less. That complicates matters from the organization vantage point, but I'd like to discuss this with the Sailmates! The question is how to start at all without it immediately being a 'storefront'. I think in the context of the grant application, we can make it a budget point if we start with a single use case / api like mapbox. So we'd have, say, 6 months of api use paid up front and a window of time to measure how many people actually chose to pay. Using a transparent payment processor like opencollective one could simply instruct users to do nothing more than post the token as 'payment purpose' and that would give us the basis for evaluating. But this is speculation. I don't know to what extent solutions can be developed with the providers that exist without going through the usual identiy confirmation stuff that'd I'd like to avoid. Part of the proposal is to explore that with, for instance, open collective. |
|
To avoid chicken and egg issue, we can start with services that are pay-as-you-go. Those include Mapbox, HERE. We can later expand with the cheap services that have monthly fee and later charge for extra calls, as Stadia Maps. If we start with such services, we can, in principle, start quite early with few donations (I presume we can target as low as 10). However, it would require that we have some automatic monitoring of current expenses and mechanism to revoke keys when the collective funds are used up. If we would have to write programs for such monitoring anyway then we can already expand it by recycling API keys as well. That would allow some stats in terms of calls per active user and can be used to evaluate each user contribution to API calls. As for identity capture - not sure I follow. The contract with service provider is done by keypeer and that would be as far as identity of the user is "captured". On keypeer side, if users are making payment via opencollective, then user's token is something that can be used. Note that the token would have to somehow generated from user's secret (API key?) and some keypeer secret. That way we can have published token and keep user access to keypeer secure. Not sure I responded to all your concerns, let me know if I missed something. |
|
I had looked at the Mapbox payment Tiers and wasn't entirely sure what we'd need. So it would be helpful for you to expand on which services / apis we would need. I only vaguely remember you mentioning hitting limits but wasn't sure how many calls on which endpoints?
I'm thinking that this becomes really tricky and will end up requiring a lot of 'grey area' heuristics depending on the number and types of apis we serve. But I'm thinking about it ....
What you suggest in the second paragraph is what I meant by an 'application instance token'. Any app using keypeer would:
The problem with this idea, among others, is that it does not account for users who use the same service on multiple devices, for instance. Finally, as for the legal entity that makes the contracts, that's a bit tricky from the start. Although the pay-as-you-go models might be ideal from one perspective, for the vantage of the 'sponsoring' society, if the sailmates take on that role, it might be better to limit this. I'm just being cautious, though. |
Services:
For Pure Maps, I would need:
That could be expanded by other services, such as HERE. But let's focus, as for example, on those ones. Automatic monitoring:
Well, not sure it is that difficult if they have API to be able to monitor the calls. As we can limit supported services to the ones that do support such monitoring, it should be OK. In the end, I expect that we can write such code and it would be relatively straightforward. As it is an important project, we can also ask for help from others, including other mobile Linux developers. TokensNo, I wasn't suggesting application instance token. Scheme that I was proposing would be as follows:
As you can see, the mechanism is just requiring user API key and payment TOKEN which will be the same for all apps and devices. Legal and pay-as-you-goAgain, we can hit the breaks if we monitor the use via cron jobs and disable API calls as soon as limits are reached. It would have to be somehow specified in the agreement with the users, but should be possible. Side note: I expect that map service companies would be interested in keypeer. So, we can contact the sales departments and discuss what can be done on their side. All in all, I wonder whether it all is covered as "donation" by users and could be considered as a "sale". Which, I suspect, brings different framework to work with. |
|
Thanks for clarifying which mapping apis for round one!
In view of the very different requirements that mapbox / tiler and stadia impose, that's what I mean by 'tricky'. The programming, per se, is not what I'm talking about. It's a question of implementing monitoring depending on a matrix of some complexity. But that's not a show stopper. Just a consideration. Most of the apis I'm currently interested in are 'primitive' in comparison (ie. after developer tier, it's just XX dollars per YY number of requests).
This is just a 'gut feeling' response. I'm thinking about it in the meantime. Ok, this is exactly what I've been trying to avoid :) Already the burden of keeping payment information synched with token/user identity will impose hard legal requirements which, in effect, require a legal structure like a 'non-liable'. It wouldn't really work with a Verein like Sailmates, since in the context of a Verein, the liability ends up with the members. I think you are underestimating the legal requirements. I'm trying to keep the central service out of the payment system loop as much as possible to keep all of that liability with the payment provider. The worst case scenario, for the developer, is that funds have to be 'manually' transferred to them for paying a third party. But that could be done 'by hand' and in the case of open collective, transparently. But this manual intervention is probably inevitable in any early stage. But that isn't a hard criticism of the Token workflow, per se.
Ok, this points up 2 things we need to address:
|
|
Re tokens. If we want to use OpenCollective information that is public, the only way to generate secure token is to use some secret that keypeer can rely upon during the check of payment status. Note that apps are distributed in open source code form and it is impossible, for many distributions, to include secrets into compiled apps. So, when choosing a security schema, you have to take into account that apps should work with fully transparent code. As a result of such constrains, I don't really see how we can avoid providing keypeer API access key and public token via keypeer itself.
Problem is that contract with the service will be through keypeer. Or can OpenCollective take that part?
Re 2 I asked earlier MapTiler. Specifically, if they would be interested in charging users directly. For them, it was interesting as a revenue increase, but would require setup that is non-trivial. However, we started discussing it. Sticky point was estimation of number of users and how much they want to pay. In the end, we suspected that the numbers will be too low to start it. While it failed with MapTiler, I think they would be interested in adjusting their invoicing and API key access monitoring to make it possible for keypeer to provide such service. At least that is my feeling - especially if we ask for some specific and simple scheme. Whether larger providers will do the same, no idea. Re 1: No idea. I wonder if OpenCollective would be signing agreement with service providers. But I don't think so, unless we try to get keypeer functionality into them directly. Re monitoring: Those payment schemes with offsets (as Stadia), those are more difficult, indeed. As you have to divide that offset among all the users. As for Mapbox, you can always start with the maximal price per call and, at the end of the payment period, make correction based on the real invoice. Re manual payment: yes, I am afraid that this would be manual for a while. Unless they can invoice it in a way that the bank / OpenCollective would pay automatically. |
I hadn't gotten to the question of homomorphic encryption yet. My hope is to rope rubdos into making this a demonstration of operating on encrypted data without decrypting :) The first obstacle with a homomorphic scheme is that it offloads too much work on the developer. A more traditional scheme as you suggest is probably inevitable but that's part of the aim of applying for funding. Examine what's possible.
The main thing I was trying to avoid is having to take end user payments directly. Not necessarily making payments :) I was imaging that the payments are collected by something like open collective to a co-op / company that pays out on behalf of the keypeer service. But that requires some legal advice.
Open questions. Opencollective is not going to enter into thridparty contracts. The question is can it even support automated api requests. I actually don't think so, but haven't gotten answers to a number of my questions yet.
Ok, but this is good to know and then one of the stated purposes of applying for funding is to gather what kind of participation we can encourage / expect. And under what conditions. How do we need to promote the effort to get as many people on board as possible.
Ok, it's a good starting point to have. Just getting into a discussion with a provider is a +++
There's certainly going to need to be a legal entity behind keypeer. Just to start now, I'd asked the Sailmates if they could imagine getting behind the effort. But it would have to become a separate legal entity in the long term just to deal with financial liabilities.
I was trying to make some rough calculations but failed to get a sense of it. I had an impression that we would be breaking the 1000 Euro a month limit with mapbox at peak times in the summer, but that's just back of the napkin. You had some numbers, didn't you?
Yeah, it's not such a big deal initially. |
Just to re-iterate that I do think your right that this would be ideal. I'm going to extract this as an actual to-do. Find out who supports this and start a list. |
|
Re encryption and developer costs: Let's try to keep it as simple for developers as possible, please. Re automated requests by OpenCollective: In principle, email or some secure message with the payment information is sufficient. Don't think we need to constantly check the status. Instead, it would make sense to build local DB and check the records against that. Re legal advice: agreed, that's needed. Anyone able to provide it taking into account the intentions of the project? Re legal entity: indeed, it probably would have to become separate entity. Which is OK, I think. Re calculations: I propose to do calculations per user. If I take most expensive brackets in HERE and Mapbox, I would have used 2.4 EUR during one year. That's based on API calls using my personal API keys. For other providers, I have only all users stats which is harder to decipher, but I expect those to be cheaper. I am not most active user, I think. Also having offline maps help as well. But, that's roughly a sum we are talking about per user. Now, when you take the napkin, use 1-2 EUR per month per user and I expect you would overestimate. But it also tells me that we are on relatively low price point that should allow it to scale. Now we would have to add operational costs - running a server (cloud, I presume), backups and so on. |
Absolutely. The homomorphic scheme for at rest storage I'm considering could also be done server side only. ON all the other points, noted. I'll try to work out a budget document which is needed for funding anyway and coordinate with sailmates to look at organizational challenges. As for question of server, everyone does cloud. Let's go bare metal. |
|
Excellent! Thanks for working on it. Re bare metal: If not a joke - why would you do that? I guess solution shouldn't depend on that, but should be able to provide low down-times |
|
Bare metal was a light joke ;) I'm not such a 'cloud' fan although I've built one (openstack, early days).... I have some experience, but would prefer to rent a machine. Although, I have machines, so that's not an issue. The question is how to make it maintainable for others. I'm asking the Sailmates for input on that point too..... |
In the current form, I don't see how would user's contribution expire. Ideally, we should link user's requests to user's account. It is possible probably for some services where we can request as many API keys as we have users and later request usage info for each API key separately. There is an issue regarding "overflow" - use of calls a bit more than was payed for - but that is probably minor.
There maybe a way to use frequently API keys for services that don't have such granularity and then ask for report for each active key. And then divide equally between all currently active users for that key.
You suggested some other scheme while we discussed it at FSO - simpler. But I don't remember the details. Or maybe it had no "expiry" mechanism.
The text was updated successfully, but these errors were encountered: