About 4 years ago I was involved with a commercial software project attempting to do exactly this. What we built worked but it wasn't positioned in a way that interested our target audience (Enterprise customers).
First, bravo for making it happen in a way that is getting people excited. Second, I sincerely wish you the best luck in getting people to pay for it in a way that is sustainable for a business. We built a user interface that made truly secure group file sharing accessible to mere mortals and said mortals were uninterested.
About three months after we shut down the business Edward Snowden made his infamous leak(s) and it became obvious to me that commercial crypto products coming out of the United States would be met with extreme levels of skepticism for some time to come. Any remotely centralized solution to the problems of key distribution and encryption are probably dead on arrival because of the single point of jurisdiction/political failure. It really doesn't matter how open you are (unfortunately).
Two things really stand out to me about this implementation. 1) The trustworthiness of the key exchange doesn't appear to employ a mechanism that protects against a man in the middle. 2) They mention the possibility of in-browser Javascript crypto. These are not small issues. The people who need crypto require rigid, durable implementations that don't gloss over security concerns in favor of usability. Everyone else is just being trendy.
They do specifically mention the problem of javascript crypto. They also mention the fact they want to be mirrored.
That said, I don't actually know enough to make smart decisions in this space. But I'd be interested in your thoughts after reading the docs (if you haven't already).
I don't think Keybase is glossing over security at all.
First of all, you don't have to use the browser app at all. I personally don't trust Javascript crypto and hence don't do anything in the web app.
They're also acutely aware of the dangers of centralization and all the Keybase crypto is based on minimal trust. Check the documentation: https://keybase.io/docs/server_security
Personally, I don't want someone else storing my private keys; which is a pre-condition for doing anything you'd have to worry about in the browser anyway.
So do I - that was my point to parent: I don't use the browser tools not because of JS (which is a concern) but because of not wanting private keys stored online which would be required to do so.
I think they know what they're doing. The article seems pretty thorough and they're open to feedback. It looks like they've thought of most things but are still able to keep it usable, engaging and at times even humorous (https://keybase.pub/chris/lemon_party.jpg). These are things often missing from security products.
P.S. If anyone wants an invite then details are in my profile.
I think it's more than just being trendy; there's a range of security needs to be considered.
I'd be happy to go with something that has more crypto than Dropbox but stop short of full tinfoil hat. Consider FileVault on Mac OS. You flip the switch and you're done. If someone steals your laptop they are unlikely to be able to access your files. Win. Will it stop a dedicated hacker or NSA (or even a court order compelling you to decrypt your computer)? Nope.
Could someone with more expertise explain how Keybase protects against MitM attacks please? Does it simply rely on the difficulty of compromising the SSL certs of multiple assertions (twitter.com, github.com, etc)?
As far as I can tell, if someone was able to 'pretend' to be Twitter, ie, MitM an HTTPS connection to twitter.com, they could 'pretend' to be someone who only has their Keybase info on Twitter. Of course, putting your key data in more places makes it harder to appear as you.
1) MitM on TLS requires being able to issue trusted certificates for any domain. That means you either own an already trusted certificate (which basically means you're a state-level actor), or you can install a certificate on the victim's device (which means you have physical access/ownership of the device). It's also detectable through certificate pinning.
2) In Keybase, if you 'track' someone, you sign the assertions they've made as of today. So in the future you (or anyone else -- tracking is public) can detect if those assertions have changed since you first started tracking them.
I've been using this for a couple weeks. Along with Zcash, it is the most amazing crypto-engineering project I've seen in years.
Imagine being able to share files on an ad hoc basis with anyone -- on any network. Share with someone based on Twitter, on Facebook, or email address.
Even better, all with cryptographic proofs of identity, strong crypto at every level, and open source.
Came here to say pretty much the same thing. It's slick and easy to use. It's actually the 'dropbox' I've always wanted and if they introduce a storage limit I'd pay.
What's also impressive is doing away with Dropbox's clunky "selective sync". While having everything stored locally sounds like a good idea at first, as you store more and more data is gets less and less user-friendly; in other words, power-users get the worst user experience.
Additionally, creating an easy way to share files with friends without taking up their quota is awesome. This looks like it could be a very, very powerful competitor to Dropbox.
Not storing files locally sounds like a good idea at first - you don't have any syncing issues. But nobody has a perfect always-on internet connection. Having files local is worth the occasional sync cockup.
Oh for sure there's a reason that approach is dropbox's default - its really hard for people to understand their files aren't really "there".
That said, my point is more that for people who start storing 100GB+ of data, it becomes harder and harder to actually manage which bits you want at any time.
>There is no paid upgrade currently. The 10GB free accounts will stay free, but we'll likely offer paid storage for people who want to store more data.
Dropbox works with the NSA to hand over customer data. You are absolutely right that something like this would go over like a turd in a punchbowl at Dropbox HQ.
Unlike Google, Microsoft and Slack, Dropbox does have the top, 5 star, EFF rating for protecting your data from the government... I'm not sure what more they could be doing.
Their profitability depends on being able to dedupe and compress data across all customers. They would need to raise prices significantly to make client side encryption a built in feature.
Then use tarsnap already. Bonus: it is owned by our own cperciva.
tarsnap is nerdish, secure and reasonably priced for what it provides IIRC. Haven't used it though but expect someone would have yelled out here if it was bad. (In fact the only one I've seen bashing it was patio11, -because it was too cheap and too nerdish.)
I don't think it's distributed in the IPFS fashion, right?
Which makes sense, of course, since Keybase is a funded startup that needs to capture value... and, well, centralized file sharing is a more straightforward solution, too.
The file system thing seems really cool and useful. I'm a fan of Keybase and will recommend this to people with whom I need to share sensitive data.
It'd be interesting to hear the Keybase people talk openly about how they see their role as both infrastructure providers for an open web of trust, and an economic entity that requires for its survival some degree of lock-in and centralization.
IPFS alone is usable for the public web, but is not usable for private sharing. You need a social identity-oriented public key infrastructure with a good UI. That is Keybase, and it's incredible that we have this now. Sure, we should implement an IPFS backend for the storage part. But let's not neglect the huge progress the Keybase folks have given us.
Well, what I'm hoping for from Keybase is enough user friendly tooling to encourage a lot of people to start using public-key cryptography. I don't see IPFS as really addressing any of that, even though it is extremely cool and valuable in other ways.
I love the ideas behind IPFS, but it isn't even trying to solve the same problems as KeyBase, so comparing them like this is very silly. Users may be able to benefit from both in different ways, or even use parts of the two together in the future.
I'm not speaking for Keybase, but their approach so far is to fill these roles in compatible ways.
As an infrastructure provider, they open source the client software and design it to trust the server as little as possible. They also endeavor to document the behavior of the server so that, in theory, you could build your own Keybase-compatible server.
As an economic entity, they're positioned to tackle the issues that open source projects usually face, like support, development resources, UI design resources, and "where do you put all of this encrypted data" by getting their most needy users (mostly businesses) to pay them.
The second part is usually handled by encrypting a randomly chosen symmetric cipher key using each public key, and then encrypting the file with a symmetric cipher. And I believe keybase was founded to tackle the first problem.
Zcash is an actually anonymous cryptocurrency (BitCoin is not, since senders and receivers are public). The crypto is definitely impressive (which it is, it uses zero knowledge proofs -- which are really cool math -- for a lot of its sending operations).
I managed to find the prerelease packages in the build scripts, and got it working through that. Make sure you restart the keybase service, as it doesn't happen automatically
> We're a long way off from worrying about this, but we'll
> never run an ad-supported business again. And Keybase will
> never sell data.
> [....]
> But, as stated above, there is currently no pay model, and we're not trying to make money.
> We're testing a product right now, and we'd like to bring public keys to the masses.
I know a lot of people will see this as a pro, but honestly I see it as a huge negative. Raising capital doesn't mean that you "are not trying to make money". If you are not trying to make money, then you can't call it a "product".
This is my biggest worry about using this service. It looks great, but if they don't make any money, how can they keep it running for free in the long term? They should charge users money for storage, not give it away for free - hopefully they have a plan to do so soon but they should make that clear.
It would also be nice to be able to completely self-host, that would be really reassuring, not sure if it is possible but they could certainly sell that as a service and support it for businesses interested in running their own keyserver and encrypted file store.
Totally agree. I don't want to invest my time using a service that I don't trust will be around in 5yrs. Would love to pay a few bucks a month for this service to help alleviate that fear. Making money is a good thing.
It's indeed a very valid point, but they are already making a huge progress and few people noticed the abrupt change. When they launched here, it was full of negative comments, many questioning how much funding they got given that the idea 'wasn't very good', some security professionals said. Now their filesystem is making such a noise and they're getting and will get more users. It's a gamble to see if they could put the commercial layer on top of it or not. That's why funding startups is risky. The good business model may not get enough users and the absent business model may get many users and could try to monetize on top of it. It's a gamble, as usual.
Except that "product" means some real result of a creative process. There's zero about the term "product" that has any reliance on any element of money inherently.
prod·uct \ˈprä-(ˌ)dəkt\ 2.a.1 Something produced ; 2.b Something resulting from or necessarily following from a set of conditions. This book is the product of many years of hard work.
There's another sense (not listed) in which "product" specifically refers to prohibited drugs. I know, and you should know, that quadrangle wasn't using that sense. As regards the point being disputed, rburhum is plainly wrong to say "If you are not trying to make money, then you can't call it a 'product'", and quadrangle is completely correct to call him on it. You can call anything produced a "product". That is the meaning of "product".
If the word "product" is used in the context of "Business Model" (as in right under the "Business Model" subtitle), then it is fair to assume the definition of Business product https://en.wikipedia.org/wiki/Product_(business) and not the by-product of a process or anything drug related.
He is not "plainly wrong" if the first definition of the word in question is literally supporting what he is saying. Your assertion of his correctness is what is plainly wrong.
Don't get too hung up on "the first definition". The first definition of product in M-W is "the number or expression resulting from the multiplication together of two or more numbers or expressions". That says absolutely nothing about what it means in any particular sentence.
The bit rburhum objected to says "We're not trying to make money. We're testing a product right now." This is correct idiomatic use of the word "product" (in the sense "something we make"), and it's a relevant answer ("we don't have one") to the question "what is your business model?".
They aren't trying to make money short term. That's the kicker. I think they'll be able to monetize it later in a way that doesn't impact the average Joe.
It's a negative but not a huge negative. I, and basically anyone sane, would prefer them to have a business model we could evaluate in our minds - it's just an unknown that isn't helpful. However, it's common and we can deal with it.
I have seen lots of "security-software" get lost in the trap of monetising first and never making it alive because money becomes more important than a real secure product. I would much rather let them wait and build something good and _only_ then try to raise money.
> If you are not trying to make money, then you can't call it a "product".
You could, however, say you are testing a product. Which is probably how users should treat startups that don't know how they'll make money yet -- as a product in testing.
It works to repeatedly append to a file on one machine and `tail -f` it on another. Even an encrypted file. It just works.
As for collisions, a "conflict" is handled as you would expect on file syncing services, although all conflict resolution has to be done by the clients! (Even in the unencrypted public folders, the resolution of the conflict has to be signed. And in the encrypted case, obviously the server has no idea.) This is one of the many things that had made KBFS a large and interesting project.
If you really wanted to use KBFS as a transport layer, you could avoid the conflict entirely by each device claiming a file to write to, and each one in a folder can monitor the others' files.
> As for collisions, a "conflict" is handled as you would expect on file syncing services
I'm not sure what to expect though. Does it rename subsequent files by appending _##? Or does it overwrite? Or does it allow 2 files with identical filenames, like Google Drive (at least on the web) does?
Oh I see, sorry for not fully answering. Keybase does not merge files or anything source-control like that. In fact, if that's what you want, you can actually init a bare repo inside of Keybase and clone into and out of it. We do this all the time as we're dogfooding. It's cool that every push is signed automatically, and every pull or clone is verified.
The conflict resolution Keybase does do is simple and much like what Dropbox does. The clients will determine a winner, and the loser will be written as something like `Keybase Logo.conflicted (sjs382's imac5k copy 2016-02-04).psd` Note in this case 'imac5k' is a guaranteed unique device name for sjs382, due to the way our merkle tree of key announcements works.
By the way, the conflict resolution of a single file is one case in a fairly large list of possible conflicts. What happens if you remove a directory on one machine, but add a file to it on another? And so on. The conflict resolution flow is designed to protect you from data loss above all else.
On the page it says it is "open source Go". Does that mean that, at least theoretically, I (or another independent provider) could build this and run my own personal keybase server? If so, that would really excite me. The one thing that really keeps me away from most cloud storage and sync services is lockin. I just am not willing to be come super dependent on a service that is building their business around proprietary lockin rather than providing an excellent service.
Yes it's pretty straightforward. You can even do something much simpler if you want to self-host and just want a sort of encrypted dropbox for yourself.
I recently did a little proof of concept hackathon entry (gopher gala) for a very similar idea which works with keybase.io for keys or your own server - https://sendto.click, which is also open source. This is far simpler of course but there's no reason in principle you couldn't just compile the client yourself, write your own client and use their server, or just write your own client and server, using the same golang crypto libraries, which are here for pgp:
It doesn't have to be quite as complex as the keybase tools, though I'm sure they have reasons for every decision and have thought hard about the way it all works, the crypto libraries they've based it on are open source and relatively straightforward to use.
My one hesitation about using keybase.io would be their business model and whether they'll be around in 5 years. They might have the best intentions but if it doesn't make money, and/or is bought by a large corporation, all bets are off on how the service will evolve or whether it will continue to exist. I'd love to see them start charging money and have a sustainable business model.
I wouldn't be too hesitant to use it. I think it depends mostly on being able to verify everything that they verify. Which they already encourage you to do: leave signed signatures in profiles so that people can verify them independent of keybase.io
Maybe it's because I am not a keybase user, but can somebody explain this product in human terms? I am not an idiot, and it does sound interesting, but the post is too long and I just want to know what makes it unique compared to dropbox, etc. in one sentence.
Dropbox synchronizes files between your computer and their servers. Keybase stores the files on their servers and only downloads/uploads them "on demand". Think of your web browser accessing gmail.com versus running something like Thunderbird that downloads your mail locally.
As a benefit, it's much simpler to implement - you don't need to work as hard to handle conflicts where two people made incompatible changes while offline. However, it will be slower for bulk operations and will require an internet connection.
Unfortunately the FUSE model isn't as simple to implement as it might seem. For performance reasons we're going to have to accept writes locally and push to the server in the background, which means all the same conflict resolution logic needs to be there. (In our case "there" means the client; the server can't help us, because it doesn't have any keys.) It's not clear exactly how much we'll be able to do for you without an internet connection, but the files you've read recently at least will need to stay in cache somehow. Fun times :)
so if i understand correctly, the model is more like the old megaupload/rapidshare/etc.....so what's new? Is it that they provide multiple ways of sharing tied to social media, compared to public/private/password protected mode of sharing for those aforementioned services?
In my interpretation, the sentence about "there is no sync model" only means "files are only downloaded to the client device when the client attempts to open() or read() them". I guess means that files will not take any disk space on your device.
In my interpretation, files are stored on keybase servers.
Is that correct? I agree that the "sync" sentence in the article is confusing and maybe a bit misleading.
They're calling it a "file system," whatever that means. Presumably it means you can create encrypted virtual disk partitions that represent network storage shared with various peers, and treat those partitions as if they were resident on local drives.
Agreed that they need to work on the narrative a bit.
You don't have to, but unless someone decides to "pin" it it might just disappear at any time. So you better pin it yourself or find someone reliable to pin it for you.
I'm all for IPFS, but I think you're missing the forest for the trees. Crypto is hard, especially PKI. KeybaseFS is crypto first, global FS second, while IPFS just says "do crypto yourself" - which, as we've seen with email and texting and literally everything else, doesn't work.
I would love for KeybaseFS to work via IPFS instead of their own servers. But pointing at IPFS as a /replacement/ for this crypto+FS project is disingenious.
> Your app will encrypt just for you and then awake and rekey in the background when that Twitter user joins and announces a key.
Isn't this the weak link in the chain? If you can convince the client that you're the person the data was encrypted for, it will re-encrypt it with a new key and send it to you, thus making the encryption useless. What's the protection against this, other than "don't worry, we won't introduce bugs"? (I'm not saying Random Twitter Troll will do this, but couldn't "the government" compel Keybase to re-encrypt your content with a key they have?)
What does the encryption add here that a server controlling access doesn't?
Well I can audit the source code of my client and be assured that it will only rekey when it sees proof (posted via twitter) that the person the data was encrypted for has joined.
Keybase doesn't have my private key (only I do), so they can't re-encrypt the contents.
Cross device usability suffers, then. Credential locked keyfiles stored server side could be served to end users without revealing the key to the server - you would still need to input the credential locally to open the keyring, but then you could just login to a client rather than having to copy public keys around by file.
I imagine the later isn't impossibly complex, but would require slick engineering to get over the barrier of expectations most people have.
I'm not sure about that either. The weakest link seems to be a national security letter to Keybase where they distribute a backdoored version of the FS driver to Alice, and adds the key of Eve to all messages also encrypted to Bob.
However, Keybase can't just broadcast "Eve on twitter is Bob!" - the client gets that announcement and links you to the tweet that claims it, where you audit the twitter handle, key fingerprint, etc.
If the NSA is your adversary model, Keybase isn't for you. If the NSA is your adversary model, NO system involving any central servers is for you, unless they only act as a dumb relay. Since Keybase is also the provider of your proof that another party is who they claim to be, they will always be suspectable to a government adversary. If you want to be NSA-safe, you can't trust any third party companies code, and that just leaves you DOA.
I think the bigger problem with this is the Skype message deliverability problem. Everyone uses battery-powered devices (laptops and cell phones) now, so it's possible that days or weeks could go by before the app could wake up and rekey the data.
I would be really interested to see how they're making the filesystem cross platform if they're supporting Windows. I see in their 'hiring' page they mention FUSE which would give Linux and OS X support.
I too am very interested in if they are currently supporting Windows and/or if/when they plan to. I was hoping this blog post would have at least mentioned it in passing.
We are testing a build for Windows that uses Dokan. Early results have been very positive. It's an important feature of KBFS that it can run on Windows.
Hi Chris, the very first versions of Boxcryptor for Windows some years ago also used Dokan. Our experiences have been really bad and as the user base grew so did the number BSOD reports caused by Dokan (v0.6 back then). We are now using the commercial driver CBFS since 3+ years and are really happy with it. Hint: As development at Dokan has picked up again with Dokany, I don't know anything about its current stability.
Also, it's a terrible Plan B, but it's still a Plan B to keep in mind: Windows still has semi-adequate WebDAV views in Explorer. OneDrive for Business is still WebDAV-based for instance. (I've also seen and used several backup and NAS tools that have relied on WebDAV.)
There's always the ability to use a SAMBA server variant and be a network share. Still a lot of dumb Windows apps that fail on network shares, but most of those are long in the tooth and should be retired anyway (and the tried and true Map Network Drive is still a power user workaround).
It looks like one application I use (JungleDisk) is somehow faking a removable drive (such as USB). I'm curious how they've built that.
I wonder how hard it would be to use the NTFS pseudo-files that OneDrive used in Windows 8.1 (and abandoned in Windows 10 for being "too confusing to the average user")?
It's a public accounting of everyone's keys. All participants can review the blockchain to confirm the accuracy of their own public key. Three-letter agencies can't fork the blockchain and replace a key from the perspective of one participant.
It's not a forking attack, it's a selective-lying attack -- a malicious Keybase server could serve up old versions of someone's files, or pretend that e.g. no shared files exist between you and another user even though they do.
Putting everything into Merkle trees with published updating hashes allows clients to catch a malicious server -- if the server wants to lie to someone (without being caught), it has to lie to everyone at once.
When reading this I though, is this how the next "web" will look like!? Having the world mounted at file system level and content streamed or pushed on demand.
What about a public key block-chain where "mining" is storing and serving data!? A system with baked in hosting/browsing, identity (public key) and micro-transactions (web-money).
Unfortunately you just need to hack keybase and serve malicious code. It doesnt matter if its signed if my malicious code tells you the signature verification succeeded.
Client side needs versioned code to make this harder. Including signed, versioned javascript code, automagically.
This will also make alterations of web sites code a lot easier to detect.
Since this is a filesystem that streams data on demand, how does it behave under poor network conditions? I'm also curious how much data it caches locally, e.g. if I'm on a laptop and lose wifi for an hour, how much of the data in the keybase filesystem can I reasonably continue to access?
This is an awesome announcement and got me totally fired up.
Unfortunately, I wasn't even able to log in to my keybase account on a new computer. Judging from the 1,000 outstanding issues on their Github, it seems like Keybase should first be focusing on fixing the bugs in existing software before rolling out new products. [0]
As for the substance of the filesystem, it would be nice to have some concept of named/shared groups. So I could create a "company" folder and then add people to it over time instead of having to create a whole new shared folder each time we add someone new. (And having to manually copy over all relevant files.)
I hate begging but I've been in the keybase queue for at least a year and would like to finally see what it's all about. I'd appreciate it a ton if someone could shoot me an invite: [removed] Thank you very much ashishchaudhary! :)
"Centralised Crypto" in what sense? Unless I'm very much mistaken, your private key never leaves your control - signing/encryption is done client-side.
One _can_ host their private key(s) on Keybase (you need to to use in-browser tools) but you don't have to; can instead use Keybase cli, or gpg directly.
The entire system is architected so that you don't need to trust them for anything, beyond the trust you generally need to have in open-source developers. What is a specific scenario that concerns you?
Are you talking about the announced file storage service here? Or about the "drudru claims to be foobar on Twitter" service?
The former should be good - that sounds like a smart client in front of a dumb server. The latter is a different problem and as far as I'm aware the service is merely aggregating proves - and can link to those. Verify them?
Wasn't keybase started due to a problem snowden had? He couldn't easily verify the GPG key of a journalist? They even resorted to tweeting the public key fingerprint to verify: https://twitter.com/micahflee/status/296119710485979136
>If that person hasn't installed Keybase yet, your human work is still done. They can join and access the data within seconds
Good luck getting people to do that.
Edit: I guess if the audience for this is technical people, then the kind of person who follows them is likely to be the kind that would download it, but that's a very small market. There's a far greater barrier to getting people to install software (with little tangible gain) than getting them to sign up for your website.
A monetization idea: let people create folders that others need to pay to access and take some % of the payment (useful for companies distributing movies, games, etc.)
So slightly tangental but keybase has been around for a few years now, right? I haven't been able to figure it out but are they only afloat due to investment funds? Do they have any monetization plans? I setup a profile but I'm curious what the company ends up turning into. Perhaps the money made from providing paid upgrades to this filesystem can give them enough profit?
so assuming one trusts the model, would it work to have something like:
I have a /me/private/yourwebsite.com set up to be shared between me and your particular site, the link is set-up when I sign up
when I log in your site, it would look for this directory to be there, in this directory there will be a file with a password hash, the server would load it, and validate the hash of the typed in password against the hash I provide, once the login is successful it would remove this file
this would basically mean that I could have single-use passwords for any site as it would be trivial to have a browser add-on that generates a random password and corresponding hash when I want to log in somewhere, it types the password in the password field on the page and puts the hash in the keybase directory corresponding to it, and alert me if the site does not remove the file after the login.
You can get rid of the middleman and just sign a nonce for the site, modulo the "don't sign whatever someone gives you" caveat. If you have a PGP key that uniquely identifies you, there are many many things you can do.
I have 9 invites and I do not particularly want to trawl through all of the existing comments to find people who may or may not have been invited since having posted their comments hours ago.
So, reply to me here or email me (wanda {at} teknik.io) and I will send you an invite. First co-- actually, first noticed, first served.
I can't see your email address anywhere. I googled your screen name, which just led me to various web 2.0 accounts. Your website seems to be down or non-existent. Sorry, you'll have to wait for the next train.
I've been using keybase and their copy really seems to make sense to people that do not understand encryption. I've been able to get more of my friends using PGP recently due to this. I'm hoping that the file system will get more people to migrate away from dropbox, etc.
I've got invites (9) for Keybase that are collecting dust if anyone wants one. Email in profile.
WOW: That happened fast, I'm all out of invites now... 2 minutes after posting emails started coming in and within 3 minutes I was out. Sorry if you didn't get one...
I have 8 invites if any other stragglers (6 hours after the story was posted) are still reading. I'm heading to bed but will send them during morning coffee, GMT -5. (please make sure your email is in your profile)
Are there any invites floating around yet? I'd love one, email address is in my profile. Very interested in developing other tools against Keybase, with mruby or Elixir.
I am so excited for this project. I have been waiting for an invite for close to a year. Can anyone send me one? EDIT: email: jsrjenkins @ [google's email service].com
That does not work - I have to log in with the command line client, which fails because I it doesn't have GPG sign with the correct key. Edit: Managed to get it to work by restoring a backed up keyring from before I updated my keys.
It is 2 weeks old, but that's also the latest tagged release on github, so it's not out of date. I'm not seeing how to actually get KBFS on linux today.
Considering keybase-release[0] was "Last Updated: 2015-11-03 22:36", community/keybase is a lot more recent, but still from January, so not recent enough.
First, bravo for making it happen in a way that is getting people excited. Second, I sincerely wish you the best luck in getting people to pay for it in a way that is sustainable for a business. We built a user interface that made truly secure group file sharing accessible to mere mortals and said mortals were uninterested.
About three months after we shut down the business Edward Snowden made his infamous leak(s) and it became obvious to me that commercial crypto products coming out of the United States would be met with extreme levels of skepticism for some time to come. Any remotely centralized solution to the problems of key distribution and encryption are probably dead on arrival because of the single point of jurisdiction/political failure. It really doesn't matter how open you are (unfortunately).
Two things really stand out to me about this implementation. 1) The trustworthiness of the key exchange doesn't appear to employ a mechanism that protects against a man in the middle. 2) They mention the possibility of in-browser Javascript crypto. These are not small issues. The people who need crypto require rigid, durable implementations that don't gloss over security concerns in favor of usability. Everyone else is just being trendy.
I wish you the best of luck.