rich1.0Geek (npub1m2…r3wgu)https://yabu.me/npub1m2jphmdkskgnvwl5gplksl9e0zwv2sldqf9mwlpz6tyymz84g9fsqr3wgunjumphttps://yabu.meGood 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.