Open source the server components of Keybase

[kallisti5]

There's an uproar in keybase chat about the purchase of Keybase by Zoom.

Statements like this "Ultimately Keybase's future is in Zoom's hands, and we'll see where that takes us." scare the keybase community and will drive away the more technically minded user-base.

Please open source the server components to keybase.

While the Keybase client is open source, and handles all of the encryption + decryption, the server component that streams chats, file transfers, etc between users is not. Keybase will not function if Zoom shuts down the (currently closed source) server component.

This act will help ensure the long term stability of the keybase platform in-case keybase's future is bleak at Zoom.

[virtadpt]

Please! Very much please!

[NewAlexandria]

This seems like an important step in Zoom retaining the value that they paid for in the Keybase acquisition. (admittedly, only Zoom know's what is best for Zoom's value)

[Laphatize]

facts bro

[aaronky]

2020 strikes again, I’m really bummed because I have integrated keybase into my workflow heavily over the years.

Back to rolling my own again. This one hurts.

[Southclaws]

There should be "nothing to hide" regarding the server(s) implementation. I'd imagine the worry is that once technical users (probably the majority of the userbase) can self-host their own infrastructure, there's no need for a company to exist.

That being said, I'd still happily pay a small monthly fee for a hosted server even under the circumstances of the acquisition. I'm still preparing to move my documents to another place though. And have been since Keybase became a day to day tool for me, since their business model, and thus any promise of sustainability, was always nonexistent.

[kfogel]

There would still be a demand for one central company that is the go-to place for those who don't want to set up their own server. Typically, one of the biggest drivers of demand for a "we host it for you" company like that is when organizations set it up themselves and then decide, after a period of time, that self-hosting isn't worth the trouble anymore. They become more likely to become customers when they know that they could, in principle, go to another vendor or host it themselves if absolutely necessary -- but if they're getting good service, they won't ever leave.

So, +1. I hope Zoom makes the decision to open source the server code. I'm not privy to all the factors that went into their Keybase decision, but from what I can see from the outside, it would make a lot of business sense.

[kallisti5]

A "feeling" in the keybase community is Zoom purchased keybase for all the smart crypto-nerds who wrote the platform to help them improve the security of the Zoom application + platform. This is all pure speculation though. (and somewhat based on the language at the end of the keybase blog post)

Lets keep +1'ing this issue to show there is a lot of support in the keybase community for open sourcing the server components. If Zoom has good intentions, and are only interested in the skilled developers who wrote it... there is a chance they might agree to opening the server components.

[clord]

Zoom could achieve a big win here.

[alexparker]

There should be "nothing to hide" regarding the server(s) implementation. I'd imagine the worry is that once technical users (probably the majority of the userbase) can self-host their own infrastructure, there's no need for a company to exist.

That being said, I'd still happily pay a small monthly fee for a hosted server even under the circumstances of the acquisition. I'm still preparing to move my documents to another place though. And have been since Keybase became a day to day tool for me, since their business model, and thus any promise of sustainability, was always nonexistent.

ghost.org exists keybase server could exist too while still open sourcing the code

[Southclaws]

ghost.org exists keybase server could exist too while still open sourcing the code

I agree, many other open source businesses exist too. But I can imagine the angle would be that Keybase is a tech product for technical users. Still, I don't like the hassle of self-hosting and I'm sure many share the same sentiment and would prefer to pay for sustainability.

[Southclaws]

A thought occurs: are there any unknowns that would prevent one from implementing their own backend by reverse engineering the API calls from the client? Seems doable, if Keybase itself don't disclose the source.

[programmarchy]

A thought occurs: are there any unknowns that would prevent one from implementing their own backend by reverse engineering the API calls from the client? Seems doable, if Keybase itself don't disclose the source.

@Southclaws Possibly, but why not just contribute to Matrix / Riot instead at that point?

[Southclaws]

Possibly, but why not just contribute to Matrix / Riot instead at that point?

You're probably right there. I didn't consider that because I never used the chat features of Keybase, just the encrypted Git and filesystem integration.

[rscmbbng]

@Southclaws Possibly, but why not just contribute to Matrix / Riot instead at that point?

Because it is your next VC funded disappointment waiting to happen?

[manuelvsousa]

Possibly, but why not just contribute to Matrix / Riot instead at that point?

You're probably right there. I didn't consider that because I never used the chat features of Keybase, just the encrypted Git and filesystem integration.

