Good push, and I've folded the format into the spec so it's fully interoperable, and any client can encrypt/decrypt from just the file key. One clarification though since I think we're picturing different things, but please correct me if I'm misunderstanding.
There are no chunk references stored in the event. It's still one blob with one sha256 and a single key. The "segments" are purely an internal AEAD framing of that one blob's bytes (encrypt in 64 KiB segments, concatenate into the one blob), not separate blobs and not a chunk list. So it's encryption segmentation, not storage chunking.
That distinction matters because keeping it to one content-addressed blob is what lets dedup, redundancy counting, and hash-healing keep working, splitting a file into N separately-referenced blobs would break all of that. The segmentation gives us the thing you actually want (bounded memory / no OOM at any file size, streamed encrypt and decrypt) without giving that up.
And it's a fully specified format now, so any app is interoperable with it: 64 KiB AES-256-GCM segments, per-segment nonce = 11-byte big-endian counter ‖ 1-byte last-segment flag, tag per segment. A file that fits in one segment is just the N=1 case, so small and large files use the same path. Nothing client-private.
Geek
npub1m2…r3wgu
2026-07-22 13:51:30 UTC
in reply to nevent1q…hz3f
Author Public Key
npub1m2jphmdkskgnvwl5gplksl9e0zwv2sldqf9mwlpz6tyymz84g9fsqr3wguPublished at
2026-07-22 13:51:30 UTCEvent JSON
{
"id": "aee5d39711f08d4c709536446662c6a8956082c23ea652f4bf1d9baf1e521ee0",
"pubkey": "daa41bedb68591363bf4407f687cb9789cc543ed024bb77c22d2c84d88f54153",
"created_at": 1784728290,
"kind": 1,
"tags": [
[
"e",
"884cff2bc034e5ffb45a2beaa41f4a9cbf125569ec66cd787af339feb1716b22",
"",
"root"
],
[
"e",
"417b0b5419e24eed6787c407f57c2e999d4c61e8fcea2e0e5647b826addb36ab",
"wss://relay.mostr.pub",
"reply",
"c21b1a6cdb247ccbd938dcb16b15a4fa382d00ffd7b12d5cbbad172a0cd4d170"
],
[
"p",
"daa41bedb68591363bf4407f687cb9789cc543ed024bb77c22d2c84d88f54153"
],
[
"p",
"c21b1a6cdb247ccbd938dcb16b15a4fa382d00ffd7b12d5cbbad172a0cd4d170",
"wss://relay.mostr.pub"
]
],
"content": "Good push, and I've folded the format into the spec so it's fully interoperable, and any client can encrypt/decrypt from just the file key. One clarification though since I think we're picturing different things, but please correct me if I'm misunderstanding. \r\n\r\nThere are no chunk references stored in the event. It's still one blob with one sha256 and a single key. The \"segments\" are purely an internal AEAD framing of that one blob's bytes (encrypt in 64 KiB segments, concatenate into the one blob), not separate blobs and not a chunk list. So it's encryption segmentation, not storage chunking.\r\n\r\nThat distinction matters because keeping it to one content-addressed blob is what lets dedup, redundancy counting, and hash-healing keep working, splitting a file into N separately-referenced blobs would break all of that. The segmentation gives us the thing you actually want (bounded memory / no OOM at any file size, streamed encrypt and decrypt) without giving that up.\r\n\r\nAnd it's a fully specified format now, so any app is interoperable with it: 64 KiB AES-256-GCM segments, per-segment nonce = 11-byte big-endian counter ‖ 1-byte last-segment flag, tag per segment. A file that fits in one segment is just the N=1 case, so small and large files use the same path. Nothing client-private.",
"sig": "313832e99fbe39d2ebe2b414a3681515a5fec3a4fc8f0881ab932849590969db0f488ca55701998e0d8a532789cdea4627c0d41e08899e4b6d53457c8069b588"
}