Distinguish feature set for open source and solana mobile variant.
Closed this issue · 7 comments
I really think we need to define what we mean by the Solana Mobile "variant". I think it's a bad look if we have a private fork with significant different functionality.
Our goal should be to protect API/key secrets, no more, no less. I feel like that should be mostly possible with a fully open code base, but maybe not. I feel like a more representative ticket would be around investigating key projection.
Thoughts @Funkatronics @sdlaver @oliveeyay
One idea: What about a private sub-repository?
That contains all the private keys / infos needed to build the Solana Mobile variant (even gradle confs) and is linked to our main gradle confs. If it doesn't exist, it defaults to the public variant.
Nice, I like that idea. We' could just use the interface/gradle config operation like in dapp store right?
If the goal is to keep secrets secret, they can be included using GitHub Actions secrets at build time. However, they still end up in the APK, and can be trivially extracted from it.
The only way to keep an API key completely secret is for it to never be on the client in the first place. As an example, a web server hits the RPC node on behalf of the client, and returns app-specific responses to be processed by the client for display purposes. This is the difference between the open-source and production versions of Minty-Fresh that I had in mind - the open-source version exists to serve as an example of how to build a client-only app that interacts with the chain. The production version uses an intermediate backend to handle the relevant data fetch from RPC. This way, the RPC (which is the scarce resource to protect) cannot be hijacked for non-Minty-Fresh use.
Yeah for the API protection, there's probably no other way.
We could still isolate the client-side server API logic into a submodule. That plus obfuscation plus maybe a nonce exchange between the server and the application (based on the application signature) could slow down attackers?
Otherwise, people could replay the server's requests if it's too public.
Or we would need an authentication mechanism on our server (wallet+civic or email+password?) 🤔
Ankur and I were talking, and we're going to try and manage a private fork of MintyFresh with some alternate implementations of the interface.