This. I believe this is the most difficult thing to replicate, and I think it's what most people want to be open-sourced. The chat is a sad loss, but there are a lot of good alternatives out there for that.

[programmarchy]

@Southclaws Possibly, but why not just contribute to Matrix / Riot instead at that point?

Because it is your next VC funded disappointment waiting to happen?

For one, it's entirely open source. But why do you say it's VC funded? From their site:

The Matrix.org Foundation is a non-profit UK Community Interest Company, incorporated to act as the neutral guardian of the standard on behalf of the whole Matrix community. It is an open initiative which acts as a neutral and independent custodian of the Matrix standard.

[rscmbbng]

For one, it's entirely open source. But why do you say it's VC funded?

Because it is. Matrix is developed by a startup called New Vector which has already taken multiple rounds of VC money. The Matrix.org foundation is only for the development of the standard, the development on Riot and other software is done by the VC-backed New Vector. The way that Matrix is positioning itself as the 'meta-protocol', bridging other protocols, slowly gobbling different services and communities sure feels like EEE to me.

[nuke-web3]

+1!!!!

If the server source is available, this will allow for a federated group of keybase servers to come up. I personally want to use this as the foundation for a community hosted cloud services project.

The community already use keybase as the primary source of community chat and shared files with the foundation of provable ID for members. We would love to self-host this as a service in full for the group and help others do the same in a simple, easy to maintain way.

[Camorandj]

If someone knowledgeable and private can please contact me that would like to help and/or make a difference with this project I can help you help me fix it I hope. I cannot find a good friend that believes me, in that, I have a lot of control via a computer genius and his files. Sadly, he is no longer with me, but was an important role in the future of ai...

On Thu, May 7, 2020 at 17:30 Dan Shields ***@***.***> wrote: +1!!!! If the server source is available, this will allow for a federated group of keybase servers to come up. I personally want to use this as the foundation for a community hosted cloud services project <https://github.com/Cryptorado-Community/Cryptorado-Node>. The community already use keybase as the primary source of community chat and shared files with the foundation of provable ID for members. We would love to self-host this as a service in full for the group and help others do the same in a simple, easy to maintain way. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKVHKYQRQLKW5VJ5EYYN3X3RQMY7VANCNFSM4M3SFNEQ> .

-- TAMARA NUTTER

[babolivier]

The Matrix.org foundation is only for the development of the standard, the development on Riot and other software is done by the VC-backed New Vector.

Not true. All the server side software, and more generally any project under the matrix-org organisation on GitHub, is owned by the foundation, which isn't directed by New Vector. In fact, all the work New Vector employees do on these projects is donated to the foundation. Only Riot and Modular.im belong to New Vector. And even then, Riot's open source, anyone can host it outside of the riot.im domain, fork it, hack it. If New Vector was to take a wrong turn at some point in the future, it wouldn't mean people wouldn't have access to a Riot that didn't.

[babolivier]

just the encrypted Git

FWIW some folks in the Matrix community are experimenting with Git over Matrix, which makes sense since the structure of a Matrix room (a DAG) isn't unlike the one of a Git repo 😛

[junderw]

Gitlab opens their backend and still has a stable business with steady revenue from support contracts. They offer private hosting solutions OR support for self-hosted solutions.

Bitwarden also open sourced the backend, and uses signed certs to open up certain features to paying customers.

"Front and Back open but still making money" is totally viable.

Our company would totally do a support contract with a proxy for the CCP. But anything more than a support contract is a no go...

This really hurts a lot. I personally liked this app, would have paid for it. Our company would have paid for it.

It didn't have to be like this.

Another example of governance ruining a good project.

[ajgraves]

There's a possibility (and this is purely speculation by an outsider here) that Zoom is looking at the potential to add a potential Slack competitor to their portfolio to provide an all-encompassing solution for remote work... you get the team organization and chat, along with video conference.

[jamesjulich]

I don't have much to say that hasn't already been said. I totally understand why you all sold the company. I don't hold any ill-will for that. That said, I think the community would've been really appreciative if we'd gotten some assurance that Keybase as we know it is not going to go away.

I hope this acquisition ends up like Microsoft's purchase of Github. Lots of outrage at the beginning; 6 months later, all is bliss. We love Keybase. Many of us would be willing to pay for it. Please do not kill it off.

[lattice0]

I just want a private end-to-end encrypted git

[Tedko]

@kallisti5 Take a look of www.Maskbook.com www.github.com/DimensionDev/Maskbook and our approach to do it in a much more server less way.
But indeed many functionalities of keybase still require a server though

