I'm really looking forward to that. I use something I cobbled together for password management that's completely backed by KBFS [Passbase] and I haven't worked on it much, but the main gripe I have is the difficulty in using my passwords in Android apps. Web apps are fine, Chrome syncs the password so I just login once from a computer, but any app is a painful `passbase read appname > /Drive/tmp.txt` and open-copy-switchapp-paste experience via Google Drive.
That's a long introductory way of saying: KBFS on phones will be fantastic - but I've long intended to move my (pretty much personal use only, but still) app to using a database rather than raw files, so is there any plan for programmatic access to KBFS for other apps? I realise there are non-trivial issues concerning permissions there, but it could be really great - perhaps silo other apps from full access, e.g. 'App is requesting access to KBFS/Appname, approve?' and 'App is requesting access to KBFS/none-of-its-business, approve?'?
[Passbase]: https://github.com/OJFord/passbase
Alternatively, have you considered implementing an input method provider as the means of inputting passwords into your apps? I know that on Android you can create your own input method apps. I think on iOS you will need to jailbreak the device and even then I don't know if you can make your own input method app for it.
I am imagining that the input method shows you your list of credentials and allows you to select from it.
Yep, that would be ideal :)
I'd like to use KBFS' multiparty private storage for shared passwords too though, which I think would be far easier to implement with a proper DB than text files.
The issue then is that if KBFS just comes as an 'explorer' view within Keybase app, I wrote have no way to copy a password for use. Hopefully cross-app access or a fully mounted drive is on the cards though.
This means I have to wipe it when crossing borders.
Will doing so pollute my graph with lots and lots of device keys?
Not the end of the world, but I take it this particular UX is a work on progress.
> This rule got so much press 7 years ago that it will be one of those "truths" about a platform that never dies on internet forums, that and the Playstation platforms using OpenGL as their primary API...
https://itunes.apple.com/us/app/ivy-big-number-calculator/id...
It's true that fork() isn't allowed on non-jailbroken phones, so you can't shell out to a Go binary (you can on Android if you want). But you can build a static library in Go and link it and call into it with cgo from Objective-C or something.
https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitc...
Unless devs are given the option to test the final binary, it's delivering untested binaries to users, and as such should be a no go.
Last night I was pleasantly surprised to discover it is in the FreeBSD repository as well. I really like what you all are doing.
How about Chromebooks?
I've been evangelizing keybase for a while now and was checking almost every week for info on an Android app, but this 'existence' by way of a React app is a huge disappointment. Without a simple, lightweight, native app, it is very difficult to do verified builds and engage community contributions. I sincerely hope there are plans in place for a real Android app; I would happily contribute in any capacity I could.
There are still some things missing from the app, such as the ability to browse your encrypted files (KBFS), although the app actually has KBFS running inside it. So we're close on that front. Also, provisioning is still a bit clunky.
Possibly interesting to HN: Keybase is one of the only large apps we know of which exists on all 5 platforms (iOS, Android, macOS, Linux, and Windows) and which was programmed almost entirely in Go. Except for the chrome, which is react/react native. Source code for all platforms at https://github.com/keybase/client
If you're an HN user and give it a try, please send us feedback. It's `Gear Icon > Feedback`. We read all the feedback.