Third party API keys and keypeer

Applications
#1

As some of you might have gathered, instigated by the needs of the mapping clients and @rinigus we’re working on a transparent api proxy, a service to help fund the use of third party apis in FOSS. Initial project information at: https://keypeer.org (or github!). The Sailmates have signalled a willingness to support / host the project and we’re applying for funding. It’ll get built, like it or not.

If you are responsible for an app that requires a third party API we’d be very happy to here from you!

8 Likes
Pure Maps (Native map app)
#2

@karry if you have some time, maybe you have some input on the maps front?

#3

Not much feedback from the community. Pity.

I have looked for online TTS services, but those are proprietary. It would probably not be great to include proprietary ones as examples for a grant application that should promote open source software. However, one can argue that having a money stream established, it will be possible for companies like Mycroft to work on TTS and publish services using more complicated models than the ones designed for embedded devices.

But let me reiterate the original request:

  • developers and users, think what can you do if you will be able to use payed online services.
  • having good use cases would be great to expand the scope of the application

Deadline is coming up very soon, so not much time wait for the response.

#4

As a +/- basic user, I don’t understand how I could help here, despite my good will.
I am sorry not feeling able to understand what is asked here.
Proxy, Api, payed online services?
I don’t understand what all this would/could concretely represent in my use of SFOS.
Maybe some examples for simple users would help me help you :slight_smile:
Thanks

1 Like
#5

Thinking about things available on private platforms, I’m wondering about traffic data. Are there paying services that provide these kind of data ? Because that’s surely something convenient to have when planning an itinary. But I must say that I didn’t search for such providers.

I’m wondering how Google for instance can have access to very local traffic congestion on secondary if not tertiary roads. Is it syphoning GPS position of (all) Android phones and comparing average speed at position with theoretical speed at position ? But that’s off-topic.

Anyway, if such data exist and can be “purchased”, that can also be an example.

#6

I don’t feel like companies would allow using their api in a community manner. So building an app around that bears the risk of being taken down.

#7

They might not be too keen on apps sharing them perhaps… But if it is just a simple way to pay for or paywall them, what would be the problem?

#8

Traffic is a part of maps offers. For example, in Pure Maps, if you are on HERE platform then it is already using traffic data to calculate the route. Same can be done for Mapbox and some others.

How traffic data is collected probably depends on the service.

1 Like
#9

I don’t think that such sharing of the keys between keypeer (that has “app” registered with the service providers) and users is that much different from a regular use by app with the key in that app. But we would have to get in touch with the service providers and clarify if it is allowed. I am sure that the smaller ones will even be flexible to change their conditions if we can get the users to pay for the service. In principle, whole idea is to allow users to pay for the service. Which benefits the both sides - users and services.

#10

The first application is out now. Fingers crossed. We have more time to apply for https://prototypefund.de/ so feedback is still welcome.

2 Likes
#11

Hi @poetaster and @rinigus . I just read basic ideas and protocol proposal on keypeer.org website. It is nice idea. I just worry about costs (developer time and infrastructure) of running of this proxy service.

Where you are running your backends? Some public cloud, own hardware, or vps?
I’m not so familiar with zero-knowledge protocol, do you will be able to track api usage of individual users? Soon or later you will need to make sure that some user do not exceed quotas.
How hard is to integrated new api service? Do you have proxy instance per api service?

Anyway, I wish you good luck and looking forward for the results!

#12

Hi! I’ve applied to nlnet and am working on prototypefund next to try to get the initial work funded. The Sailmates are willing to put in some time or help organize support.

To start, I have a fair amount of dedicated metal that’s just gathering dust at the moment (https://www.hetzner.com/de/dedicated-rootserver/ax61-nvme with extra IPv4s).

The zero knowledge proof idea came from @rubdos who has done some academic work in that direction. Yes, it would permit us to do some accounting. It just limits what you need to expose and still determine if facts are ‘true’. But, I have no idea if I’m just being naive :slight_smile:

I would say it will be easy, but it depends on us having the requirements cover ‘modalities’ at the outset. Obviously there are accounting issues with individual use and apis having different metrics. But, if we get the design right, I don’t see that it should be complicated to use.

Might be a good idea to make it easier to keep track of which apis cause traffic. Now we’re on to design ideas …

#13

@karry: right now, it is mainly in the concept stage. We haven’t started properly discussing a design. Currently we are mainly waiting for grant decision.

Re zero-knowledge: I have no knowledge regarding it (in full harmony with the zero in the concept). Have some simpler ideas on accounting, but let’s see what we will choose in the end.

Re tracking usage: some APIs allow you to make as many keys as you need. So, we could assign every user one key and account using that. If impossible, we can probably make record then with allocating the keys to groups of users depending on time window. So, we can get an estimate of API usage.

Re integration: probably each service will require some specific solution on the backend. I presume that after few of them are done and tested, adding the new ones will be easier. So, it is probably major work required on getting it running with couple of services. On app side, it should be trivial - at least that is the target for us.

Re proxy: I think we cannot have any proxy between app and the service (like maps client and Mapbox, for example). there are privacy implications and it could be prohibited by services as well (not sure in the latter).

#14

I’m not sure that’s what @karry meant? I think he meant a proxy against keypeer for each different api service. so, mapbox.keypeer.org or newsapi.keypeer.org ? or?

#15

mapbox.keypeer.org can be instead

keypeer.org/api?keytype=mapbox …

#16

There are other reasons for sub-domains… Sharding of requests. Migrating particular API instances to dedicated hardware under load, etc, etc. Still not sure what @karry meant, though :slight_smile:

As for api shape, I’d probably go for something like REST like: /api/providers/{ID} with GET/PUT,DELETE, etc. But I’m just noodling in public.

#17

I thought that applications will have no access to the api keys of third party api’s, right? So, for every service you will need to have some “proxy” service that validates keypeer credentials and proxy http request to provider with his api key… Right?

#18

No, that is not the intention. The idea is for any app to request the api key from keypeer and use the 3rd party service directly. Reason is so far I understood: privacy. And providing such a proxy probably would need way more efforts.

#19

As yajo10 states, no. The apps would obtain a key, ephemeral or not, depending on the api. Whether keys are distributed with an app (ie. developer has a subscription and bakes the key into the app) or obtained by the app should not be of consequence. It does require a rotation scheme which complicates accounting, but that should be about it.

#20

@poetaster: Idea is to get rid of API keys baked into the app :slight_smile: . User will have a key that will be used to request API keys by apps via some protocol. So, your app code will have to add that request for API key and watch for that key expiry.