[mannp]

Have to say I was very disappointed and deleted my families keybase accounts already.

I hope they do open source this, but really can't see it happening.

[themilkrat]

Open source or mass exodus.

[GwynethLlewelyn]

@GwynethLlewelyn had me until there were mentions of Microsoft not being evil. Definitely still is Evil Corp. GitHub is used as a tool to lock developers into a platform and try to sell its other proprietary services (Copilot, Codespaces, getting a chunk of donations with Sponsors, closed VS Code plugins, etc.)

Heh. You're obviously right! I was just attempting to whitewash Microsoft a little: in the sense that Microsoft is less evil today, compared to what it was, during, say, the early 1990s (before they restyled themselves as 'the Internet company' and gave up on MSN Network).

[GwynethLlewelyn]

I think the tldr is Keybase is dead. We got zero movement since Zoom took over in 2020. The client saw a few updates since it is open source and a few folks are still reviewing / merging patches, but overall things are slowing to a crawl.

Well... not really dead, to be fully honest. I have been reading a few past threads attempting to 'prove' that all work at Keybase stopped since 2020. Personally, I'm not quite convinced of its 'dead' status. The Keybase team only ever had three user accounts on GitHub, AFAIK. Probably there weren't more people working at Keybase. Who knows? 🤷‍♀️ If there were, they either were here incognito, or possibly didn't even use GitHub at all (but just a Keybase-enabled internal Git repository!).

While it's true that most of the work going on are small patches and fixes here and there, made by community members who happen to have the right permissions for that, it's not that different from other open-source projects I've seen. There are a handful of commits per day — all minor things, sure, but it's not as if 'development stopped completely'.

This, IMHO, would be enough of a pretext to go ahead with a reverse-engineered version of the Keybase Server — assuming, of course, that nobody is able to persuade Zoom to do exactly that.

[DiagonalArg]

I wasn't going to read it eaither, but it was worth my time. I think the bottom line is, there is precedent to the idea that if the community starts working on reverse engineering the server, we may be successful in getting something that works - we may even be sucessful in getting Zoom to release some/all of the code if they see a fait accompli and/or if they identify a way to make the system profitable even with an open sourced version.

[kallisti5]

Oh look, Zoom is shutting down one of the more interesting features of Keybase without open sourcing the server software. suprise! 🎊

[yubozhao]

This issue is like the youtube comments section of an old video. We still gather around once in a while to think about the good ol' days.

Joking aside, I hope we have a solution/approach to this soon.

[cherryblossom000]

While it doesn’t have all the features of Keybase (e.g. doesn’t have web hosting), I’ve migrated to Keyoxide which allows you to verify your online identities.

[nealmcb]

@cherryblossom000 Note that this github issue is now long enough that you have to explicitly ask to see all the comments, including this one which has some more helpful insights on Keyoxide, i.e. that it "is an absolute mess of a UX", in stark contrast to keybase: #24105 (comment)

It also has this advice, which mirrors several other comments here:

If you like Keybase because of the ease of use, Keys.pub is a far more promising project and is much more closely aligned with Keybase

At the same time, I'll note that the recent anouncement of the shutting down of Keybase.pub (a web mirror of public KBFS files), as noted above by @kallisti5, actually underscores that the team is (contrary to many guesses in this thread) continuing to support Keybase in a relatively responsible way nearly 3 years after getting new high-profile work. So I for one continue to hope they eventually get back to either improving it or handing it over to a team that can and will. Since there still really isn't anything else as amazing as Keybase.

[GwynethLlewelyn]

