The link is not the film

There is a particular way this goes wrong, and it is worth describing before the mechanism, because the mechanism only matters if you recognise the moment.

A shoot finishes. The film plays. You right-click it, copy the address, and paste it somewhere that is not Nitaris — into a message to the person who runs the store, into a brief, into a scheduling tool, into a form field on a platform that asks for a video URL. Then you go and do something else. An hour later the film is still there, still yours, still exactly as it was. The address is not. Anyone who opens it now gets a black rectangle and an error they cannot read, and nobody is told.

Why the address has a clock on it

The files live in object storage, which is a different system from the app and on a different domain. Nothing in that storage is public. Every address the app hands you is signed on the spot: a long URL with a signature in it that says, in effect, whoever holds this may read this one object until this exact moment, and no longer.

That is the only sane arrangement for files that belong to you. The alternative is a permanent public address, and a permanent public address for a product film is a file that anyone who ever saw the URL — a contractor, a marketplace, a forwarded email — can still fetch two years later, with no way to withdraw it short of deleting the file. The expiry is not a restriction on you. It is what makes the storage private in the first place.

The window is an hour for the things you watch and save: the film, its thumbnail, the download. A music preview gets ten minutes, because nobody keeps one open. A bulk archive gets fifteen, which is long enough to start a large download and short enough that a link left in a chat does not stay live.

The app hides this from you, on purpose

Leave a shoot open on screen and the film never stops playing. That is not because the link lasts; it is because the page re-mints it. The app reads the expiry off the URL it is holding, works out how long is left, and re-reads the page just before the current address dies. Come back to a tab you left over lunch and the same thing happens on the way in.

So the one place the link appears to be permanent is the page that is quietly replacing it. Everywhere else, it is an hour old and getting older. This is the right behaviour — the alternative is a player that goes black while you are looking at it — but it does mean the app teaches you the opposite of the thing you need to know the moment you copy something out of it.

It is worth being clear about how invisible the failure is. When one of these addresses expires, the refusal comes from the storage system, at its own domain. Nitaris never sees it. The person holding the dead link sees a video that will not start, or a download that does nothing, with no message attached to either. There is no error in your account, no notification, and no way for anyone to work out from the symptom what went wrong.

Which menu item you use decides everything

On a desktop browser the two actions sit next to each other in the same right-click menu, and they do opposite things.

• Copy link address gives you the signed URL. It is a temporary pointer. It will work for the rest of the hour and then it will not, wherever you have put it.
• Save link as, or the Download button, gives you the file. The download address is signed to arrive as an attachment, so it saves with a sensible name instead of opening in a tab, and once it is on your disk the clock stops mattering.

The Download button is doing slightly more than that. Before it hands the address to the browser it checks how much time is left on it, and if the answer is less than a couple of minutes it fetches a fresh one first — so a download started from an old tab works, where a copied link from the same tab would not. It is still an ordinary link underneath, which is deliberate: right-click, middle-click and save-as all keep working, and so does the button if the page's scripts never load.

You can read the deadline off the link itself

This is the part most people do not know is available. A signed address carries its own expiry in plain sight, in the query string after the question mark. There is a timestamp recording when it was signed, in the compact form 20261002T101500Z, and a number of seconds it is good for — 3600 for a film. Add them together and you have the exact minute the link stops working.

That is genuinely useful when something has already gone wrong. If a colleague says the video you sent does not play, you do not have to guess between a broken file, a permissions problem and an expired link. Look at the URL you sent them. If the timestamp in it is more than an hour old, you have your answer, and the fix is to send the file instead.

What to do instead, which is shorter than the explanation

Treat the link as a way of looking at the film, and the file as the film.

If the destination is a store listing, an ad account, a marketplace or a social platform, those all host video themselves — they want the file uploaded, not a pointer to someone else's storage, and uploading it is also what stops your product video depending on a system you do not control. If the destination is a person, send the file, or send them the shoot page and let them download it themselves with a fresh address.

And if you only remember one thing: the moment you are about to paste a video address into something that is not Nitaris is the moment to go back and press Download instead. It is the same two seconds, and it is the difference between a film that is still playing next month and one that stopped an hour after you walked away.