Add possibility to "sign" ERCs

[nuest]

An ERC must be subject to human inspection.

How can we model and trace the involved people in a way that is open to scrutiny?

Examples: reviewers "sign" an ERC which they examined and evaluated, librarians add their signature on receiving and checking a submission to an archive, an author does a self-check and confirms "to his best knowledge" the ERC is OK. Could possibly be done by storing files in the .erc directory.

And blockchains are suppossed to be good for this stuff, too...

[ghost]

good idea. Does this include the possibility of their public keys to create a cryptographic signature? The journal could even give out crypto keys with the mandate of reviewing a specific work, which is then used by the designated reviewer.

[nuest]

Yes, public keys and cryptographic signatures are what I had in mind, just didn't find the right words. Thanks!

[ghost]

Okay, lets work this out. How about a space for a signature in erc.yml?

Something like:

signature:
  version: "GnuPG v1.4.13 (GNU/Linux)"
  text: "iEZEARECAAYQAnHZCvgACgkQ5IGFtbBWdrF5HgCfc4xhT29uoAWdo1PMlyDKIfaqpGoAoKig8sCXukrPPoKC1ZYB5CR7BvNL=WPPL"

[nuest]

How about multiple reviewers? What is the meaning of the signature: did somebody read something, or author the ERC, or reproduce it?

I don't expect this to be part of the spec any time soon. Would you like to add this now?

[ghost]

I think it's a valuable addition but not a trivial one. It would require to depict the state of the publication somehow in the ERC. The signature then could serve as checkpoints for each stage of the process. But since the ERC is for published items, it does not really fit. Important steps in my opinion are:

• Signed submission by the submitting author
• Signed review for each reviewer (using the journal's review key, if reviewers are supposed to stay anonymous)
• Signed publication by the editor
• Signed successful reproduction would belong into a blockchainish future

[edzer]

Nice to have, but I think that identity management of people involved is sufficiently handled by OAuth and Orcid IDs. Let Orcid think about stronger identity management; this is not up to us. Most scientist won't have a key, many won't even know what it is. Even CRAN packages can't be signed (yet).

Thinking about trust by reviewers/users in general: do ERCs inform you what they require and will do with your system, like apps on your phone? This ERC will:

• require 16 Gb of RAM
• require at least 2 CPUs, use maximally 8
• need 12 hours of runtime to reproduce
• use 200 Gb of mounted disk drive on the local system, as swap space

"Do you agree? Yes/No"

[ghost]

I agree that OAuth handles ID management in a sufficient way. The advantage of a signed ERC would be that with the included signatures, the trust handling would be independent of any infrastructure, which in my opinion strengthens the concept of the ERC as a self-contained, comprehensible entity. But I'm ready to let go of that in the current perspective of the project.

Better communication with the user in terms of information on the system requirements is another, no less important, aspect of the idea of trust. It leads to the question of who is providing the resources necessary to store and run an ERC. Currently our reference implementation is doing the calculations on the server side and the ERC is meant to be stored elsewhere, in a scientific repository. A reviewer has a different role than a user. They would want to download and inspect the whole thing closely on their own machine and would in fact better be presented with estimated requirements.