S/About/Pitch/Support/DRY_Transacting_v0.md
SourceEditDocumentPrintGitHubUsed ByEdit and Complete   Other "punctuations":  IPLDJAW
Object Model for DRY Peer-to-Peer Transacting
  1. Each person has one or more Personal Data Stores.
  2. A Personal Data Store consists of Cmacc "lists" and other files. The lists are formatted as files (canonical) or as records in a database, for instance a graph database.
  3. The user can manage the lists by adding, deleting, archiving, etc. the files. They can use tools such as text editors and git (and GitHub) to collaborate on collections of lists. This can be improved by interfaces and apps.
  4. Transactions are done by creating and synchronizing some new lists across the Personal Data Stores of the participants. This can be done by any method satisfactory to the participants. Some possibilities include git-based repos for the particular transactions, file attachments to emails, or sharing a server.
  5. A preferred way to synchronize is to exchange lists via payment systems, where signature and transfer of value is handled by the payment system. Payment systems give receipts which have key=values that can be used to record and reference lists. More advanced payment systems such as blockchains may automate transaction flows and conditions.
  6. In many circumstances, participants will not need to retain all of the details of a transaction. By automating access and using hashes to allow post-hoc verification, Personal Data Stores can make a "DRY" transaction system - where each element of data has a canonical source and all uses of that data consist of copies of the necessary portions that are discarded as soon as no longer needed.
  7. Access to a Personal Data Store may be managed directly by the owner of the Personal Data Store, but the owner may also arrange for a hosting service or other person to provide access. Hosting, and therefore reliable access, is particularly important in a DRY data environment where others may need rapid, reliable access to elements of the data. "Hosting" may be virtual, for instance on a blockchain or similar technology.
  8. The permissions, requests, and receipts for access can be handled like other transactions in the system - each is a transaction stored in the participants' Personal Data Stores, and subject to agreement regarding discarding.
  9. See, e.g., http://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provenance_11182015.pdf