Graph of Keybase commits pre and post Zoom acquisition
github.com
github.com
Edit: following up on this since i think it was slightly misleading -- this has always been Zoom's public opinion since they announced the acquisition. Their goal was always to integrate the Keybase technology into Zoom. See their blogpost for more https://blog.zoom.us/zoom-acquires-keybase-and-announces-goa...
It's all such a shame but I guess that's why I stay away from centralized chat services.
There is probably a profitable business to be built to implement an opensource version of the Keybase server that is backwards compatible with the client and then start charging enterprises a reasonable price for data storage and communications to host it in the cloud. Zoom is sitting on a potential gold mine and they are just letting it languish.
It would be very cool if they acquired it tho, and I agree it is a potentially profitable business, but only barely so.
The closest Keybase alternative I've found so far is https://keys.pub/ (on HN: https://news.ycombinator.com/item?id=22995792)
Welcome any suggestions for KBFS alternatives!
More detail in our book - https://book.peergos.org
We can also do signed identity proofs with better privacy than keybase's. Here's a public example https://beta.peergos.net/public/ianopolous/.profile/ids/iano...
pricing 5 GBP per month - I read over that 4 times and it kept becoming 5 GB in my head... might I suggest adding $7 US per month and $80 per year perhaps.
then I checked the terms and I saw UK law - which has fluctuated a lot with content that is okay and not okay.. and then the word "obscene" is in there.. and other stuff that makes me wish this was hosted elsewhere.
perhaps for an extra X$ one can choose to host an instance on other locations and avoid some of the uk things I dunno.
There is also the option to self-host and still be able to interact with users on other instances, including https://beta.peergos.net.
Although the git graph looks like it's their only priority at the moment...
Five months later, they announce their initial technical preview of E2E encryption (https://blog.zoom.us/zoom-rolling-out-end-to-end-encryption-...)
What usually happens after M&A is if the acquired product isn't a profit-maker, they "integrate" it into other products and it goes into maintenance mode, eventually to be sunset. If the product did make money, they'd re-brand it and keep development going... unless they have plans to integrate the product's core feature into a larger corporate product (Zoom) that a separate branded product would compete against internally.
It seems like keybase has been eaten and absorbed into the Zoom app, and the rest will be flushed.
none of those hashes stand up to government level resources
every keybase customer is now available to china, which has a long pattern of logging in as you
There's a wealth of tools and docs, and users are becoming more and more conscious (which is fantastic, for the record!). There's the obvious ethics of keeping the data your users entrust you with safe to the best of your abilities, too.
Sorry, but the vast majority of people just don't care. Customers want a working product.
It would be wasteful to throw away the Web of Trust (people with handles to keys) that everyone entered into Keybase. Hopefully, Zoom will consider opening up the remaining pieces of Keybase if not just spinning the product back out to a separate entity?
From https://news.ycombinator.com/item?id=19185998 https://westurner.github.io/hnlog/#comment-19185998 :
> There's also "Web Key Directory"; which hosts GPG keys over HTTPS from a .well-known URL for a given user@domain identifier: https://wiki.gnupg.org/WKD
> GPG presumes secure key distribution
> Compared to existing PGP/GPG keyservers [HKP], WKD does rely upon HTTPS.
Blockcerts can be signed when granted to a particular identity entity:
> Here are the open sources of blockchain-certificates/cert-issuer and blockchain-certificates/cert-verifier-js: https://github.com/blockchain-certificates
CT Certificate Transparency logs for key grants and revocations may depend upon a centralized or a decentralized Merkleized datastore: https://en.wikipedia.org/wiki/Certificate_Transparency
How do I specify the correct attributes of my schema.org/Person record (maybe on my JAMstack site) in order to approximate the list of identities that e.g. Keybase lets one register and refer to a cryptographic proof of?
Do I generate a W3C DID and claim my identities by listing them in a JSON-LD document signed with W3C ld-proofs (ld-signatures)? Which of the key directory and Web of Trust features of Keybase are covered by existing W3C spec Use Cases?
From https://news.ycombinator.com/item?id=28701355:
> "Use Cases and Requirements for Decentralized Identifiers" https://www.w3.org/TR/did-use-cases/
>> 2. Use Cases: Online shopper, Vehicle assemblies, Confidential Customer Engagement, Accessing Master Data of Entities, Transferable Skills Credentials, Cross-platform User-driven Sharing, Pseudonymous Work, Pseudonymity within a supply chain, Digital Permanent Resident Card, Importing retro toys, Public authority identity credentials (eIDAS), Correlation-controlled Services
> And then, IIUC W3C Verifiable Credentials / ld-proofs can be signed with W3C DID keys - that can also be generated or registered centrally, like hosted wallets or custody services. There are many Use Cases for Verifiable Credentials: https://www.w3.org/TR/vc-use-cases/ :
>> 3. User Needs: Education, Retail, Finance, Healthcare, Professional Credentials, Legal Identity, Devices
>> 4. User Tasks: Issue Claim, Assert Claim, Verify Claim, Store / Move Claim, Retrieve Claim, Revoke Claim
>> 5. Focal Use Cases: Citizenship by Parentage, Expert Dive Instructor, International Travel with Minor and Upgrade
>> 6. User Sequences: How a Verifiable Credential Might Be Created, How a Verifiable Credential Might Be Used
Is there an ACME-like thing to verify online identity control like Keybase still does?
Hopefully, Zoom will consider opening up the remaining pieces of Keybase if not just spinning the product back out to a separate entity?
> The last IETF draft for HKP also defines a distributed key server network, based on DNS SRV records: to find the key of someone@example.com, one can ask it by requesting example.com's key server.
> Keyserver examples: These are some keyservers that are often used for looking up keys with `gpg --recv-keys`.[6] These can be queried via https:// (HTTPS) or hkps:// (HKP over TLS) respectively: keys.openpgp.org , pgp.mit.edu , keyring.debian.org , keyserver.ubuntu.com ,
npm i @transmute/lds-gpg2020 -g
gpg2020 sign -u "3BCAC9A882DEFE703FD52079E9CB06E71794A713" $(pwd)/docs/example/doc.json did:btcr:xxcl-lzpq-q83a-0d5#yubikey
From https://gpg.jsld.org/contexts/#GpgSignature2020 :> GpgSignature2020: A JSON-LD Document has been signed with GpgSignature2020, when it contains a proof field with type GpgSignature2020. The proof must contain a key signatureValue with value defined by the signing algorithm described here. Example:
{
"@context": [
"https://gpg.jsld.org/contexts/lds-gpg2020-v0.0.jsonld",
{
"schema": "http://schema.org/",
"name": "schema:name",
"homepage": "schema:url",
"image": "schema:image"
}
],
"name": "Manu Sporny",
"homepage": "https://manu.sporny.org/",
"image": "https://manu.sporny.org/images/manu.png",
"proof": {
"type": "GpgSignature2020",
"created": "2020-02-16T18:21:26Z",
"verificationMethod": "did:web:did.or13.io#20a968a458342f6b1a822c5bfddb584bdf141f95",
"proofPurpose": "assertionMethod",
"signatureValue": "-----BEGIN PGP SIGNATURE-----\n\niQEzBAABCAAdFiEEIKlopFg0L2sagixb/dtYS98UH5UFAl5JiCYACgkQ/dtYS98U\nH5U8TQf/WS92hXkdkdBQ0xJcaSkoTsGspshZ+lT98N2Dqu6I1Q01VKm+UMniv5s/\n3z4VX83KuO5xtepFjs4S95S4gLmr227H7veUdlmPrQtkGpvRG0Ks5mX7tPmJo2TN\nDwm1imm+zvJ+MXr3Ld24qaRJA9dI+AoZ5HXqNp96Yncj3oWD+DtVIZmC/ZiUw43a\nLpMYy94Hie7Ad86hEoqsdRxrwq7O6KZ29TAKi5T/taemayyXY7papU28mGjVEcvO\na7M3XNBflMcMEB+g6gjrANsgFNO6tOuvOQ2+4v6yMfpJ0ji4ta7q2d4QKqGi5YhE\nsRUORN+7HJrkmSTaT7gBpFQ+YUnyLA==\n=Uzp1\n-----END PGP SIGNATURE-----\n"
}
}From https://news.ycombinator.com/item?id=28926739 :
> NIST SP 800-63 https://pages.nist.gov/800-63-3/ :
> SP 800-63-3: Digital Identity Guidelines https://doi.org/10.6028/NIST.SP.800-63-3
> SP 800-63A: Enrollment and Identity Proofing https://doi.org/10.6028/NIST.SP.800-63a
FWIU, NIST SP 800-63A Enrollment and Identity Proofing specifies a spec sort of like ACME but for offline identity.
https://github.com/keybase/client/issues/24105
Hopefully if enough people make their voices heard Zoom will either opensource it or maybe revive development of it.
Don't want to reset or delete the entire account for now, but I'd like to remove some stuff.
No echo, no sound+video synch issues, rarely any "breaking up"... they must've implemented some very nice tricks to make all these work even when we have meetings with people sitting in from several different countries.
Despite their security issues, it's not surprising they came to dominate the market: it was the only product that really worked.
Very sad it didn't get more traction. I still use it.