{
  "txid": "63a21cec72619690b7d90f1c41db995aee697de04c54df2053c6adf866398c7f",
  "block_height": 0,
  "time": null,
  "app": "treechat",
  "type": "post",
  "map_content": "Progress is steady.\r\n\r\nThe issue with creating platforms like PeerMark, is that more often than not \u2014 we become innovators. Leaders of the technological space, having to conquer issues that have not yet even been considered.\r\n\r\nThis becomes especially difficult when attempting to create working, reliable, secure machine logic whilst maintaining complete self-sovereignty, and self-custody.\r\n\r\nRobustness which remains at scale is important. Nobody wants a platform/app which throws constant errors when under stress/load. Seamless, smooth, and secure.\r\nWhen registering confidential assets on-chain, it's important that the contents remain just that \u2014 confidential.\r\n\r\nTherefore, for 'Confidential' verification/storage, I opted for a flow as follows:\r\n\r\n1. Upload file(s) to browser\r\n2. Select \"Confidential\" mode\r\n3. See message: \"No file leaves your device. We publish only a fingerprint.\"\r\n4. Optionally toggle \"Include original file in package\" (for backup)\r\n5. Set access terms (if any)\r\n6. Sign with wallet (biometric + password)\r\n7. MUST download .pmrk package and confirm backup\r\n8. See success with verification instructions\r\nThis allows us to create a '.pmrk' package file, with plenty of details (and automatic file-alteration detection) to either verify, or show specific error messages upon rejections.\r\n\r\n\u2014 \u2014 \u2014 \u2014 \u2014\r\n\r\nThe .pmrk package is a self-contained ZIP archive that serves as the user's canonical proof of registration.\r\n\ud835\ude4b\ud835\ude40\ud835\ude40\ud835\ude4d\ud835\ude48\ud835\ude3c\ud835\ude4d\ud835\ude46  \ud835\ude4b\ud835\ude3c\ud835\ude3e\ud835\ude46\ud835\ude3c\ud835\ude42\ud835\ude40 (.pmrk) \ud835\ude3e\ud835\ude4a\ud835\ude49\ud835\ude4f\ud835\ude40\ud835\ude49\ud835\ude4f\ud835\ude4e:\r\n README.txt | Human-readable instructions and verification guide | \u2705 \r\n manifest.json | Package metadata (mirrors on-chain + local-only fields) | \u2705 \r\n content.enc | AEAD-encrypted ciphertext | \u2705 \r\n canonicalised/ | Canonicalised bytes used for contentHash | \u2705 MANDATORY \r\n raw/ | Original file at registration time | \u274c Optional \r\n packageIndex.json | SHA256 checksums for integrity/rename detection | \u2705 \r\n\r\n\u2014 \u2014 \u2014 \u2014 \u2014\r\n\r\nThis allows us to store important 'references' to the original files, whilst confirming what that file actually was, and what it contained remains in-tact and unchanged \u2014 without actually 'seeing' the contents. No 'database' storage, no 'on-chain' file storage, just somewhat clever references.\r\n\r\n \u2014 \u2014 \u2014 \u2014 \u2014\r\n\r\nAll of this seems somewhat pointless, if your wallet is easily compromised. So, another challenge is ensure a completely self-sovereign, self-custodial wallet which can easily be referenced by our Platform to ensure it always remains connected to your PeerMark account, with specific rules when it comes to 'recovering' lost access.\r\n\r\nTherefore; PeerMark uses a fully self-sovereign security model, with all sensitive material encrypted client-side and controlled solely by the user. Storage is split across the following several locations:\r\n\r\nDevice share \u2014 encrypted in localStorage using a WebAuthn-derived key\r\nDevice metadata \u2014 stored locally as public, non-sensitive information\r\nRecovery share \u2014 encrypted with a password-derived key and stored on the server\r\nUser backup \u2014 a plaintext seed phrase kept only by the user\r\nWallet state \u2014 public information stored both locally and server-side\r\nRecovery is designed around three straightforward scenarios:\r\n\r\nIf a device is lost, the user logs in on a new device, verifies their email, enters their account password, and the recovery share is decrypted to enrol the new device and restore the wallet.\r\nIf a password is forgotten, the user authenticates via WebAuthn, enters their seed-phrase backup, reconstructs the backup share, and generates a new recovery share with a fresh password.\r\nIf both device and password are lost, the user simply enters their seed phrase, completes an additional email check, and recreates the remaining shares on a new device.\r\nBecause PeerMark never holds any plaintext shares, it cannot decrypt recovery data or spend funds on a user\u2019s behalf. Even a database breach would expose only encrypted blobs, useless without user-derived keys. This architecture ensures the wallet is entirely controlled by the user, and since all encryption happens client-side, adding KMS or HSM services would increase complexity without offering any real security advantage.\r\n\r\nThe access model is designed so that only the user can ever combine the required shares, while every other party remains strictly limited. In practice:\r\n\r\nThe user can access all three shares once they\u2019ve authenticated, giving them full control of their wallet.\r\nPeerMark can only see an encrypted recovery blob and cannot access any plaintext shares or the master key.\r\nThe user\u2019s device can access the device share after biometric authentication but cannot view or reconstruct any other shares.\r\nAn attacker gains nothing without meeting multiple independent factors and therefore cannot access anything of value.\r\nThis structure ensures that no single party \u2014 other than the user \u2014 ever has enough information to act on the wallet.\r\n\r\n \u2014 \u2014 \u2014 \u2014 \u2014\r\n\r\nThis is often not just development, but innovation. Combining various logics and conjuring a methodology that could shape and elevate standards across organisations for years to come, in a desperate bid to retain privacy when it's needed most, with the ability for the user to verify it when necessary.",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "14aqJ2hMtENYJVCJaekcrqi12fiZJzoWGK",
  "display_name": "Casey",
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 7,
  "timestamp": "2025-12-02T18:30:17.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "attachments": [],
  "ui_name": "Casey",
  "ui_display_name": "Casey",
  "ui_handle": "Casey",
  "ui_display_raw": "Casey",
  "ui_signer": "14aqJ2hMtENYJVCJaekcrqi12fiZJzoWGK",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}