Hey, I’ve worked a fair bit with AI in my remoteStorage apps, but since the very beginning I had to write my plain API key into my remoteStorage data. This means any app with read access could steal my API key.
The ideal solution would be to let apps request AI usage at the moment of authentication with remoteStorage, and the user should be able to answer the request with the number of tokens the app may spend.
Technically, this would work as an AI proxy on the remoteStorage server. During the OAuth flow, the app requests an AI scope, and the user determines how many tokens to grant. The user sees this alongside the usual permissions and approves a token budget. The app then sends AI requests to a new endpoint on the remoteStorage server using its existing bearer token. The server holds the real API key, checks the remaining budget, proxies the request to the AI provider, and returns the response. The app never touches the key.
This would let people have one unified and easy place to manage their AI from. In many cases I saw myself forced to create my own backend or having to think about possibilities of subscription models to let users of my apps have AI features.
I’d love to hear thoughts. It definitely still needs some thought, i.e. what if some user would like to use a locally hosted provider like Ollama but hosts on 5apps? Or what if one model is more expensive than the other — should a budget in monetary value be given?
The question is about you as an app developer offering AI features in your RS apps to users, without hosting your own back-end, correct?
I think this is more of a general question about unhosted apps than it is about mixing non-storage functionality into RS server software.
The storage should probably only save bookmarks for configured services and maybe AI-related preferences, perhaps in a standardized data module that other apps can re-use.
Since none of the big providers allow per-user OAuth for their LLM APIs, I think the only viable solutions today are:
Let users configure their own AI provider API keys (put in localStorage/IndexedDB, not synced to RS)
Let users configure a local API; you can likely add some presets for common ones
If they were synced, then people have to paste their API key everywhere manually. This is what I’m trying to avoid as you’d have to do this for every app.
If users had a local API it would be the ideal situation, but even then it would be nice if the API endpoint and model where configured once by the user.
Maybe something like a secure API Key storage would be a nice addition? Where RemoteStorage acts as a proxy to store not necessarily AI API keys?
It’s about letting remoteStorage use OAuth Token Exchange to hold keys and hand apps delegated tokens instead (so the app never sees the real key).
So it seems like this could apply to the problem you’re describing, hopefully the proposal gets some traction as I think it can be very useful in many ways.
This could be accomplished all in-client using postMessage without changing the remoteStorage server protocol.
You create a privileged app “keyholder.5apps.com”. This is where the user adds/manages their API keys. It writes keys to the user’s remoteStorage (but not to a location that other apps are expected to ask for and to be granted read permissions to).
Any app that wants to make requests that consumes the user’s token budget is expected to embed the keyholder app via iframe and postMessage requests to it. The keyholder determines whether to translate these into fetch/XHR requests, filling in the API key as appropriate before relaying back the response (also via postMessage).
No proxy. No additions to the server protocol. No AI-specific functionality that remoteStorage providers would have to implement. Just a simple embedded widget that manages its own secrets and communicates to clients through postMessage.
Wow, this idea is blowing my mind, I never thought about iFrames this way!
It also seems like Android could also work in a similar way, with a keyholder app as a middleman. Only for iOS I haven’t found a solution on first glance yet.
The next problem on my mind would be: How can a teacher in a school scenario share AI access with his students.
We can assume that it’s okay to give users a public link with a unique id, as secrets could be encrypted in some way.
Ideally students could use the AI at home, as long as the endpoint of the AI is in reach.
The teacher should not have to manually create the API Keys for every student.
There’s no way to do this while maintaining the secrecy of the key, since the requests are still ultimately going to originate on the user’s device—unless the teacher is advised to leave his or her machine running to key the requests on students’ behalf and the app provides some way to relay them to the original requestors by some unspecified means (WebRTC? XMPP-over-remoteStorage?)
I don’t think this is a good enough use case to make extensive changes to the remoteStorage contract that providers are expected to adhere to. It would make more sense to leave this up to the app deployment platform as a nice value-add (a lot like the way 5apps.com provides a proxy to get around CORS restrictions) or have the creator of the app set up a supplemental request-signing-and-relaying function on some popular platform for hosting workers.
