The asset library
When a file comes back
Download an image, bring it back later, and Plnty recognises it and reattaches everything it knows about how it was made.
Download an image from Plnty, send it around, and drop it back on a board weeks later. It arrives knowing what made it: the tool, the model, the prompt, the settings, and the asset it came from. Nothing is added to the file to make that work. The bytes themselves are the identifier, and Plnty recognises them when they come back. ## How the recognition works Plnty takes a SHA-256 fingerprint of an asset's bytes when you **download** it and records that against the asset. When a file is **uploaded**, it fingerprints the incoming bytes and looks for a match. Downloading is the moment that matters, and that is deliberate: the only files that can ever come back are the ones somebody exported, so fingerprinting on the way out covers exactly the right set. Neither half blocks you. Your image appears on the canvas immediately and the link fills in a moment later. :::note[Copy and paste keep their history a different way] Duplicating an image on a board, or copying one between boards, needs no fingerprint at all, because the canvas already knows which asset it points at. Fingerprinting exists for the one case that breaks that chain, which is a file leaving Plnty entirely and coming back as fresh bytes. ::: ## What comes back with it Everything the asset already carried: - The **tool** and the **model** that made it - The exact **prompt** - The full **settings** of the run - Its place in the **chain**, so it still knows what it was made from Right-click the re-uploaded image, open Properties, and it reads the same as the original did. ## The limit worth understanding **The bytes have to be identical.** Not similar, identical. | This comes back | This does not | |---|---| | The file exactly as you downloaded it | A screenshot of it | | The same file after a round trip through a drive or a chat that preserves bytes | A crop, a resize or a re-save | | The same file renamed | A version re-encoded by a platform on upload | That last row catches people. Several messaging apps and social platforms re-compress images when you upload them, so a file that went out through Plnty and came back through one of those is a different file as far as the fingerprint is concerned. :::caution[Why the match is exact rather than approximate] A perceptual match, the kind that recognises a crop or a resize, would be a guess. A guess that attaches the wrong parent to an asset is worse than attaching no parent at all, because a wrong record still looks like a record. ::: Two smaller boundaries: a file that was **never downloaded** has no fingerprint to match against, and files over 64 MB are skipped rather than made to wait. ## Why this is safe to use on shared work The fingerprint is calculated in your browser, so Plnty treats it as a claim rather than as proof. Two rules keep that honest. **Write once.** An asset's fingerprint is recorded the first time and never overwritten, so nobody can point an existing asset at different bytes afterwards. **Read-gated in both directions.** You can only fingerprint an asset you are already allowed to see, and a lookup only ever returns an asset you are already allowed to see. Uploading a file you found somewhere therefore tells you nothing about a stranger's library: if you could not already see the asset, the match does not exist for you. :::tip[The check is access, not authorship] It asks whether you can read the asset, not whether you made it. Gating on authorship would break the case the feature exists for, which is work being passed around a team and coming back through somebody else's hands. ::: ## What this means for your work It matters most in the situations where provenance is usually lost: - A client sends back the one they picked, out of ten you delivered, and you can see which run made it rather than guessing from the thumbnail - A file surfaces in a folder months later with a name nobody recognises - A colleague hands you an image and neither of you remembers where it came from In each case the answer is to drop it on a board and look.Download an image from Plnty, send it around, and drop it back on a board weeks later. It arrives knowing what made it: the tool, the model, the prompt, the settings, and the asset it came from. Nothing is added to the file to make that work. The bytes themselves are the identifier, and Plnty recognises them when they come back.
How the recognition works
Section titled “How the recognition works”Plnty takes a SHA-256 fingerprint of an asset’s bytes when you download it and records that against the asset. When a file is uploaded, it fingerprints the incoming bytes and looks for a match. Downloading is the moment that matters, and that is deliberate: the only files that can ever come back are the ones somebody exported, so fingerprinting on the way out covers exactly the right set.
Neither half blocks you. Your image appears on the canvas immediately and the link fills in a moment later.
What comes back with it
Section titled “What comes back with it”Everything the asset already carried:
- The tool and the model that made it
- The exact prompt
- The full settings of the run
- Its place in the chain, so it still knows what it was made from
Right-click the re-uploaded image, open Properties, and it reads the same as the original did.
The limit worth understanding
Section titled “The limit worth understanding”The bytes have to be identical. Not similar, identical.
| This comes back | This does not |
|---|---|
| The file exactly as you downloaded it | A screenshot of it |
| The same file after a round trip through a drive or a chat that preserves bytes | A crop, a resize or a re-save |
| The same file renamed | A version re-encoded by a platform on upload |
That last row catches people. Several messaging apps and social platforms re-compress images when you upload them, so a file that went out through Plnty and came back through one of those is a different file as far as the fingerprint is concerned.
Two smaller boundaries: a file that was never downloaded has no fingerprint to match against, and files over 64 MB are skipped rather than made to wait.
Why this is safe to use on shared work
Section titled “Why this is safe to use on shared work”The fingerprint is calculated in your browser, so Plnty treats it as a claim rather than as proof. Two rules keep that honest.
Write once. An asset’s fingerprint is recorded the first time and never overwritten, so nobody can point an existing asset at different bytes afterwards.
Read-gated in both directions. You can only fingerprint an asset you are already allowed to see, and a lookup only ever returns an asset you are already allowed to see. Uploading a file you found somewhere therefore tells you nothing about a stranger’s library: if you could not already see the asset, the match does not exist for you.
What this means for your work
Section titled “What this means for your work”It matters most in the situations where provenance is usually lost:
- A client sends back the one they picked, out of ten you delivered, and you can see which run made it rather than guessing from the thumbnail
- A file surfaces in a folder months later with a name nobody recognises
- A colleague hands you an image and neither of you remembers where it came from
In each case the answer is to drop it on a board and look.