Secret Request
Ask someone to send you a password or sensitive data — unreadable even to the server.
The question is encrypted here in your browser before it is sent, with the key traveling in the response link's fragment (after the #). The recipient's response is encrypted with a public key generated just for this request — only whoever holds the matching private key, which exists solely in the recovery link, can read it afterwards. The full mechanics are described in "How Secret Request works", below.
Shown to the recipient as "[name] is asking for something sensitive".
Only you see it, on the recovery page — useful to tell several open requests apart.
Extra password required to view the request and respond — agree on it through another channel; it is not part of the link — 0/128
How Secret Request works
When you create the request, your browser generates two different keys and encrypts the question locally. The server keeps only the encrypted question and the expiration date — and returns TWO links: one for the recipient to respond, another just for you to recover the response later. When the recipient responds, their browser encrypts the response with the public key you generated on creation — only the matching private key, which exists solely in the recovery link, can open it afterwards.
Why two links, not one
In Secret Share, a single link is enough because whoever creates it and whoever reads it are, in practice, the same person who already knows the content. Here it's the opposite: whoever responds must not be able to recover the response afterwards (otherwise anyone intercepting the response link would gain that same power), and whoever recovers it does not need the response link. That is why the two roles travel on separate links with different powers — never mix them up, and never send the recovery link to someone who should only respond.
Why Nexinon cannot read either the question or the response
The question uses the same zero-knowledge design as Secret Share: the key lives in the response link's fragment (after the #), which the browser never sends to any server. The response uses public-key cryptography (ECDH) instead: the recipient encrypts with the requester's public key, but only the matching private key — which exists solely in the recovery link's fragment — can decrypt it afterwards. At no point does the server hold a key capable of opening either the question or the response.
When to use the passphrase
Without a passphrase, whoever has the complete response link can view the request and respond — which is already safe when the sending channel is trustworthy. The passphrase adds a second factor for less trustworthy channels: it takes part in deriving the key that protects the question, so the response link alone becomes insufficient. Send the link through one channel and agree on the passphrase through another. Verification happens in the recipient's browser, before anything is sent — getting it wrong never wastes the single accepted response.
Frequently asked questions
They are inverses. With Secret Share, you send a ready-made secret for someone to read. With Secret Request, you ask someone to send you a secret — you create the request, share the response link, and read whatever arrives through a second, private link of your own.
The response becomes unrecoverable — by design, the server never held the private key that decrypts it, and it exists only in that link's fragment. There is no way for Nexinon to recover it for you. If this happens, close the request (if you still have the response link) and create a new one.
No — each request accepts a single response. A second attempt is rejected, and the page shows that the request has already been answered, never overwriting the first response.
Not yet — Nexinon does not send e-mail or notifications in this version. Return to the recovery link and click "Refresh" to check manually.
No — unlike Secret Share, the response stays available on the recovery link until you close the request manually or it expires. You can reopen the page and read it again as many times as you need.
You shouldn't: whoever holds that link can read the response and close the request at any time. Treat it with the same care as the response itself — only the response link is meant to be shared.
No — it is a courtesy from whoever creates the request (any text can be typed there), not an authenticated identity. Treat it like the sender of a greeting card: useful for context, not proof of origin.
It's just for you: a short text (e.g., "Maria Silva — Frontend") shown on the recovery page, to tell several open requests apart. The recipient never sees it — it is encrypted with a key that exists only in your recovery link.