Deprecation Notice: This daemon and its use of IPNS has been depricated in favor of blockchain addresses managed by a contract and DApp
The Cancer Gene Trust
The Cancer Gene Trust is a simple, real-time, global network for sharing somatic cancer data and associated clinical information. It's architecture is a decentralized, distributed content addressable real-time database. Stewards working directly with patient-participants publish de-identified genomic and basic clinical data. Researchers who find rare variants or combinations of variants in this global resource that are associated with specific clinical features of interest may then contact the data stewards for those participants. A submission consists of a manifest containing fields and references to files by multihash. Initial submissions will likely include de-identified clinical data, a list of somatic mutations, and gene expression data although any type of data can be submitted and shared.
The Cancer Gene Trust Dameon
The Cancer Gene Trust Daemon (cgtd) stores steward submissions in a distributed, replicated and decentralized content addressable database. It provides a basic HTML interface and RESTful API to add, list and authenticate submissions as well as the peering relationship between stewards.
search.cancergenetrust.org is an example search engine across all current stewards that builds a searchable index with network viewer.
Submissions consist of a JSON manifest with a list of fields and files. Fields typically include de-identified clinical data (i.e. tumor type). Files typically consist of somatic variant vcf files and gene expression tsv file. Manifest's and files are stored and referenced by the multihash of their content.
Eash steward has a top level JSON index file containing it's dns domain, list of submissions by multihash and list of peers by address. Each steward has a public private key pair which is used to authenticate their submissions. A steward's address is the multihash of their public key. A steward's address resolves to the multihash of the latest version of its index. Updates to a steward's index file are signed using their private key. This provides authentication and authorization for its contents as well as any other content referenced via multihash within it including all submissions.
Running a Production Instance
Note: The only dependencies for the following is make and docker-compose
Start cgtd and ipfs daemons with data stored in a docker volume:
Reset the steward's index to no submissions, no peers, set a domain:
DOMAIN=lorem.edu make reset
To verify both cgtd and ipfs are working you can query your steward's address:
To make a test submission:
or via curl:
docker exec -it cgtd curl -X POST localhost:5000/v0/submissions \ -F "a_field_name=a_field_value" \ -F files=@tests/ALL/SSM-PAKMVD-09A-01D.vcf
To access the submission:
Access control for mutable operations such as adding submissions or peers is restricted to localhost as a poor mans authentication. As a result we curl from within the cgtd container above.
To populate a server with a bunch of test data:
Finally to see the index for you server including submissions:
Build, Debug and Test Locally
Build a local cgtd docker container:
Start cgtd running using the local code with auto-reload:
This runs the cgtd container listening on port 5000 out of the local folder so you can make changes and it will live reload.
To run tests open another terminal window and: