Ok, I’ve had a little time to dig into things. Here’s a report on my progress with some questions.
I’m modified my review system so that when a user creates a review for a document, a certificate is also created.
Here’s the result of creating a test review:
http://dll-review-registry.scta.info/reviews/bbcb46fa-0675-4b47-a580-61ef7761b50b.html
(NOTE: discourse is only letting me embed two links because I’m new, so subsequent links are prefaced with "link
At the time of creating a review, the document being reviewed is pinned to the ipfs network and given an ipfs hash. (For example: linkhttp://gateway.scta.info/ipfs/QmZfPbMDGZ4cbpw3oB9q7kscqA72aCsjFg2X3iW791QG1z)
This hash is then sent to my custom certificate creator, which uses the ipfs hash the identify of the “recipient”.
This unsigned-certificate is likewise pinned to the ipfs network and its hash is recorded.
(For example: http://gateway.scta.info/ipfs/QmYygcQHHpCErEKj97FfvbUVuT8snUBgiSncgRvjo5F46v)
In creating the certificate, I think I’ve tried to follow the basic schema for making an assertions. I used one of the example unsigned certificates in the cert-issue examples folder (linkhttps://raw.githubusercontent.com/blockchain-certificates/cert-issuer/master/examples/data-testnet/unsigned_certificates/3bc1a96a-3501-46ed-8f75-49612bbac257.json)
As an aside I tried running both this example certificate and my own certificate in the OpenBadges validator (linkhttp://validator.openbadges.org/) and there were various errors. I’m not yet sure if the blockcert certificates are supposed to pass OpenBadges validation or not.
With my unsigned certificate created, I then started testing verifying the certificate on a test blockchain with the cert-issue docker set up.
This basically worked.
Note that cert-issue rejected the certificate until I changed the recipient[“type”] to “email” instead of “url” or “string”. I’m not sure if I’m missing something there or the schema needs to be adjusted to allow a document to be a recipient.
But once I change recipient[“type”] to email, I was successfully able to sign the certificate.
Once, the certificate has been signed, I suppose I’ll need to add that to IPFS as well and the update the registry record with the hash of the signed certificate rather than the hash of the unsigned certificate. (Perhaps I’ll preserve both.)
This leads me to a few questions.
- Once I have the signed certificate, I have successfully been able to find the transaction using the
"sourceId": "79925bf920bfa56b428384de7a774e22e70f66a244cae2faee24f2a485f8bdc9"
and
bitcoin-cli gettransaction 79925bf920bfa56b428384de7a774e22e70f66a244cae2faee24f2a485f8bdc9
But I’m not able to find a new block that contains this transaction.
In fact, if I run bitcoin-cli getblockcount I continue to get 101. No matter how many times I run cert-issuer -c /etc/cert-issuer/conf.ini the count is still 101, which makes me think that no new blocks are being created. Should I expect a block to be created after running cert-issuer -c /etc/cert-issuer/conf.ini? Or am I missing something.
In any case, when the block is created, should I be able to easily move from the transaction id or the merkleRoot to the corresponding block or at least discover the hash of the block containing this merkleRoot or transactionid? What bitcoin-cli command would allow me to do that?
- Second, even if I succeed in signing the certificate and verifying it on blockchain, I still feel like I’m going to need some sort centralized index that allows a user to discover if a document has a certificate.
Certainly if a user begins with the signed certificate, they’ll easily be able to find the document that has been approved (through the recipient field). Likewise, they’ll be able to use signature to find the verification on the block chain.
This is I think is exactly what @kim describes
However, in general I expect the dominant use case to be the other way around. Namely, a user or client application will begin with a document or url to a document, and they will want to know are their any reviews/certificates for this precise document.
While the blockchain will be able to confirm that the certificate has been issued for a precise document, it won’t be able to answer the question, are there any certificates for this document?
Thus my feeling is I’m still going to need a kind of registry (as I have running now in production linkhttp://dll-review-registry.scta.info/reviews/bbcb46fa-0675-4b47-a580-61ef7761b50b.html) that connects documents with certificates. This service allows a user to supply the ipfs hash or shasum of the document and the learn if there are reviews/certificates for this document.
Once they have the ipfs hash of the associated reviews that can then use the certificate and block chain for any further verification. But I think I still need a services that helps people discover these certificates.
FYI, here’s a link to a little more context of what I’m trying to do: Ipfs and distributed peer review - Ecosystem - IPFS Forums. This is a related discussion on the ipfs discussion board.
I’m be really grateful for any thoughts or feedback. I’d love to hear if you think i’m on the right track or I missing something obvious.