Progress is steady. The issue with creating platforms like…

Progress is steady.

The issue with creating platforms like PeerMark, is that more often than not — we become innovators. Leaders of the technological space, having to conquer issues that have not yet even been considered.

This becomes especially difficult when attempting to create working, reliable, secure machine logic whilst maintaining complete self-sovereignty, and self-custody.

Robustness which remains at scale is important. Nobody wants a platform/app which throws constant errors when under stress/load. Seamless, smooth, and secure.
When registering confidential assets on-chain, it's important that the contents remain just that — confidential.

Therefore, for 'Confidential' verification/storage, I opted for a flow as follows:

1. Upload file(s) to browser
2. Select "Confidential" mode
3. See message: "No file leaves your device. We publish only a fingerprint."
4. Optionally toggle "Include original file in package" (for backup)
5. Set access terms (if any)
6. Sign with wallet (biometric + password)
7. MUST download .pmrk package and confirm backup
8. See success with verification instructions
This 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.

— — — — —

The .pmrk package is a self-contained ZIP archive that serves as the user's canonical proof of registration.
𝙋𝙀𝙀𝙍𝙈𝘼𝙍𝙆 𝙋𝘼𝘾𝙆𝘼𝙂𝙀 (.pmrk) 𝘾𝙊𝙉𝙏𝙀𝙉𝙏𝙎:
README.txt | Human-readable instructions and verification guide | ✅
manifest.json | Package metadata (mirrors on-chain + local-only fields) | ✅
content.enc | AEAD-encrypted ciphertext | ✅
canonicalised/ | Canonicalised bytes used for contentHash | ✅ MANDATORY
raw/ | Original file at registration time | ❌ Optional
packageIndex.json | SHA256 checksums for integrity/rename detection | ✅

— — — — —

This 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 — without actually 'seeing' the contents. No 'database' storage, no 'on-chain' file storage, just somewhat clever references.

— — — — —

All 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.

Therefore; 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:

Device share — encrypted in localStorage using a WebAuthn-derived key
Device metadata — stored locally as public, non-sensitive information
Recovery share — encrypted with a password-derived key and stored on the server
User backup — a plaintext seed phrase kept only by the user
Wallet state — public information stored both locally and server-side
Recovery is designed around three straightforward scenarios:

If 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.
If 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.
If 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.
Because PeerMark never holds any plaintext shares, it cannot decrypt recovery data or spend funds on a user’s 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.

The access model is designed so that only the user can ever combine the required shares, while every other party remains strictly limited. In practice:

The user can access all three shares once they’ve authenticated, giving them full control of their wallet.
PeerMark can only see an encrypted recovery blob and cannot access any plaintext shares or the master key.
The user’s device can access the device share after biometric authentication but cannot view or reconstruct any other shares.
An attacker gains nothing without meeting multiple independent factors and therefore cannot access anything of value.
This structure ensures that no single party — other than the user — ever has enough information to act on the wallet.

— — — — —

This is often not just development, but innovation. Combining various logics and conjuring a methodology that could shape and elevate standards across…