search

CatholicBlockchainOrg / SacramentalRegistry

Storing sacramental records on the blockchain
7 stars 2 forks source link

JSON Objects #3

Open xerocrypt opened 6 years ago

xerocrypt commented 6 years ago

I recommend extending the JSON record to include the following fields:

    {
        "name": "Fulton Sheen",
        "cname" : "Francis",
        "type": "BAPTISM",
        "diocese" : "Peoria",
        "registrar" : "RCADC",  
        "date" : "10.01.1944",
        "year" : "1944",
        "signed" : "EF53A3B65CA6D"
    }

Reasons: a) For privacy, we want to encrypt fields and and anonymise records, but we also want the dataset to be queryable. The 'registrar', 'year' and 'cname' (confirmation name) are enough to find a record without identifying the subject before the fields are decrypted. b) The 'signed' field was included because the registrar should be able to sign the record with his private key, so it could be verified as a true record.

dquinn40 commented 6 years ago

These all seem like great ideas to me. Do you want to create a pull request to update the records?

xerocrypt commented 6 years ago

Oh, that would be lovely. I've been looking at a few APIs that might be useful and was about to fork the project. Even if the blockchain thing turns out to be untenable (a lot would need to be developed around it for usability and privacy), at least this project would have produced a schema for parishes, organisations, sodalities, etc. to follow. Also, for a blockchain, I think there would be another two fields, one a hash digest of the current block, and the other a digest of the previous block. #

dquinn40 commented 6 years ago

Admittedly I need to learn a lot more about blockchain technology, especially how Ethereum works, but I believe privacy and security is a fundamental problem it tries to solve. That being said, extra security/privacy around the contents of our system is never a bad idea in my mind.

The JSON record I created was not intended to be a block itself. It is just intended to be representative of the type of data our contract will work with. As you mention, that schema will evolve quite a bit before its viable. As to how its stored, Im not sure. I believe there are options(e.g. on or off the chain, etc). It seems Devin has some ideas(IPFS) about that. I'm excited to learn more about how all this works.

To your last point about current and previous hashes, I don't think those are needed since this information would never be a block itself, just the payload of a block.