files: a file row's name and media type travel in cleartext in the signed envelope

[emooreatx]

files::publish (edge v32.1.0, src/files.rs ~L340) builds the file:v1 row envelope with filename (FIELD_FILENAME), the room target (cohort_target_field = the room's content id; for a self file, the owner's identity key id), and the BlobPointer, which carries media_type. All of it is in cleartext. The BYTES are sealed (tier InvisibleEncrypted for a self file), and the pointer's content_sha256 is the at-rest hash, so the content stays private. The file's DESCRIPTION does not.

Why it matters now: CIRISServer's selffiles ladder, run 36278132685, measured another person's peered node holding the owner's self file rows, with names readable (contract (signed).pdf, archive.zip, screenshot.png, …). How they got there is CIRISPersist#919: the #530 consent sweep widened them to federation. That is fixed in persist v50. But even after that, the name is readable by anything that stores the row legitimately: a relay, a holder, and any node that ever receives the row through a future widening defect. Existence metadata then fails OPEN, not closed.

Ask: seal filename (and optionally media_type) under the room's content key, beside the bytes or as a small sealed metadata field in the pointer. files::open / FileRef would return them after the room DEK opens. A room member sees no difference; anyone else sees a row with a pointer and no name. If a cleartext hint is needed for routing or policy, name the field and why.

Server side: CIRISServer's drive reads FileRef.filename and needs no change beyond adopting the sealed form.

🤖 Generated with Claude Code

[emooreatx]

From persist: no persist change is needed for this. Persist reads neither filename nor the pointer's media_type anywhere — no vocabulary path, no schema gate, no admission rule names them (the media Source struct of v45 / CC 3.3.13 is a separate path that carries format/codec/size for byte verification; if you ever encrypt format there, CC 5.3.2.6's sniffed-essence check would have to run after a member decrypts, but the file pointer's media_type is not that struct). An encrypted name is an opaque string to persist and rides through every gate as today.

On whether it should hold 0.5.218: after persist #919 (v50.0.0), a self-room row is never republished, and self/family rows project SelfOwn (CC 5.2 structural invisibility: never advertised, never offered), so post-v50 the only nodes that legitimately store a self file row are the owner's own devices. A community room's members are meant to read its file names. So this is defence in depth against a future holder-side leak, not the open path the ladder measured; I would not hold 0.5.218 on it. Persist v50 is in final certification.

[emooreatx]

Read against the Constitution and edge's own docs before touching code. The cleartext name is CC-conformant; sealing it unilaterally would fork a CC-defined shape. Not a blocker for 0.5.218.

What the CC says.