1. Let me echo, underline, subscribe and recommend @nealmcb's assessment of Keybase's commitment to its namesake product 😸 For each "Keybase is dead" comment on this insanely long 'issue', the Keybase developers have been busy at releasing a few new versions — at least on the client-side of things (we obviously cannot see what they did on the server-side). None of these changes were, well, earth-shattering — more like fixing tiny bugs here and there. It is true that, for a while, there seemed that 'nothing' was going to happen — which coincided with the period of time when the Keybase team faced their new Zoom Overlords, told them what they had, got the reply that "it's too advanced for our lowly free-riding users; do something simpler", wrote some code from scratch (or so the legend goes), and made Zoom's stakeholders very happy.
   It's conceivable that, while on a long journey of many sleepless nights during the pandemic lockdown, the team was laser-focused on their Zoom assignment, and had no time for anything else (beyond the occasional reboot of Keybase's servers or similar things). But three years later, well, I can guess that the original efforts paid off, Zoom remains happy (and secure!), they might be preparing the next Zoom security enhancement (as a paid product), but have been given some free time to hack away at the Keybase code again.
   While perhaps we might not expect a flurry of cool new features dropping from the sky, it's reasonable to assume that, thanks to Keybase's currently very stable codebase, they might just need to spend their time fixing bugs and polishing their software. This was clear to me when they started addressing issues such as Enable Keybase in Finder doesn't work in macOS Big Sur 11.0.1 #24366 or KBFS doesn't work on macOS X 11 Big Sur (still works with <=6.0.1) #25379, which are strictly related to supporting newer and legacy versions of certain application layers (more specifically, the ability to use the KBFS redirector facility under different macOS versions). They have been releasing newer versions of Keybase — a reasonable handful of them, in fact, the latest of which are already code-signed with a date in mid-January 2023 — to address these issues specifically (and probably others as well); there remain a few outstanding problems that haven't been fixed yet, but it's not as if there was a total neglect and abandonment of their software. It's a WiP for sure, just perhaps at a slower pace than we were once used to.
2. For those who still think that my 2500-word-essay posted above is far too long to read, I brought Resoomer and ChatGPT to the rescue, and here is an AI-generated summary of my thoughts:

The author argues in favor of open-sourcing the server component of Keybase, a message encryption tool. They mention that the Keybase client application is already open-source, but the server is not. The author believes that Keybase users are looking for a secure solution without having to install and maintain another software. They acknowledge that Keybase was acquired by Zoom and the Keybase team is now busy working for Zoom, but they believe that Keybase could benefit from open-sourcing its server component. The author also mentions their experience with Second Life and how it remained successful for a long time despite being proprietary, closed-source and obscure. They believe that an open-source Keybase Server Community Edition would not hurt Zoom financially and might even have a positive impact.

There you go. I hope that powerful AIs are better at condensing my own words and still capturing the essence of it — because I certainly am not good at that!

[huyz]

Hahah thanks for the AI-assisted summary @GwynethLlewelyn !

[GwynethLlewelyn]

Hahah thanks for the AI-assisted summary

Glad you liked it, @huyz :)

Still, I hope that the nay-sayers have seen the flurry of recent activity on the Keybase client in the past month or so. 4 pages of fresh commits! Like in the good old days, I'd guess? Oh, sure, some are merely routine chores, just updating things here and there, but others are not — bugs are getting fixed, compatibility issues are being dealt with. The developers might be silently committing old things and possibly not starting to do an insanely big change overall, but... they're back. Not asleep.

I suppose the intense development they had been forced to do at Zoom has paid off; Zoom is now more secure, and they've been allowed to return to their 40-hour weeks (as opposed to the 120-hour weeks on the past few years!). Which is more than fair enough!

I'm crossing my fingers, but I surely hope to see a few more things coming up soon.

[GwynethLlewelyn]

... well, open issues from 2017 have been fixed and are being closed now (just got some notifications). That's progress :-)

[kallisti5]

I want to take a quick moment to look back at this statement from Dec, 2022:

I wouldn't invest anything in keybase as it stands, and be looking for alternative solutions. As soon as Zoom wants to save costs, i guarantee the keybase infrastructure will be the first thing shutdown.

-- #24105 (comment)

It's almost like I have a crystal ball 😆 Rip keybase.pub

[LHCF1A1Ossy]

Hey que pasa por que ocurrió?Open Go.2023 03

[nikow]

Do anybody have screenshots from keybase.pub? Can you describe how it was working?

[nealmcb]

@nikow Archive.org has some of the pages archived. See e.g.

https://web.archive.org/web/20221205121448/https://keybase.pub/

https://web.archive.org/web/20230208160820/https://chris.keybase.pub/

The announcement of it going away was on the web page which is no longer there. It said:

Announcement
We regret to inform you that the Keybase.pub web hosting service will be shutting down on March 1, 2023. Although the service was a great showcase for the kinds of cool things that could be built with Keybase, the usage of this product never took off. The continued cost of maintaining the site has led us to make the difficult decision to shut it down. If you are hosting any content on Keybase.pub, we strongly recommend moving that content to a new hosting provider as soon as possible.

No Keybase Filesystem (KBFS) data will be removed from any user public folders. All data will remain safe and viewable by others running Keybase. Other features of Keybase including Chat, KBFS, Teams, Git, Wallet and others will continue to run normally as well.

