Stream only uses entries secured by personally identifiable digital signatures in an immutable ledger in order to track proofs of task completion. JLINC as well as a multi-ledger connection to a blockchain(s) each provide a perfect architecture to submit these proofs to, being programmable, immutable, and natively allowing for personally identifiable digital signatures through cryptography.
When a user (either a volunteer or an offeror) signs up in for an action or event, offer, or experience in the Stream network, Stream creates a secret cryptographic string (known as a private key) for them, based upon a password provided by the user/volunteer. The private key will be reinforced with other pseudo-random input, so two users with the same password will not coincidentally have the same private key. This private key, through a standard mathematical process, may derive into a shareable cryptographic string (known as a public key), which may be freely shown as part of the process of proving one’s identity.
As a volunteer completes a task, they will use the Faya Bot, Dashboard, or Wallet to submit an entry to the common ledger protocol ensuring its recoding on a chain via JLINC. The JLINC record, and Holochain or blockchain will contain the following data, encrypted with the volunteer’s public key:
- The proof that the task was completed (possibly a link to a photo, a pre-arranged code, etc)
- The specific time the task was completed
The entry will also have a UPI, or Universal Profile Identifier, an MC2 Universe specific identifier that uniquely identifies the task that was completed, left unencrypted, anywhere across the MC2 Network. This is how Stream powers many ecosystems.
The Flow on a Stream Network via Aether will continuously read the Holochain, or blockchain, searching for entries that match this payload. When one is identified, the identifier for the task will be read and compared to the internal ledger of offers in Flows in the Stream. The encrypted payload will then be forwarded to the offeror, who may decrypt the payload with their private key. After decryption, they will either confirm that the task has been completed or deny that it is completed. If it is confirmed, the volunteer will be forwarded the claim instructions set forth in the original offer. If it is denied, the volunteer will be notified as well.
In this way, a secure, one-to-one communication of proof is established between the offeror and the volunteer, in a way that is auditable forever.