Keybase Proof Language (ToC and Discussion Ticket)

[maxtaco]

Keybase proof language will allow us to quickly change rules for client scraping, in case Twitter or Github et al make a breaking change. ... More details to come on this ticket ...

[maxtaco]

I think there are two compelling reasons to come up with a nice solution here: (1) as @chrisnojima says, to make it easy to push client fixes in the case of a calamity; and (2) to make it easier for people to contribute plugins to is (think: slack).

For instance, when working on the bitbucket scraper (from keybase/proofs#5), there are just a large number of things that need to change in both the proofs repo itself, and also in our keybase/keybase code tree. See keybase/keybase@d4ba923c4c1f79134cb0484697b9601af426876c for an example of all of the boilerplate.

I think the finished product here will be, for each bitbucket-like integration:

1. a JSON file that describes how clients can check and consume proofs
2. an additional ICS file that consumes the previous JSON file, and deals with all changes needed for:
   • proof display on the Web site
   • proof generation on the web site (via sig_modals)
   • proofd scraping include:
     • how to hunt
     • how to get bearer tokens (if needed)
   • proof checking and validation on the upload path.

Why two files and not one? The first file will change infrequently and should be pinned to the KB merkle tree. The second is internal and need not be so restricted.

[malgorithms]

I'm on board for both of these things:

1. the proof language, which can allow us to update the rules for verifying proofs easily, so clients can be corrected when there's an API or site change with partners
2. a generalization of proofs, for adding more proof types. This generalization will have a lot of considerations about the process for generating a proof, not just hunting. For example, consider:
   • Instagram, where the proof might be an image + text.
   • Facebook, which, like Twitter, will need a mini post, and which needs to walk the user through their post.
   • how these proofs can be done using apps that exist on the same platform; if I'm in the Keybase app and want to do proof on service X, the right answer might be to flip to app X, not some webpage.
   • different kinds of failures...we've been pretty weak on this. In reddit, the hunter should be able to report back that a user is shadowbanned. In coinbase, that their public page isn't set up. With web proofs, that their intermediate certificate is missing. With instagram or Twitter that their account is private. And so on. Each new service is going to have various kinds of very specific problems, and it's the hunter and/or verifier that needs to recognize and return them to a layer that presents them.

In terms of prioritization, I think 1 is more important, because we'll want to apply it to all our existing proofs.

[maxtaco]

Do you think it might make sense instead to fold 95% of the integrations into this framework, but still hand-code the important remaining 5% like instagram and FB?

[malgorithms]

I guess my point is that pretty much every integration we've had so far has had weird custom stuff about it. I know we can't swallow up all those generalizations, but I'm concerned how we can get to 95%. Or even 75%.

[malgorithms]

either way, these two things are separate issues, right? (1) the proof verification language, and (2) generalization of proofs across the board (hunting, etc.)?

[maxtaco]

they are, but i think we'd benefit from attacking them in tandem

[maxtaco]

The first question to resolve is should the scheme in (1) be a dumbed-down language, or should it be JS? I prefer the form if we can squeeze all of current proofs into it. Let's make a discovery ticket for that -- #962.