[craftyguy]

No, the server implementation is proprietary. Therefore, it's a walled garden that relies entirely on them. Supporting federation would be going above/beyond just releasing the server implementation's source under a permissive license. As it stands today, you have no choice but to rely on their proprietary server implementation, since the clients are useless on their own.

[twr]

Considering the whole point of end-to-end encryption is to reduce or eliminate necessary trust in the middleman, this seems like a minor, but still valid concern. Open sourcing the backend code wouldn't allow you to attest to what's running on the server. If the clients also allowed you to point to a custom server URL, which I would support, then the source availability might matter.

[craftyguy]

Without the proprietary server backend, you cannot use the clients. It's a walled garden. If keybase goes away for whatever reason, you're stuck. You cannot host it yourself, others cannot host it, and even if they released binaries, you'd have no idea what it is doing with the unencrypted 'metadata'.

[twr]

I didn’t dispute the description of Keybase being labeled a walled garden. I opposed it being too-broadly called proprietary, when it’s not — only the backend is. And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective, which is the reason people usually (mistakenly) bring up source code availability.

Now I’ll also partially dispute the accusation of it being a walled garden, since walled gardens don’t have open specifications and documented APIs for third-party client implementations.

The backend source code would be good to have, for the prudent reason you pointed out, as well as for private instances, but that’s not enough: you also need client code modifications to allow configuration for custom servers.

About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)

[craftyguy]

> And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective

Gosh, not really. They completely control who can use the service, and any information they 'require' to register for the service.

> since walled gardens don’t have open specifications and documented APIs for third-party client implementations.

I'd like to point out that walled gardens will still openly invite folks to join, and give them tools that they could reproduce, but give them no way to experience the garden outside the walls.. including the tools previously given that are also useless outside the walls. That's exactly the case with keybase.

> About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)

Huh. I'm interested in hearing how having source code makes autiting more difficult, since that has not been my experience.

[twr]

I agree with you that Keybase should release their backend code. My comment about (server source code- derived) trust was made in the context of users who would remain using the official keybase.io API servers, which would probably be the vast majority of Keybase users.

It’s not all of the time, or even most of the time, but frequently there are reasons for preferring binaries:

- build systems which are more annoying to setup than just straight reading the assembly / IL dump (ex: android)

- you might want to reverse and/or edit the binary anyway — to look at compiler output, as one example

- it’s sometimes faster to understand the asm than it is to go over the code, compile it, and compare [non-]matching binary outputs (this is regularly true for smaller programs)

- the tools for analyzing binaries are often more advanced than code tools