And indeed, the kbfs files are still there, so it is not a particularly significant loss.

$ ls -l /keybase/public/chris
total 32195
-r-------- 1 myusr mygroup  7809881 Sep  7  2022 einstein.svg
-r-------- 1 myusr mygroup     1160 Jan  3  2019 index.md
dr-x------ 1 myusr mygroup      490 Nov  2  2021 keys
-r-------- 1 myusr mygroup      938 Apr 18  2019 lobsters.txt
-r-------- 1 myusr mygroup 16881270 Feb  3  2020 moose.jpg
dr-x------ 1 myusr mygroup     1553 Jan 27  2017 photos
-r-------- 1 myusr mygroup     1729 Jan  3  2019 plan.txt
dr-x------ 1 myusr mygroup      629 Apr 23  2018 random
-r-------- 1 myusr mygroup  8265819 Feb  4  2020 those-darn-squirrels.jpg
dr-x------ 1 myusr mygroup      873 Nov  5  2020 verified_software

[nikow]

Thank you @nealmcb. I was wondering if i can use kebase client/service and some Python to recreate service. If i success, maybe i will be able to get redirection to my domain from Their one? We will see.

[notpushkin]

@nikow No need for Python even – should be totally possible by just configuring a webserver to read content from /keybase/public/{subdomain} (and render Markdown, probably). Are you ready to handle the traffic, though? I think it was the main reason behind keybase.pub retirement.

[marvhus]

+1 to them open sourcing the server software.

It would be beneficial to us, and them.
Also, what have they got to loose?
Keybase is free to use so they don't get any revenue anyways, Zoom seams to not care about it,
and people would still use their instance because not everyone wants to do it themselves.

[DiagonalArg]

I wasn't going to read it either, but it was worth my time. I think the bottom line is, there is precedent to the idea that if the community starts working on reverse engineering the server, we may be successful in getting something that works - we may even be sucessful in getting Zoom to release some/all of the code if they see a fait accompli and/or if they identify a way to make the system profitable even with an open sourced version.

This idea may be getting a lot easier (published 2020):
IReEn: Reverse-Engineering of Black-Box Functions via Iterative Neural Program Synthesis
Descriptive article: Researchers propose AI system that reverse-engineers black box apps

Published 2023:
Combining Functional and Automata Synthesis to Discover Causal Reactive Programs
Descriptive article: Autumn: Causal Discovery Through Program Synthesis

Fun discussion

[modemrunner]

--> "Please open source the server components to keybase."
Don't kill another beautiful online community.

[clayrisser]

Adding my comments here before "they" close this thread.

Please open source the server!!!

If it is not open sourced, the community will eventually build their own server or alternative and move away from this project.

[GwynethLlewelyn]

@nikow No need for Python even – should be totally possible by just configuring a webserver to read content from /keybase/public/{subdomain} (and render Markdown, probably). Are you ready to handle the traffic, though? I think it was the main reason behind keybase.pub retirement.

@pushkin @nikow here's a thought: an interesting Gist that uses nginx to redirect all Markdown files through a static HTML page, which, in turn, will pull marked.js with highlight.js from a popular CDN, and render every Markdown page on the browser.

So, from the perspective of nginx, it's just serving a small, static HTML file as the "rendering engine", which will only need be sent but once, let the browser cache it, and then the rest can follow — all static files, mind you.

Granted, that's something everyone can do for their own files, mounted on a low-end server (possibly just a VPS or even a cloud container or worker), which should handle everything nicely, under your own domain name.

As a service to the community — even if it's a small one! — obviously all the traffic from the static files adds up. For nginx, it shouldn't be a problem though, and it scales well. But... traffic is traffic!

So, here's a thought. We could apply to one of those very nice CDN giants out there who already host static files for gazillions of open-source projects. We might catch the interest of one that is a) already doing that kind of service for free for other services; b) is very security-conscious (because that's what Keybase is all about, after all), c) already uses nginx for their own backends, and d) already offers some sort of VPS/containers/workers so this would be an opportunity for them to show off their technology.

Why, one comes immediately to my mind — Cloudflare :-) It's the kind of service that seems to be designed for them to offer! And by "offer" I mean exactly that — make it free. In 99% of the cases, in the Keybase community, whatever we're hosting will not be insanely traffic-intensive. Or, putting it in other words: individually, there will be little traffic per instance/container/worker. It's just when one adds all that together that the traffic may become more challenging. But that's exactly what Cloudflare is good at.

