How UsenetShare works

Ten minutes that make the rest of the app obvious. Most confusion — and most support tickets — trace back to one of the four ideas on this page.

If you only read one section, read Where the key lives.

The short version

UsenetShare turns a folder on your disk into a link. Anyone you give the link to can browse that folder and pull files out of it, streaming them on demand if they prefer not to download. The files live on Usenet — a decades-old, globally replicated network your provider already gives you access to — and they are encrypted before they leave your machine, so the provider stores bytes it cannot read.

There is no UsenetShare server in the middle. We never see your files, your file names, or your keys.

The three roles

Everyone using the software is doing one of three jobs. The app calls them by these names and so do these guides.

The owner has the files. They add a folder, the app indexes and encrypts it and posts it to Usenet, and they get a share link. Covered in Upload and publish.

The consumer has the link. They import it, which fetches a catalogue of what is in the share, then download or stream whatever they want. Covered in Download a share.

The provider is your Usenet company — Newshosting, Tweaknews, and so on. They store and serve the encrypted articles. They are not a party to the share; they hold ciphertext and have no idea who the recipients are.

One install can be owner and consumer at once. The same app does both, which is why the navigation has both Upload and Download.

What actually happens to your folder

Publishing runs six stages. The app shows them as a row of steps on the Upload page and names them the same way in the folder's timeline, so when something stalls you can tell what it was doing.

Two consequences worth knowing:

Your folder is never moved or modified. Indexing reads it. A single-file share reads that file where it sits.

Small files are grouped. Thousands of tiny files (game artwork, thumbnails, text) get packed together into shared pieces, so fetching one of them fetches its neighbours too. That is why a share of two million small files can be browsed quickly, and why pulling a handful of artwork files out of such a share is nearly free — the first one costs a network round trip and the rest come from memory.

What a share link is

A link looks like this:

usn://dXNlbmV0Oi8vPGFiYzEyM0B1c2VuZXRzaGFyZS50ZXN0Pi9mLTdiMmUuLi4

That is a wrapped form of a plainer address:

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

• the message-id points at the article holding the share's catalogue
• the folder-id identifies the folder inside it
• the key, when present, is the decryption key

The usn:// wrapper is base64 and is trivially reversible. It exists to keep the message-id from being harvested by scrapers, and that is all it does. It is obfuscation, not protection. What actually protects your content is the encryption, and where the key goes.

Paste either form. The app accepts both.

Versions: v3, v4, v5

You may see a badge next to a link. It refers to the catalogue format, not to the app version.

Consumers open all three. Owners publish signed links only. Nothing you need to choose.

Where the key lives (the one that matters)

Every share is encrypted with a key. The three access types differ only in how that key reaches your recipient, and that single fact explains almost every "why can't I…" question.

Public

The key travels inside the link, in the part after #.

Anyone who has the link can open the share. Anyone who sees the link can open the share — in a chat log, a forum post, a browser history, an email that got forwarded. Treat a public link as the content itself.

Password protected

The key is derived from a password that you choose and never upload. The link alone is useless; a recipient needs the link and the password, and you must send them the password separately.

We never store it. That is not a policy, it is the design: there is nothing on any server to look up. If you forget the password, the share cannot be recovered — not by you, not by us. Re-publish the folder to mint a new one.

Private

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

This is the strongest option and the only one where a leaked link achieves nothing: someone who is not on the list has no wrap to open. The trade-off is that you need each recipient's identity token before you publish, because the wraps are built at publish time. Collect them first — see Public, password and private shares.

Adding someone later means re-publishing. That is cheap (nothing is re-uploaded) but it is a step people do not expect.

Consequences

What your provider can and cannot see

Your provider stores the articles, so they see what any Usenet provider sees: that an account posted a lot of encrypted articles, how big they were, and when.

They cannot see your file names, your folder structure, or your content. All of that lives in the encrypted catalogue. Article subjects carry no meaningful names. There is no plaintext index anywhere on the network.

They also have no idea who your recipients are. Consumers fetch articles like any other Usenet reader, using their own provider account, which may be a different company entirely.

We see less than that: nothing. There is no account with us, no telemetry of your content, no server in the path. The only thing that ever reaches us is what you deliberately send — a diagnostics bundle, a bug report, or a remote support session you switched on yourself.

Usenet has a memory, and it is finite

Providers keep articles for a retention window — currently several thousand days at the major ones, but not forever, and not identically everywhere.

Two things follow.

Old shares can decay. Articles can expire or go missing. A share that opened last year may report missing pieces today. The folder view shows retention and redundancy health so you can see it coming, and repair or re-publish before it bites. See Verify and repair.

Redundancy is your insurance. By default the app posts extra copies of every piece, so a share survives losing some. You can raise that for content you care about — see Recommended settings.

Why speed is what it is

Worth setting expectations, because "it's slow" is usually one of three specific things and knowing which saves everyone time.

Your provider gives you a fixed number of connections — 50, 60, whatever your plan says. That number, not your internet speed, is usually the ceiling. More connections than your plan allows gets you errors, not speed.

Two things in the app want those connections: downloading, and streaming (a mounted drive or the S3 gateway). When both are active they get half each, and a banner at the top of the app shows the split and lets you give either side everything. Streaming a file this machine already downloaded is read from disk and uses no connections at all.

Your disk can be the limit, not the network. A network drive over Wi-Fi frequently cannot absorb what a good Usenet connection delivers. The app has a built-in test that measures your provider, your drive's write speed and its read speed separately, and tells you in plain language which one is holding you back. Run it before changing any setting: Help & Support → Check your speed. See When something is wrong.

Where your things are kept

That folder holds the database of your folders and imported shares, your config.json, your license, your identity keys, the publish cache and the logs.

Back it up, or at least know it exists. Your identity keys live there, and they are what makes you you on private shares. Losing them means recipients' existing wraps still work but you can no longer prove ownership from that install. Update, move machine, uninstall covers moving it properly.

Where to go next

• Not installed yet → Install
• Installed, nothing configured → Set up
• Want to share a folder → Upload and publish
• Someone sent you a link → Download a share
• Something is wrong → When something is wrong