I'm adding his section to provide context and inform development, because a request for context came up in discussion. There are no requirements below - this describes the things that other people will do with your code - it's the closest thing to a use case I could document in the time I had.
*** We intend to do the following with this data right away:
1) Demonstrate blockchain integration by proving that we can record and track value immutably and that our system of value transfer is mathematically verifiable (this is the first demo of spacelaunch integration - also part of that demo are a listing protocol and a digital key management system). Mechanically, in it's simplest form, a few python processes running on servers completely separate from the drupal site would pull a json file from spacebase.co and evaluate it, store a copy, and write a hash of that json file to a blockchain.
2) White-hat attack spacebase.co, spacelaunch.co and integrations as thought experiments and by soliciting help from the community in proving our model, and by proving out our ideas with programmatic efforts. (this will allow us to uncover and develop appropriate countermeasures like delays, human checks and balances, and other mechanics - which will all ultimately make it into the spacelaunch whitepaper). Mechanically, in it's simplest form, this would simply be a discussion between security professionals about gaming the contribution credits system, with some live experiments.
*** We intend to do the following with this data in the future:
Give contributors credit on spacelaunch.co. Where industry members have agreed to sponsor individual contributions, products can be redeemed for credits.
Give contributors a way to donate their contribution credits to projects. These donations are a form of voting that is super-powered, as the credits can be redeemed with vendors who have approved the project to redeem contribution credits for product.
*** A couple more notes:
I will just note for fun that the idea of redeeming for a digital product is quite powerful. We are building a digital fulfillment system as part of spacelaunch - digital products can be like coupons - redeemable in the future for available product whose value is not constant to a given currency.
Finally, as with everything else, we should keep in mind that we will need to debug this. If the drupal site gets cracked, for instance, we will need to shut it down, identify bad actors, roll back and invalidate bad data, close the holes and re-enable the system.
*** Some things will need to query:
Here are the types of queries I envision right off the bat:
Site Members
Contribution Types
Time Period
*
Blog
march 23rd nzdt
1-3
*
all-time
27
*
last 24 hours
We can make more than one query to get what we want (within reason).
In GitLab by @richbodo on Dec 24, 2018, 17:46
Summary
Expose a list of contribution credits to an external system in json. See also the Contribution Credits spec
Uses
I'm adding his section to provide context and inform development, because a request for context came up in discussion. There are no requirements below - this describes the things that other people will do with your code - it's the closest thing to a use case I could document in the time I had.
*** We intend to do the following with this data right away:
1) Demonstrate blockchain integration by proving that we can record and track value immutably and that our system of value transfer is mathematically verifiable (this is the first demo of spacelaunch integration - also part of that demo are a listing protocol and a digital key management system). Mechanically, in it's simplest form, a few python processes running on servers completely separate from the drupal site would pull a json file from spacebase.co and evaluate it, store a copy, and write a hash of that json file to a blockchain.
2) White-hat attack spacebase.co, spacelaunch.co and integrations as thought experiments and by soliciting help from the community in proving our model, and by proving out our ideas with programmatic efforts. (this will allow us to uncover and develop appropriate countermeasures like delays, human checks and balances, and other mechanics - which will all ultimately make it into the spacelaunch whitepaper). Mechanically, in it's simplest form, this would simply be a discussion between security professionals about gaming the contribution credits system, with some live experiments.
*** We intend to do the following with this data in the future:
Give contributors credit on spacelaunch.co. Where industry members have agreed to sponsor individual contributions, products can be redeemed for credits.
Give contributors a way to donate their contribution credits to projects. These donations are a form of voting that is super-powered, as the credits can be redeemed with vendors who have approved the project to redeem contribution credits for product.
*** A couple more notes:
I will just note for fun that the idea of redeeming for a digital product is quite powerful. We are building a digital fulfillment system as part of spacelaunch - digital products can be like coupons - redeemable in the future for available product whose value is not constant to a given currency.
Finally, as with everything else, we should keep in mind that we will need to debug this. If the drupal site gets cracked, for instance, we will need to shut it down, identify bad actors, roll back and invalidate bad data, close the holes and re-enable the system.
*** Some things will need to query:
Here are the types of queries I envision right off the bat:
We can make more than one query to get what we want (within reason).