And they've eagerly placed IPFS and Tor exit nodes on their infrastructure, too. Just, well, "because they can", not necessarily because either of those services is in desperate demand among Cloudflare's customers.

All right, as a disclaimer, I should say that I'm an enthusiastic fan of Cloudflare (at least, at this stage, where they, as a corporation, are Still Doing No Evil; but we all know what happened to Google... and I was a fan of Google too, 20 years ago, and even more naïve than today), and thus can recommend their services — especially the absolutely free ones! — to anybody, with a clear conscience :)

However, these days, among cloud services, there are lots of options to request such a service from. One notable example is the Cloud Native Computing Foundation (CNCF), part of the Linux Foundation. They could be a source of continuous funding of whatever infrastructure is needed for hosting not only keybase.pub — but possibly the whole of Keybase as well, if Zoom is willing to release the server components as open source and to allow their Keybase developers to work with the CNCF in order to migrate their infrastructure.

Part of the Merkle tree is managed via the Stellar blockchain, anyway; that means that at least one major component doesn't require any new infrastructure to maintain. The Stellar Foundation is a non-profit that manages the (decentralized) Stellar blockchain using funds from donations — not necessarily from getting mining fees or by actively engaging in cryptocurrency day trading — which means that our collective history will remain there for anyone to see, even if Keybase stops providing any services in the future. This has some interesting consequences for whatever future lies in store for Keybase (both as a company and a service) — after all, you might be able to recover all that (encrypted) history without requiring everybody to relinquish their personal accounts and start from scratch with new ones on a different service...

[huyz]

Perhaps all this energy should be redirected toward the Signal project?

[DiagonalArg]

Perhaps all this energy should be redirected toward the Signal project?

I use Signal, but these are not at all interchangable.

[kallisti5]

I loved keybase mostly because of the cool file gateway thing via keybase.pub. Now that keybase.pub is shut down, honestly signal is a pretty good alternative if you're not into matrix.

Signal's client + server are open sourced too. (though, the server is java 🥴 🤮 ) I've personally abandoned any hope that Zoom will open-source the server component at this point.

[DiagonalArg]

honestly signal is a pretty good alternative

Teams, fileshare, github, identity. No, Signal is not an alternative.

[huyz]

No one is saying it's an alternative today.

Think potential

[frju365]

Is there any alternative to keybase with server part opensourced ? Indeed I want to use this software for private cloud use.

[GwynethLlewelyn]

Replacing Keybase with Signal is, mmmh, how should I put it... essentially restricting Keybase to one of its many useful features, namely, 'encrypted advanced chat/messaging'. While that is certainly one of Keybase's many uses, and possibly the most popular feature in the client (and the one that still gets many regular updates here on GitHub!), it's not the only thing that Keybase does well. While I have Keybase chat always open (one of the few chat apps that I'm willing to have 'always on'), and certainly love it, I think that reducing Keybase's usefulness and interest just to 'yet another chat' is, well, unfair.

Also, it's highly likely that the core server components are all written in Go. Signal is written in Rust — a completely different programming language, conceptually alien to Go's simplicity, and which would require a profound amount of work to backport.

Granted, the client application is Electron/JavaScript, and that could certainly be integrated into Signal, but I would think that Signal already has pretty good client applications and doesn't need another one.

This, of course, is just my humble opinion.

There are a few tricks and technologies which are similarly employed by Signal and Keybase, namely, the Double Ratchet algorithm for keeping track of cryptographic signatures. The implementations, however, are quite different, and very likely incompatible. Notably, Keybase's backups are stored on the Stellar blockchain (formerly on Bitcoin's!), but it's conceivable that it could be stored on any blockchain supported by Go. Signal implements its own representation of a Merkle tree. Strictly from a conceptual point of view, Keybase's environment is more advanced and allows many more use cases than Signal ever does (or will do). Granted, it's arguable that what Signal does, it does very well, and possibly in a more robust and efficient way than Keybase (which was not designed to support hundreds of thousands of simultaneous users in text chat) — I don't know, I never did any benchmarking, I'm just assuming this to be the case.

[kallisti5]

All fair points. Signal does 5% of what Keybase did.
Keybase is as close of a product i've seen to an end-to-end user friendly gpg secured communication ecosystem.

There are no real alternatives (unless someone improves the UX of keyoxide.org), which makes this whole bug cut deeper.