/Docs/S/About/Pitch/Support/DRY_Transacting_v0.md
  Source views: Source JSON(ish) on GitHub (VSCode)   Doc views: Document (&k=): Visual Print Technical: OpenParameters Xray
(Sec = (Ti = Object Model for (DRY = DRY)
(P2P = Peer-to-Peer)
Transacting)


(sec = (0.sec = )
(xlist = (Olist =
  1. (Secs = (secs = (1.sec = Each person has one or more (PDSs = Personal Data Stores)
    .)

  2. (2.sec = A (PDS = Personal Data Store)
    consists of (Cmacc = Cmacc)
    "(lists = lists)
    " and other files. The (lists = lists)
    are formatted as files (canonical) or as records in a database, for instance a graph database.)

  3. (3.sec = The user can manage the (lists = 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 = lists)
    . This can be improved by interfaces and apps.)

  4. (4.sec = Transactions are done by creating and synchronizing some new (list = list)
    s across the (PDSs = 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. (5.sec = A preferred way to synchronize is to exchange (lists = 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 = lists)
    . More advanced payment systems such as blockchains may automate transaction flows and conditions.)

  6. (6.sec = 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, (PDSs = Personal Data Stores)
    can make a "(DRY = 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. (7.sec = Access to a (PDS = Personal Data Store)
    may be managed directly by the owner of the (PDS = 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 = 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. (8.sec = The permissions, requests, and receipts for access can be handled like other transactions in the system - each is a transaction stored in the participants' (PDSs = Personal Data Stores)
    , and subject to agreement regarding discarding.)

  9. (9.sec = See, e.g., http://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provenance_11182015.pdf)
    )
    )
)

)

(00.sec = )
)

)