Portable Cryptographic Authorship and Multi-Proof Artifact Bundles
- Signed Artifact Bundles Are Now Working End-to-End in Continuum
- The Important Part Is That Every Proof References the Same Artifact
- The Bundle Is Becoming the Durable Object
- Different Cryptographic Worlds Are Converging
- The Really Interesting Part Comes Next
- Composite Signing Authorities
Andrew G. Stanton - Friday, May 8, 2026
Signed Artifact Bundles Are Now Working End-to-End in Continuum
Yesterday I wrote that Continuum was becoming something broader than “a Nostr client.”
Today that became very concrete.
The full signed artifact bundle flow is now working end-to-end.
That includes:
- generating the bundle
- attaching all proofs
- generating manifests/signer metadata
- verifying the entire package locally
And the structure is no longer theoretical.
This is what an actual generated bundle now looks like:
2025_TaxReturn_continuum_signatures/
├── 2025_TaxReturn.pdf
├── 2025_TaxReturn.pdf.asc
├── 2025_TaxReturn.pdf.bitcoin-proof.json
├── 2025_TaxReturn.pdf.nostr-proof.json
├── 2025_TaxReturn.pdf.pgp-proof.json
├── 2025_TaxReturn.pdf.ssh-proof.json
├── manifest.json
├── pgp-public-key.asc
└── signers.json
I won’t share the actual artifact here (obviously) but I included one of the proofs, the manifest and the signers.json (all public)
2025_TaxReturn.pdf.bitcoin-proof.json
{
"address": "16H42vAEUBgr4Q5FVdvMLChNMGALrbgTLN",
"artifact_filename": "2025_TaxReturn.pdf",
"artifact_sha256": "da419c367bd572625fea4774d0fbcb1b64848c4bd5e353a56e3748591dfb0e8a",
"derived_public_key_hex": "0313a7b62bdcdb32209e4ffbb84f0dbd0a826e4138f59dbf9884f73f9241b2b813",
"identity_fingerprint": "3cecdfdc7f5b2d160887fb5c1ac60ae17ec9be2065a8ebff098836b2e8f1e1aa",
"identity_name": "16H42vAEUBgr4Q5FVdvMLChNMGALrbgTLN",
"message": "Continuum artifact attestation\nartifact_filename: 2025_TaxReturn.pdf\nsha256: da419c367bd572625fea4774d0fbcb1b64848c4bd5e353a56e3748591dfb0e8a\nsigned_at: 2026-05-08T20:20:34.675183+00:00\n",
"message_sha256": "de1e83af9f23217a14b676f6db56fd230ff5d2b4f89683a746ba192b0052b9bb",
"public_key_hex": "0313a7b62bdcdb32209e4ffbb84f0dbd0a826e4138f59dbf9884f73f9241b2b813",
"signature": "MEUCIQDsXzeJWtwcYIWHipwVgd4nkc5FCpmlQFbzEmavjcqBwAIgVP2Cx7TM/wamqjEIZKAVInoR2TZ03QxA7C1M991ZVl4=",
"signature_encoding": "base64_der_ecdsa_secp256k1_sha256_coincurve",
"signature_scheme": "ecdsa_secp256k1_sha256_coincurve",
"signed_at": "2026-05-08T20:20:34.675183+00:00",
"type": "continuum_bitcoin_artifact_attestation",
"version": 1
}
manifest.json
{
"artifact_filename": "2025_TaxReturn.pdf",
"artifact_sha256": "da419c367bd572625fea4774d0fbcb1b64848c4bd5e353a56e3748591dfb0e8a",
"created_at": "2026-05-08T20:20:35.150512+00:00",
"includes_bitcoin_proof": true,
"includes_nostr_proof": true,
"includes_pgp_proof": true,
"includes_pgp_public_key": true,
"includes_pgp_signature": true,
"includes_signers_json": true,
"includes_ssh_proof": true,
"type": "continuum_artifact_signature_bundle",
"version": 1
}
signers.json
{
"artifact_filename": "2025_TaxReturn.pdf",
"artifact_sha256": "da419c367bd572625fea4774d0fbcb1b64848c4bd5e353a56e3748591dfb0e8a",
"created_at": "2026-05-08T20:20:35.150512+00:00",
"signers": {
"bitcoin": {
"address": "16H42vAEUBgr4Q5FVdvMLChNMGALrbgTLN",
"derived_public_key_hex": "0313a7b62bdcdb32209e4ffbb84f0dbd0a826e4138f59dbf9884f73f9241b2b813",
"identity_fingerprint": "3cecdfdc7f5b2d160887fb5c1ac60ae17ec9be2065a8ebff098836b2e8f1e1aa",
"identity_name": "16H42vAEUBgr4Q5FVdvMLChNMGALrbgTLN",
"proof_file": "2025_TaxReturn.pdf.bitcoin-proof.json",
"public_key_hex": "0313a7b62bdcdb32209e4ffbb84f0dbd0a826e4138f59dbf9884f73f9241b2b813",
"signature_encoding": "base64_der_ecdsa_secp256k1_sha256_coincurve",
"signature_scheme": "ecdsa_secp256k1_sha256_coincurve",
"signature_type": "bitcoin_secp256k1_artifact_attestation"
},
"nostr": {
"identity_name": null,
"npub": "npub19wvckp8z58lxs4djuz43pwujka6tthaq77yjd3axttsgppnj0ersgdguvd",
"proof_file": "2025_TaxReturn.pdf.nostr-proof.json",
"pubkey": "2b998b04e2a1fe6855b2e0ab10bb92b774b5dfa0f78926c7a65ae08086727e47",
"signature_encoding": "hex_schnorr_secp256k1_sha256",
"signature_scheme": "schnorr_secp256k1_sha256_coincurve",
"signature_type": "nostr_schnorr_artifact_attestation"
},
"pgp": {
"email": "andrewgstanton@gmail.com",
"fingerprint": "B480CC987E0BAA6D5962EBAABF2E7F14860D3FB0",
"identity_name": "Andrew G. Stanton",
"key_algorithm": "Ed25519 (EdDSA)",
"proof_file": "2025_TaxReturn.pdf.pgp-proof.json",
"public_key_file": "pgp-public-key.asc",
"signature_file": "2025_TaxReturn.pdf.asc",
"signature_type": "pgp_detached_signature",
"subkeys": [
{
"algorithm": "ECDH",
"id": "DE8888788F1628BF"
}
],
"user_ids": [
"Andrew G. Stanton <andrewgstanton@gmail.com>"
]
},
"ssh": {
"identity_fingerprint": "SHA256:HRNyprnaZz+8kvBKwk7K4Cpept0tnH1dgCU0Ivmw0rM",
"identity_name": "SHA256:HRNyprnaZz+8kvBKwk7K4Cpept0tnH1dgCU0Ivmw0rM",
"key_algorithm": "RSA",
"proof_file": "2025_TaxReturn.pdf.ssh-proof.json",
"public_key_openssh": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDJL6Hjgc8K8KVLi3xth+9UiuC6czgvr0YJsy9qAaCBhntszVRTW8/whjnSMnS/MiDZEdV0z8Em0fkAZ7yj76r6m/8Sm8xGBcC2MKR9lDH2sbeiWa2+NKxHBlmXCCp/Ftc21eUbhpVRWe0afm1JQg50xk34Rg61BVjpSALoOSzmq/Cy/XDxqcgNCeul26cuLPi/6hINhIopMZSg/W3LcvR+YBu6hk6tz47bZsat9xGOWO5ZK0RAumOIXuxHfziZ81VXVk77bV8EyzKNjhHO4Z0rervTghUUGzf8izQwLij95mwIhi2ekJS56p1x6da4YmwJUNWOWpUGAkKljNN+tPvH2YWOQu88Td5IHdCMDbN77rMAvq4skMIR3bbN3HNJCOWrMQ7Wggj61sdMCHOFYkGghWaA62MwxGNe2++KGczYLZpsMI/blJD3Aa22OBamR2/9mtSlbaa5kmyOwk5j2KtkyqI+PJJQtO+6p0UmJXnEZqy1TbAqcaPMUeFUOfrrF1fdC32uIPbyzRcnMxmd4a/NJqxbQpryJWpsWAmfzndjUFNFCcPm+9BIVVWWcIyB2kYeJNq+Ooz4p877lQ5JRJ9hKKVNqdSFCJMNZEXiXv4Da/6SPyG5xD3UZ0ERe2bURfALKsfcJCD4BgTZIOkBxU/WZUV5Ns99TfIibMSVHNi5Ww==",
"signature_encoding": "base64",
"signature_scheme": "ssh_rsa_pkcs1v15_sha256",
"signature_type": "ssh_artifact_attestation"
}
},
"type": "continuum_artifact_signers",
"version": 1
}
This is not a mockup.
These are all from an actual generated Continuum signing bundle.
At this point Continuum supports:
- Nostr signing + verification
- PGP signing + verification
- Bitcoin signed attestations + verification
- SSH signing identities + verification
inside the same local-first workspace.
The Important Part Is That Every Proof References the Same Artifact
The verifier flow works by recomputing the artifact hash locally and validating every included proof against that exact artifact.
That is the key.
For example:
- the Nostr proof attests to the artifact hash
- the Bitcoin signed message attests to the same artifact hash
- the PGP signature validates against the artifact
- the SSH proof validates against the same canonical payload
So the verifier is effectively asking:
“Do all of these cryptographic identities independently attest to this exact artifact?”
If the answer is yes:
- the artifact has not changed
- the proofs are valid
- the signer metadata matches
- the attestations are internally consistent
No relay required. No cloud verification service required. No external platform required.
Just the artifact bundle itself.
The Bundle Is Becoming the Durable Object
This feels important because the center of the architecture is shifting.
Most modern systems revolve around (except of course for Nostr!)
- accounts
- servers
- hosted platforms
- SaaS databases
But here the durable object is the signed artifact bundle itself.
The proofs travel with the artifact.
The verification metadata travels with the artifact.
The signer metadata travels with the artifact.
The bundle itself becomes portable cryptographic authorship.
Different Cryptographic Worlds Are Converging
Another thing that became very obvious while building this:
these proof systems originated from completely different domains.
PGP came from:
- email trust
- software signing
- decentralized verification
SSH came from:
- infrastructure authorization
- machine access
- operational trust
Bitcoin signing came from:
- sovereign monetary identity
- address ownership
- cryptographic attestations
Nostr came from:
- decentralized publishing
- relay-based distribution
- event authorship
Yet underneath all of them is the same primitive:
cryptographic authority attached to an artifact.
Continuum is now treating those systems as interoperable proof layers around the same signed object.
The Really Interesting Part Comes Next
Now that the verify flow is working, the bundle can evolve over time.
For example:
I can generate a signed bundle locally.
Another Continuum user can:
- verify every proof
- inspect the manifests/signers
- add their own attestations
- regenerate the package
- pass it forward again
At that point the bundle becomes more than authorship.
It becomes portable multi-party attestation.
For example:
- several Nostr users independently attesting
- multiple Bitcoin identities signing the same artifact
- multiple PGP signers approving a release
- multiple SSH authorities validating infrastructure artifacts
All independently verifiable.
All portable.
All local-first.
And importantly: without requiring a blockchain consensus layer or centralized signing authority.
Composite Signing Authorities
Another direction I’m now thinking about is the idea of a composite signer.
Right now the identities are independent:
- one Nostr identity
- one PGP key
- one Bitcoin signing identity
- one SSH identity
But increasingly it makes more sense to think in terms of grouped signing authorities.
For example:
“Andrew Stanton” could internally contain:
- multiple Nostr identities
- multiple PGP fingerprints
- several Bitcoin signing identities
- several SSH identities
Then Continuum could apply all configured proofs automatically when generating the bundle.
That abstraction feels much closer to how real-world cryptographic trust actually works.
Individuals and organizations rarely operate through a single key.
They operate through overlapping cryptographic authorities.
Continuum is starting to model that directly.
Write a comment