Sharing a file once is a workflow problem, not just an encryption problem: NoSus design questions

I'm Shubham, the developer of NoSus, a sharing product built with Flutter/Dart, Supabase/Postgres, Deno functions, and a Next.js website. I would appreciate technical and usability feedback on the boundaries between encryption, access controls, and what the interface promises.

A file-sharing interface has to answer several different questions:

• Can the recipient open it without an account?
• Does a read consume access, or can the same link be reopened?
• What does revocation stop after a recipient has already opened or downloaded something?
• Does a displayed name or email prove who the viewer is?

NoSus has an account-free Burn tool at https://nosus.foo. Its direct links carry encryption keys in the URL fragment. However, single notes/files also generate a two-digit redemption code: the corresponding key remains server-side temporarily while that code is valid, even when someone uses the direct link. That distinction matters when describing the security model.

The document-sharing workflow uses viewer-entered email watermarks, activity logs, and revocation. An entered email is an attribution clue, not verified identity. SecureSend is access-controlled rather than end-to-end encrypted. Revocation cannot erase screenshots, printed pages, or downloaded copies.

Here is a small test with no confidential content: create a dummy Burn note, copy its link, open it in another browser, and attempt a second open. Note which steps are unclear and whether the result matches what you expected.

For developers who build sharing flows, I would value feedback on:

1. Which UI wording best distinguishes future-access revocation from erasing an existing copy?
2. What failure cases would you prioritize testing for a one-time claim, particularly concurrent opens or an interrupted connection?
3. How would you explain the server-held redemption-key window without hiding it behind a generic encryption badge?

Please keep any security findings non-sensitive in public replies. This is a request for critique of my own product, not a claim that a forum discussion constitutes a security audit.