Allow user to export the keys for a single address and the associated private keys for that address.
It occurs to me that with all the node and client code written in java already, making an android app might be pretty simple
Yes!
If we know anyone competent, I'd be inclinded to hire an android dev
I am setting up the android dev environment and will give it a try
if the UI library isn't incomprehensible i might be able to just nightmare it up
ok, the hard thing is of course the build dependencies
it might just work sticking this jar file there
heh
i held a cto hat in a mobile games company for a few years, but i only work for fiat on stuff like that and you’ll have to form a legal entity first, and we’ll sign papers - if that is to be - but FYI, i’ve got time in october-november
I have several legal entities :wink:
but for snow tips i can help wrap the core into a state on top of which ~any kid can do react native
a full mobile app is about a 200h project all in all
I am going to smash my face on it a little. What I am looking for is pretty basic.
there’s a few gotchas on android for you with the SDK versioning and chip native crypto, when going for polish
If I can reuse all the existing java library and if the UI modules don't trip me up too hard, I have high hopes of having something basic and workable in 20h or so
yeah, if the bouncy castle library works on android is a big question
IIRC you had a thin wallet plan?
currently SnowBlossomClient just connects to a full node, we currently tell people to run their own but that isn't strictly needed
I can have it hit one of my seed nodes, at a privacy cost of course, but keeps it simple
i’m also cursed with being able to run java on ios and obj-c on android, did porting heavy lifting way back when
I could in fact run a full node on android. That would be kinda funny for the headline if nothing else.
most people struggle with internet quality and phone storage
not fair to the world at large
sure. Looking a 1.6gb already, probably more if we have to use lobstack, which almost certainly would
I could do the pruning work and quick prune sync...
rocksdb runs with scissors from version to version so not too polite to go with that
basically current utxo only database
right, I would never trust rocksdb with wallet
always fun to decide between addressing a CVE and breaking data
but for a node you can resync on failure, so whatever
human readable text is for wallets, yeah
don't quite have that, single protobuf messages rather than a db
but do have the export to plain text at least
fair enough, not home cooked schemaless-on-experimental
yeah, no minecraft map file format here
mobiles have sqlite natively, but REALM is a thing i recommend you look at for future proofing mobile
future proofing as in reusable-for-ios
The issue I seem to be hitting is that these frameworks try to insulate people from writing in java, and I want to write it in java
It would be great to have IOS support as well though
I'm hoping on these default app setups will allow me to just define some tabs or tab equivalents and just let me dump some text and maybe a few buttons in each.
The hard parts will be QR code camera integration and some sort of reasonable export backup file to something
well, you only really want to provide an in-app TCP api, aka. the RPC, which you already have anyway
then let the frontendy people do their thing
and qr code reading is relatively easy, actually
if you're willing to bar anyone with play services older than 7.8, that is (from 2015, as in probably in phones from 2016 and newer)
from your point of view, it's just a sync call, which returns a string
you can do it async, but no need to, as the camera ui is on top of your now frozen ui, so that's fine
and you can just register a callback, or go all fancy with manager threads and services
Sync is perfect for this