4 ms·

> But to be clear, you're actively diverting from the point. ... I get why you showed up here, but you're really not addressing the point of the post at all,

> But to be clear, you're actively diverting from the point. ... I get why you showed up here, but you're really not addressing the point of the post at all, and in fact you're trying to distract with the suggestion that Signal's publication of that code protects people from this flaw. It doesn't. At all. Wow, that's a pretty hostile (and accusatory) response to a fair ask. This is one (small) step removed from accusing someone of shilling/astroturfing. Let your product stand on its own merits. If you have a good reason why you won't open source Keybase's server implementation, own it. Don't undermine requests to open source the code by publicly accusing people of supporting a competing product. The person you're replying to didn't make an argument in favor of Signal - or any other competing product, for that matter. In my opinion, your response is actively distracting from their request.

drexlspivey 8y ago
Even if they publish their server code there is no way for anyone to verify that it's the code they are actually running and it would be just a PR move. If the client implementation is good there should be no way that the server can compromise any message.
- throwawaymath 8y ago
  Okay, and that's exactly the kind of reasoned response that's appropriate. What's not appropriate is implying the request is simply unfounded because of its source. It's not charitable.
- elagost 8y ago
  It's a step toward people running their own servers, either federated with Keybase proper, or just as a personal instance. That would be valuable for quite a number of enthusiasts. Federation (like email/XMPP) is a very reasonable feature for any forward-looking communication platform.
  - sethgecko 8y ago
    Then this is not a request for transparency but for them to change their business plan
  - chupasaurus 8y ago
    Keybase's target is to become a central identity point. Other features (like team chat and git repos) are made to showcase what you could do with that.
malgorithms 8y ago
Fair enough - I don't want to dilute my point by coming across as too hostile, even though my point is that it seems like a well-crafted diversion. Let me edit it down and your quote of the original can stand.
- mhluongo 8y ago
  You don't need to apologize IMO ¯\_(ツ)_/¯
mhluongo 8y ago
I think it's a pretty reasonable way to combat FUD. It's tough to compete on security because users struggly to know what's actually better (on top of needing convincing security is a worthwhile differentiator in the first place). A client that doesn't trust a server is a great improvement and "show us the server" is a terrible response.
- throwawaymath 8y ago
  Then the reasonable thing to do is to explain why it's a terrible response. What's unreasonable is to imply that the request is a sideshow in favor of a competing product because of the identity of the person who brought it up. If you have a good reason not to fulfill the request, charitably responding to the request with that reasoning is an educational opportunity for the audience. There's just no need to bring identities into the mix like this, and I think a dispassionate response outlining why the server need not even be trusted would stand on its own.
throwawaylolx 8y ago
Well, equally, GP could've disclosed their conflict of interests instead of just using a hit&run one-line red herring. OP makes a post advocating not having to trust a server, and most upvoted comment is someone asking them to open their server so they can trust it? Doesn't make much sense..
- throwawaymath 8y ago
  Agreed, they could disclose a conflict of interest. But I don't think it matters here, because their request could reasonably have been brought up by someone unaffiliated with Signal. In other words - you don't need to be affiliated with Signal to be in favor of open sourcing the server-side code. It's a fairly common complaint on HN, and I can see why it was the top comment for a while even if I don't ultimately agree with the need to open source the code. Likewise, if you look at the link to the GitHub issue you can see many other people likewise asking for - or reacting to responses to - open source the server code. Do all those people have conflicts of interest? Is it possible that the affiliation with Signal doesn't matter here? Then be charitable, and let your actual reason for not fulfilling the request stand on its own.

drexlspivey 8y ago

Even if they publish their server code there is no way for anyone to verify that it's the code they are actually running and it would be just a PR move. If the client implementation is good there should be no way that the server can compromise any message.

throwawaymath 8y ago
Okay, and that's exactly the kind of reasoned response that's appropriate. What's not appropriate is implying the request is simply unfounded because of its source. It's not charitable.
elagost 8y ago
It's a step toward people running their own servers, either federated with Keybase proper, or just as a personal instance. That would be valuable for quite a number of enthusiasts. Federation (like email/XMPP) is a very reasonable feature for any forward-looking communication platform.
- sethgecko 8y ago
  Then this is not a request for transparency but for them to change their business plan
- chupasaurus 8y ago
  Keybase's target is to become a central identity point. Other features (like team chat and git repos) are made to showcase what you could do with that.

malgorithms 8y ago

Fair enough - I don't want to dilute my point by coming across as too hostile, even though my point is that it seems like a well-crafted diversion. Let me edit it down and your quote of the original can stand.

mhluongo 8y ago
You don't need to apologize IMO ¯\_(ツ)_/¯

mhluongo 8y ago

I think it's a pretty reasonable way to combat FUD. It's tough to compete on security because users struggly to know what's actually better (on top of needing convincing security is a worthwhile differentiator in the first place). A client that doesn't trust a server is a great improvement and "show us the server" is a terrible response.

throwawaymath 8y ago
Then the reasonable thing to do is to explain why it's a terrible response. What's unreasonable is to imply that the request is a sideshow in favor of a competing product because of the identity of the person who brought it up. If you have a good reason not to fulfill the request, charitably responding to the request with that reasoning is an educational opportunity for the audience. There's just no need to bring identities into the mix like this, and I think a dispassionate response outlining why the server need not even be trusted would stand on its own.

throwawaylolx 8y ago

Well, equally, GP could've disclosed their conflict of interests instead of just using a hit&run one-line red herring. OP makes a post advocating not having to trust a server, and most upvoted comment is someone asking them to open their server so they can trust it? Doesn't make much sense..

throwawaymath 8y ago
Agreed, they could disclose a conflict of interest. But I don't think it matters here, because their request could reasonably have been brought up by someone unaffiliated with Signal. In other words - you don't need to be affiliated with Signal to be in favor of open sourcing the server-side code. It's a fairly common complaint on HN, and I can see why it was the top comment for a while even if I don't ultimately agree with the need to open source the code. Likewise, if you look at the link to the GitHub issue you can see many other people likewise asking for - or reacting to responses to - open source the server code. Do all those people have conflicts of interest? Is it possible that the affiliation with Signal doesn't matter here? Then be charitable, and let your actual reason for not fulfilling the request stand on its own.