• CC 3.3.13, the multimedia Source struct (ruling CIRISConstitution#104, normative). The common field set is a descriptor — members of the signed row: digest, size (REQUIRED, checked before hashing), format (IANA essence), codec, layout hints, placeholder, name — "display only; RFC 6266 §4.3 sanitised; never selects a decoder or a save path", content_digest ("plaintext hash when digest is over ciphertext — community+ scopes, per-epoch HPKE"), derived_from. The encrypted two-hash case borrows Signal / NIP-17 for exactly one thing: the second hash. name and format stay descriptor members. So edge's file:v1 row (filename + pointer.media_type in clear, bytes sealed) is the CC's shape, and CIRISNodeCore FSD/MEDIA_SHARING.md §4 pins the schema — a sealed name would be an interop fork.
• CC 5.2 scope note + CC 1.13.3.1 non-goals. Structural invisibility "buys content-holding confidentiality only — it is NOT relationship-existence, metadata, traffic-analysis, or unobservability privacy"; metadata privacy is listed as explicitly out of scope, and "treating [it] as provided is an error". Privacy for a file row is audience: self/family rows never leave the collective (no holds_bytes, no row beyond it); community rows reach members' nodes (edge's audience gate; persist's EncryptedCohort table says community bytes are sealed and their existence deliberately NOT suppressed). Whoever legitimately holds a file row can open its bytes — the name adds nothing they lack.
• Edge precedent. Chat seals the message body under the room key and leaves the envelope (room id, author) clear — the body is content; a file's name is, per the CC, descriptor metadata, sanitised so it can drive nothing.

What the selffiles run actually found was the CC 5.2 breach: a self/family row on another person's node. That is CIRISPersist#919 (the widening predicate), fixed in v50, and the right invariant to check is "no self/family file row is held by a node outside the owner's collective" — the negative already on #919. A check that fails "whenever a file name appears in cleartext in any row" would fail every conformant community row and should not be added.

Where the concern is legitimate, and whose call it is. A user-authored name can be content ("contract (signed).pdf"), and Signal / NIP-17 do put name and mime inside their seals. If that protection is wanted, it is a Constitution question — CC 3.3.13: in the encrypted two-hash case, should name (and format) move inside the seal, with content_digest the only plaintext link? — to file on CIRISConstitution, weighed against the stated metadata non-goal and against what the row must still carry in clear for holders and relays (digest, size, the room target). Edge implements whatever that ruling says; it should not pre-empt it. Until then this issue is a design question, not a bug; I'd re-title it that way or close it with a pointer to the CC filing.

[emooreatx]

Maintainer's position: move it inside the seal — readable only if authorized, and protected at rest (the directory row tables are not sealed; the bytes are; a sealed name rides the room DEK and its per-occurrence wraps). Filed as a Constitution ruling request on CC 3.3.13's encrypted two-hash case: CIRISConstitution#114 (name + format inside the seal; digest, size, the room target, content_digest and placeholder stay clear). This issue becomes edge's implementation of that ruling: files::publish seals name + media type as a sealed descriptor member under the room key; files::open / FileRef return them after the DEK opens; the self/family and community paths both; conformance vectors for the encrypted case; the server reads FileRef after open (no change beyond adopting). Ships with the ruling, alongside CIRISNodeCore's MEDIA_SHARING schema change, so the shape moves together. Not a blocker for 0.5.218; the 0.5.218 negative stays #919's (no self/family row outside the collective).

[emooreatx]

CIRISConstitution#114 landed as proposed. The shape edge builds here, exactly as persist will gate it (posted on #114 by persist):

• sealed_descriptor on the Source struct: base64 of an AEAD seal under the room DEK over the JCS object {name, format, codec?}, with the blob's address digest as associated data (a descriptor cannot be moved between blobs).
• Always in clear, required: size, the address digest, the room target, content_digest (encrypted case), placeholder.
• format / codec: in clear iff sealed_descriptor is absent; when it is present they must be absent in clear (persist refuses both-present as "one description"). name is never in clear beside a seal.
• Sniff (CC 5.3.2.6): by the opener, where the bytes decrypt.

Edge's implementation (this issue): files::publish seals {name, format} under the room key with the digest as AAD and writes sealed_descriptor, omitting filename/media_type in clear; files::open / FileRef return name and media type after the DEK opens (a row a reader cannot open yields a pointer, size and no description — by design); both the self/family and community paths; the file:v1 conformance vectors gain the sealed case; the server's drive reads FileRef after open, unchanged. Sequencing: persist's gate ships in the cut after v50.0.0; edge's producer ships in the same cut (a mixed fleet must not see a member the older gate refuses), so this is edge v33.x on that persist tag, not v33.0.0. Asked persist to confirm how v50.0.0 treats a row carrying sealed_descriptor from a newer producer.

[emooreatx]

Sequencing settled, from persist's gate code (not belief): persist v50.0.0 admits a file:v1 row that carries sealed_descriptor and omits a clear format, as long as the row carries no top-level media member — persist's media gate (check_media_source) runs only on a non-null media Source struct, and edge's file rows carry the pointer under content (edge's own pointer struct) with no media member (persist grepped edge's writers at d34df2f: none emits media). So an extra member inside content rides through opaque; a v50 reader stores the row and shows no name.

The caveat that binds this issue and #638 together: the moment a producer emits persist's media Source struct on a row, v50 refuses a sealed one (that struct is closed — an unknown member is refused by name — and requires format in clear). CIRISPersist#922 changes that gate in the cut after v50. Therefore:

• files: a file row's name and media type travel in cleartext in the signed envelope #698 ships on edge's schedule (v33.0.0 is fine): sealed_descriptor lives inside edge's content pointer (base64 AEAD under the room DEK over JCS {name, format}, AAD = the address digest), filename/media_type omitted in clear; FileRef returns them after the DEK opens. No fleet floor needed.
• CC 5.3.2.6 / 3.3.13 (CIRISConstitution#104 rc5): sniff-after-SHA at the adopt door (sniffed essence == declared format, refusal by name), size before hash, BlobPointer carries the Source struct, rendition placement, published render policy #638's adoption of persist's media Source struct on file rows must wait for CIRISPersist#922 (the gate that admits sealed_descriptor in media); until then the seal stays in the pointer, and CC 5.3.2.6 / 3.3.13 (CIRISConstitution#104 rc5): sniff-after-SHA at the adopt door (sniffed essence == declared format, refusal by name), size before hash, BlobPointer carries the Source struct, rendition placement, published render policy #638 is sequenced after that persist cut.

[emooreatx]

Design landed as an FSD-only PR; the producer is blocked on one persist door. FSD/CONTENT_TRANSFER.md §6.7.1 (+ the pointer table) writes the #114 contract, the key rule (the SAME DEK as the bytes — the pointer's tier/community/epoch — so "may read the name" and "may open the bytes" are one fact), the reader postures, the mixed-fleet rule (seal inside content, no media member, until CIRISPersist#922), the at-rest property and invariants D1–D7.

Why not built: edge never holds a DEK. Its only seal is GroupContentStore::seal → put_blob_scoped (persist resolves the cascade inside and returns a pointer at a NEW blob), and persist v49/v50 exposes no door that seals small caller bytes under an existing blob's DEK and returns the ciphertext — at_rest_cascade::seal/open are pub but take the DEK; there is no DEK reader. Sealing the descriptor as a second blob would give the same authorization but not the ruled inline member, and would fork the shape #922 gates. So, rather than approximate:

Persist ask (to file beside CIRISPersist#922):

Engine::seal_descriptor_for_blob(at_rest_sha256: &[u8;32], key_id: &str, plaintext_jcs: &[u8]) -> Result<Vec<u8>, BlobError>   // AEAD envelope bytes; caller base64s
Engine::open_descriptor_for_blob(at_rest_sha256: &[u8;32], viewer_key_id: &str, sealed: &[u8]) -> Result<Vec<u8>, BlobError>

DEK = the one that blob was sealed under (its recorded tier / community / epoch — same grants gate both calls; NotGranted when the viewer cannot open the bytes); AAD = the blob's address digest as #114 rules, framed by persist exactly as chunk AAD is; envelope = at_rest_cascade::AtRestEnvelope bytes. With it, edge's producer is one call beside seal and the opener one call beside open; D1–D7 land then.

[emooreatx]

Blocked on a persist door, by design not by shortcut — the descriptor must seal under the bytes' own DEK, which edge never holds (its only seal is put_blob_scoped, cascade resolved inside persist). Filed CIRISPersist#923 (Engine::seal_descriptor_for_blob / open_descriptor_for_blob: DEK = the blob's, AAD = address digest persist-framed, envelope = AtRestEnvelope, same grants as read_blob_as), to ship with #922. The design is merged separately as PR #699 (FSD/CONTENT_TRANSFER.md §6.7.1 + the pointer table, invariants D1–D7 with named witnesses); the producer/reader land here the moment the doors exist — one call beside seal, one beside open.

[emooreatx]

CIRISPersist#923 accepted as filed, for the cut after v50.0.0 alongside #922: Engine::seal_descriptor_for_blob / open_descriptor_for_blob — DEK = that blob's via the same cascade, AAD = the address digest framed as chunk AAD, AtRestEnvelope out, NotGranted/Withdrawn exactly as read_blob_as, a fixed plaintext bound, a typed refusal for a blob with no DEK (plaintext/federation-scope blobs never get a sealed descriptor — the encrypted case only, as #114 says), plus a Python opener so CIRISServer's FileRef read needs no edge FFI. Persist's witnesses include the AAD binding and edge's D1–D7 vectors. Edge's producer/reader here ship in the edge cut on that persist tag.

[emooreatx]

#923 contract updated with all four amendments, each marked by evidence status (persist, 2026-09-27): caller_aad on the opener — accepted, row-transplant witness beside the blob-move one (D8); one access set per stream — holds today on the EPOCH axis (a stream binds to one epoch at first append, #837 I41/I17; a later-epoch append is refused) and is UNVERIFIED for per-chunk occurrence wraps on self/family streams across a mid-write occurrence change — #923 asserts exactly that witness on sqlite and postgres, and if it fails the sealer fixes its recipient set at stream open; the v51 release note will say TESTED or BUILT, never assumed (D9 reads accordingly); name optional inside the seal — accepted (D10); media_type: None — accepted by the API today, and "stores no format claim anywhere (metadata NULL, no member on the holds_bytes claim)" is a #923 witness, not a claim (D2's every-row assertion has its persist-side twin).

[emooreatx]

Second review pass folded in (PR #700, docs-only) — the producer's contract in one place:

• Write API: SealRequest gains Description { name: Option<String>, format: String, codec: Option<String> } (replacing the bare media_type). GroupContentStore::seal / seal_chunked see persist's resolved tier in SealedContent.tier and decide after it is known: encrypted tier → media_type: None to put_blob_scoped/seal_stream_scoped, description sealed through Engine::seal_descriptor_for_blob, pointer carries sealed_descriptor + clear size/content_digest(/placeholder), no clear format/codec; plaintext tier → format passed through, pointer carries clear format/codec, no seal. The producer never chooses.
• Read API: FileRow::open (bytes only) unchanged. New FileRow::open_described(store, viewer) -> Result<Opened { bytes, descriptor: Descriptor }, UnopenedReason>, Descriptor::{Clear{format,codec?,name?}, Opened{format,codec?,name?}, Sealed}; opened with the same door as the bytes (Engine::open_descriptor_for_blob with the row's caller_aad), so Ok never carries Sealed; Sealed is the listing's word for a held-but-unopenable row; FileRow.filename/media_type stay the clear members (None on a sealed row).
• Rules: one description (a clear media_type/codec/filename beside a seal is refused by name); placeholder optional, clear when present; name: None = absent-by-author, never an empty string.
• Witnesses D1–D10 as in FSD/CONTENT_TRANSFER.md §6.7.1; D2 runs once per resolved tier over every substrate row.
  Builds on the persist cut carrying #922 + #923.

[emooreatx]

Implemented in v33.0.0 (draft PR #710) against persist v51: seal {name?, format, codec?} under the file's DEK via seal_descriptor_for_blob; the store decides seal-vs-clear after persist resolves the tier; encrypted pointers carry clear size + content_digest, no clear format/codec/name anywhere on any row; open_described opens bytes then descriptor. D1–D8, D10 pass (D6 on real sqlite at both encrypted tiers). Seal location: inside edge's content pointer — v50 readers refuse a sealed media struct, so #638 item 3 waits for a v51 fleet. Open with persist (v51.1): the shipped open_descriptor_for_blob lacks the accepted caller_aad parameter — edge is safe by ordering (bytes open under the row AAD first), but direct callers (incl. the Python opener) could read a transplanted pointer's descriptor; D8 pins current behaviour and flips when persist adds it. D9's stream-access-set half is persist's witness, not yet marked TESTED.