Hm, I worry this isn't explicit enough. Do you have a specific reason for why this is a thing we should do?

In D4436#69390, @durin42 wrote:

Hm, I worry this isn't explicit enough. Do you have a specific reason for why this is a thing we should do?

Honestly, I did this to make the subsequent patches easier. The way I'm going with the partial clone work, it is likely we'll need the peer to consult the capabilities data structure directly instead of trying to map everything to a string lookup (which is what capable(name) is doing). Specifically, for things like changesetdata, we'll likely start exposing the available data fields in the capabilities dict and clients will want a way to check if a specific field is available.

So there's a good chance capable(name) isn't long for this world. At least not on version 2 peers. Things are still evolving.

Hmm. I'm still uneasy about this. Maybe we could make it a dev-mode thing and not be something we depend on long term?

In D4436#69564, @durin42 wrote:

Hmm. I'm still uneasy about this. Maybe we could make it a dev-mode thing and not be something we depend on long term?

I think an outcome of our VC yesterday was you were OK with this. IIRC you thought this was a server-side thing. When in fact this code runs on the client and is inventing e.g. command-changeset capabilities so code can check for the existence of a command via an artificial capability. In the future, v2 peers will likely expose the raw capabilities dict and we'll do something more intelligent for sniffing features.