Public, password and private shares

Every share is encrypted. The three types differ in how the decryption key reaches your recipient — and that one difference drives everything else.

Choosing

Rules of thumb:

• Posting to a forum or handing out widely → Public.
• Sending to someone you cannot get a token from, and a shared secret over a second channel is good enough → Password Protected.
• A known list of people, or anything sensitive → Private.

Public

The key is in the link, after the #.

usenet://<message-id>/<folder-id>#<key>

Anyone holding the link can open the share, so treat the link as the content. Once it is in a chat log, a forum post, a support ticket or a forwarded email, it is out, and there is nothing to revoke — the key is already in every copy.

Revoking means re-publishing to mint a new link, which invalidates the old one.

Fine for genuinely public material. A poor choice for anything you would mind a stranger having.

Password protected

You choose a password. The key is derived from it. The password is never uploaded and never stored anywhere.

Recipients need both the link and the password, so send them separately — a password in the same message as the link adds nothing at all.

The thing to be certain about

A forgotten password cannot be recovered. Not by you, not by us, not with a support ticket. There is no copy on any server to look up; that is the design, not a policy we could make an exception to.

Put it in a password manager at the moment you type it into the Upload page.

If it is lost, your only route is to re-publish the folder with a new password — which needs the original files still on your disk, and mints a new link.

Publishing order

Password shares upload first and take the password at the final publish step, so it is never held while the long upload runs. The app tells you this: "Password shares upload now, then need a final 'Publish' step with the password (we never store it)."

Watch for it — the upload finishing is not the end of the job.

Private

The strongest option. The key is wrapped individually for each recipient using their own public key, and the wraps are authorised by your signature.

Someone who is not on the list has no wrap to open, so a leaked link gets them nothing.

You need each recipient's identity token first

This is the part that catches people. The wraps are built at publish time, so the list has to exist before you publish.

What you ask them for. Tell your recipient:

Open UsenetShare → Settings → Identity → copy Your Identity Token and send it to me.

Is it safe for them to send? Yes. It is a public key plus a user id — their public address. It grants nothing on its own and cannot be used to impersonate them.

What it looks like. A userid.base64key string, or the full JSON with user_id and public_key. The app takes either.

Adding recipients

On the Upload page, under Authorized Consumers: paste the token, press Add Consumer, repeat.

On an existing folder: Recipients tab → add there. It also does bulk import and export, so you can hand a list between machines.

You are always included automatically. A private share with no other recipients is one only you can open — a reasonable way to keep an encrypted off-site backup.

Changing the list later

Edit the Recipients tab, then Re-Publish.

Two things follow, and both surprise people:

Changes do not take effect until you re-publish. Adding someone to the list does not give them access; the wraps have not been built yet. The folder shows a pending-changes state to remind you.

Re-publishing mints a new link and the old one stops working. Everyone — including existing recipients — needs the new link.

Removing a recipient works the same way: take them off the list and re-publish. Their old wrap is in the old catalogue, which the new link does not point at.

No data is re-uploaded for either. Only the catalogue is re-posted, so it is quick even on a huge share.

Consumer groups — for the same people repeatedly

If you publish to the same set of people often, do not paste tokens every time.

Settings → Sharing → Consumer Groups: New group, add members, name it (Family, Team, Beta testers). Then apply the group to any folder's recipients instead of adding people one at a time.

Groups export to JSON and CSV, so a list survives a machine move and can be handed to a colleague.

Switching a folder's access type

The Share tab can switch a published folder between Public, Password and Private and re-publish it.

The same rule applies: new link, old link dead.

Going from Public to Private is a genuine security improvement for the future — but be clear-eyed that the old public link already put the key in the hands of everyone who saw it. If that link leaked, the content behind it leaked. Switching to Private protects the new link, not the old bytes. Where that matters, re-publish the content as a new folder and treat the old share as burned.

What a recipient does

For completeness, so you can tell them:

Private is the easiest for the recipient. The work happens once, up front, when they send you their token.

Their side in full: Download a share.

Common problems

"No authorized recipients yet." The list is empty on a private publish. Add a token, or choose a different access type.

A recipient says access is denied. Almost always one of:

• they were added to the list but the folder was not re-published since
• they are using a different install from the one whose token you have — identity is per-install, so their laptop and their desktop are two different identities
• they are using an old link minted before they were added

A recipient sent a token that will not paste. Truncated in transit — the token is long and chat clients wrap it. Ask for it in a text file, or have them use 📋 Copy Full Identity (JSON) from the Identity tab instead.

You lost a password. Nothing to do but re-publish. See above.

You want to know who can open a share. The Recipients tab lists exactly who is authorised on the current version.

Next

• Upload and publish — the full publishing flow
• How UsenetShare works — the underlying key model
• Download a share — the recipient's side