How do you replace a presentation without changing its URL?

Use the original deck_id when you publish the replacement file. The reader URL is derived from that stable deck ID, while the current version points to the newest accepted bytes. Claim the deck before using account-managed version history or restore.

Identifier	What changes	What stays stable
`deck_id`	Nothing during update or restore.	The full slidesfly.xyz reader URL.
Version	Increments after every update or restore.	Older version records remain in history.
Current bytes	Become the uploaded file or restored source version.	Access still goes through the reader and current policy.

Download the two verified versions

The proof uses two self-contained HTML decks with different visible markers, byte sizes, colors, and SHA-256 values. Version 1 was published, version 2 replaced it at the same deck ID, and version 1 was restored as version 3.

Version 1 source: download deck-v1.html — 4,232 bytes — 9c2f8626ba1a3889aadf22cd98892964a330ace454a6bddfd06e1dc6878bbba8.
Version 2 source: download deck-v2.html — 4,235 bytes — 981102c2c5eec330ca2b8ead752a8bbc18e960cbd006ae3805f1b16b1ca3ef3c.
Stable live reader: open the restored production deck.
Agent-readable proof: update-presentation-without-changing-link.md.

Publish, claim, update, inspect, and restore

Publish the baseline artifact
Publish deck-v1.html, save the returned deck_id and complete reader URL, and verify the Version 1 marker before changing anything.
Claim the anonymous deck
Sign in without auto-claim when you want to observe the explicit claim step, then claim the returned deck ID. The private claim token remains in the local CLI config.
Update the existing deck ID
Publish deck-v2.html with --id and the original deck ID. Do not run a second create command or construct a new reader URL.
Inspect the immutable history
List versions and confirm that version 2 is current while version 1 remains recorded with its original size and SHA-256.
Restore version 1
Restore version 1. Slidesfly creates version 3 from the old bytes instead of deleting or rewriting versions 1 and 2.
Verify the stable reader URL
Open the same reader URL, confirm the Version 1 marker and hash are current again, and test slide navigation before sharing.

1. Publish version 1

curl -fsSL https://slidesfly.com/install.sh | sh
slidesfly --version # continue with 0.1.3 or newer
slidesfly publish ./deck-v1.html --title "Slidesfly same-URL update and restore proof" --json

Save the returned deck_id and exact reader url. An anonymous publish is unlisted and its claim token remains in the local CLI config; do not paste that file into a prompt, issue, or report.

2. Claim the deck

slidesfly login --no-claim --json
slidesfly claim YOUR_DECK_ID --json

The default login flow may auto-claim local decks. Use --no-claim only when you specifically need to observe the explicit claim step shown here.

3. Update the same deck ID with version 2

slidesfly publish ./deck-v2.html --id YOUR_DECK_ID --json

Replace YOUR_DECK_ID with the value returned by the first publish. Running a new publish without --id creates a different deck and therefore a different link.

4. Inspect history and restore version 1

slidesfly versions YOUR_DECK_ID --json
slidesfly restore YOUR_DECK_ID 1 --json
slidesfly versions YOUR_DECK_ID --json

A successful restore reports restored_from: 1 and creates version 3. It does not make version 1 current in place or remove the intervening update.

Observed production version sequence

Version	Operation	Bytes	SHA-256	Final state
1	Published baseline	4,232	`9c2f8626ba1a3889aadf22cd98892964a330ace454a6bddfd06e1dc6878bbba8`	Historical
2	Published update with the same deck ID	4,235	`981102c2c5eec330ca2b8ead752a8bbc18e960cbd006ae3805f1b16b1ca3ef3c`	Historical
3	Restored from version 1	4,232	`9c2f8626ba1a3889aadf22cd98892964a330ace454a6bddfd06e1dc6878bbba8`	Current

All three operations used deck ID FwT7rsuUEkiypbiG1ujAp4. The complete reader URL remained https://slidesfly.xyz/d/FwT7rsuUEkiypbiG1ujAp4. Version 2’s live asset matched its source immediately before restore; the current version 3 asset now matches version 1.

Anonymous update, claim, and owned restore are different boundaries

The first single-file publish can be anonymous and unlisted. The originating CLI keeps the private claim credential locally.
That same local CLI can update its anonymous deck with --id, but versions and restore are account-managed operations.
Claiming transfers the deck into the authenticated account. Use the same owner account for later version and restore commands.
Update and restore do not change visibility automatically. This proof remains unlisted.
Deletion, expiry, visibility, and moderation can still make a stable reader unavailable. “Stable” means the identifier is reused, not that availability is guaranteed forever.

Update and restore failures

Error or symptom	Cause	Recovery
`AUTH_REQUIRED`	The deck is not claimed and the CLI has no account credential for version history.	Log in, claim the local anonymous deck, then retry versions or restore.
`DECK_NOT_OWNED`	The authenticated account does not own the supplied deck ID.	Use the account that claimed the deck; do not retry against another user’s deck.
`DECK_NOT_FOUND`	The deck ID or requested source version does not exist.	Run versions with the exact deck ID and restore only a listed version number.
`MALICIOUS_CONTENT`	The replacement artifact violates the current upload security policy.	Inspect and repair the local artifact. Do not auto-rewrite and repeatedly republish it.
`Reader still shows old bytes`	A historical asset URL was shared, or the reader was checked before the update completed.	Share only the stable slidesfly.xyz reader URL and verify the current version response.

Common questions

Does restore delete the newer version?

No. Restore copies the selected historical bytes into a new current version. In this proof, restoring version 1 created version 3 and left version 2 in history.

Can viewers keep using the old presentation link?

Yes. Keep sharing the slidesfly.xyz reader URL returned by the first publish. Do not share a versioned asset URL, because only the current asset is publicly delivered.

Must I claim before every update?

No. The originating CLI can update its local anonymous deck. Claiming is required when you need account ownership, cross-machine management, version listing, or restore.