Decide on how to link expences to donations

[rinigus]

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.

[poetaster]

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.

[yajo10]

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.

[rinigus]

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.

[yajo10]

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.

[rinigus]

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?

[yajo10]

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. )
To be honest, the possibility of abuse exists even in the initial concept. I can dump somehow the API key and use it on another device or share it with other users (because the app is open source).

[rinigus]

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.

[poetaster]

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.

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.

[rinigus]

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.

[poetaster]

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?

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.

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 ....

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.

What you suggest in the second paragraph is what I meant by an 'application instance token'. Any app using keypeer would:

1. receive a unique id (uuid?) which
2. combined with an instance uuid (generated in app on user device).
3. gives us a user / instance specific id

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.

[rinigus]

Services:

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?

For Pure Maps, I would need:

• Vector tiles:
  • Mapbox vector tiles API https://www.mapbox.com/pricing#vector-tiles-api
  • Alternative to them is MapTiler (Flex): https://www.maptiler.com/cloud/pricing/
• Routing:
  • Stadiamaps (Starter): https://stadiamaps.com/pricing/

That could be expanded by other services, such as HERE. But let's focus, as for example, on those ones.

Automatic monitoring:

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 ....

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.

Tokens

No, I wasn't suggesting application instance token. Scheme that I was proposing would be as follows:

1. User clicks on "Subscribe" button
2. Keypeer would generate random API key that user is expected to keep as it's ID and password.
3. Keypeer would use its secret crypto signature and sign API key to create user's TOKEN
4. User would use TOKEN and label his/her payment
5. User would use keypeer API key in the application for requesting services API keys served by keypeer
6. To check payment status, keypeer would again sign received API key and compare with payed tokens

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-go

Again, 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.

[poetaster]

Thanks for clarifying which mapping apis for round one!

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.

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).

Tokens

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.

Legal and pay-as-you-go

Ok, this points up 2 things we need to address:

1. How / if will payment providers want to cooperate with this effort
2. How /if will api providers want to support / cooperate with this effort.
   In view of the legal questions that pop up when dealing with user data / financial transactions, we'd need to address these points first.

[rinigus]

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.

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.

Problem is that contract with the service will be through keypeer. Or can OpenCollective take that part?

1. How / if will payment providers want to cooperate with this effort
2. How /if will api providers want to support / cooperate with this effort.

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.