Question: Is saving the same thing as registering?

Once I had a way to identify a project, I assumed the hard part was over.

It wasn't.


A registration key solved one problem: identity. Two projects could no longer collide under the same name.

I treated "save" and "register" as one step. Save the file, tell the backend it exists, done.

What I thought I needed

The plan was simple: on the first save, generate a key, send it to the backend, get an ID back, and write that ID into the file being saved. One action, one moment, one file that ends up complete.

Registering looked like just another step in saving. After all, every new project had to be saved before anyone else could know it existed.

Where it broke

It broke when I looked at what "save" actually meant in this editor.

I'd been picturing a file sitting on disk somewhere, ready to be reopened and updated. That's not what was happening. Saving here meant handing a file to the browser once, as a download. There was no file to go back to. The file had already left my control.

Which meant if the network call to the backend failed at the exact wrong moment — after the file was already downloading, before the ID came back — there was no clean way to retry. The save had already happened. It couldn't happen again.

Why that mattered more than it looked

At first this felt like an edge case. A dropped connection, a slow server, bad luck.

Why did I assume they were one step? Because in most systems, saving already implies persisting somewhere central — so telling a backend "this exists" feels like a natural side effect of saving, not a separate concern.

Why was that assumption wrong here? Because saving didn't mean "persist to a place I can return to." It meant a one-way handoff to the browser's download manager. Nothing about it could be resumed or repeated.

Why does that change anything? Because a download and an API request don't behave the same way. Saving finishes immediately. Registering might never finish.

The two things looked like one event because they usually happened at the same moment. They were never the same kind of event.

What I changed

Saving stopped waiting on anything. It always succeeds, network or no network, because nothing about keeping someone's work should depend on a server being up.

Registering became its own attempt. It ran alongside the save instead of inside it — using the key generated earlier, so trying again costs nothing and creates nothing new. If it succeeds, the file carries the proof. If it doesn't, the file is still safe, and the next save tries again.

Saving protects the work. Registering tells the rest of the system the work exists. One of those can never be allowed to block the other.


Wrong assumption: saving and registering were one event, and whatever happened to one should happen to the other Discovery: saving and registering are different responsibilities. Next step: the registration key made retries safe. What it didn't answer yet was what happens when two people are looking at the same project from two different places at once.


Saving was never allowed to fail.

Registering was always allowed to.