From sending to verified receipt
The factual order of an online transfer: order, acceptance, encrypted frames, verification and a signed receipt.
The sequence below is the same for every online transfer; profiles differ only in how the file bytes travel:
- 1. Read capabilities, destination and rightsControl and permissions
- 2. Prepare the source, bind the order cryptographicallyControl and permissions
- 3. Create the signed order with a stable IDControl and permissions
- 4. Accept, or decline with a reasonControl and permissions
- 5. Begin an allowed transport attemptControl and permissions
- 6. Encrypted frames, directly or through a relayFile data
- 7. Transport acknowledgements per chunkFile data
- 8. Check content, size and hash; store safely depending on the profileControl and permissions
- 9. Submit the signed receiptControl and permissions
- 10. Read the result and verify the receiptControl and permissions
The acceptance can be triggered by a person or by a receive policy that was explicitly set up beforehand. A group job bundles the consent; its members keep separate receipts. A group is therefore not an atomic database transaction across all file systems: one member can be done while another waits for space or a connection.
A lost API response does not prove that the operation never happened. IDs and signed content are therefore preserved before retries. The same ID with different content is not an allowed “update”. Version checks prevent an old response from overwriting a state that has changed since.
Related guides
Architecture: control and file data are separate
A transfer has two jobs: decide who may send what to whom, and move the encrypted bytes. pipeit keeps them apart.
Resuming: acknowledgement, checkpoint and receipt are different
Five signals that sound alike and mean different things, and what resuming actually keeps.
Encryption: file content, keys and signatures
Which standard algorithms protect a file sent from device to device, what each one does, and what the profile does not promise.