Reusing one uploaded image in more than one feature can save storage and preserve an exact original, but it changes deletion semantics. A photo-book page that points to a Memory image is not a copy; it is another live reference to the same blob.
Attach a reference when the same original matters
A photo-book page can refer to the exact Active Storage blob already attached to its source Memory. That avoids a second upload and lets the page preserve the original bytes. It also means the attachment table, not a duplicate object key, represents the relationship.
Keep references within the same account
Before creating the page, the application verifies the source Memory belongs to the current identity. A signed blob identifier is not ownership evidence on its own. The reference operation needs the same account boundary as the parent record.
This principle also informs account-scoped data exports, where a blob can only enter an archive through an owned record.
Delete references before deciding whether bytes can go
Removing an image from the original Memory does not automatically mean the physical blob is disposable; a photo-book page may still use it. Conversely, deleting a photo-book page should remove its attachment without erasing a source Memory’s image. Cleanup must account for all remaining attachment references.
This is why abandoned Active Storage upload cleanup targets only unattached staging blobs.
Encrypted media remains an opaque reference
For an encrypted source Memory, Rails stores ciphertext bytes and serves them as opaque media. A client with an unlocked vault can decrypt the media locally for display; Rails does not create a plaintext variant merely because the same blob is used in another account-owned view.
The browser and storage responsibilities are covered in encrypting photos and files before Active Storage sees them.
Register shared files once in an export
An export that serializes both a Memory and a photo-book page should not blindly write identical blob bytes twice. Inpages.me registers selected attachment blobs once and records references back to the relevant domain. This preserves the graph without inflating the archive unnecessarily.
Test both directions of removal
Focused tests cover deletion of the source reference while a photo-book page remains, deletion of the page while the Memory remains, account ownership, and export reconstruction. The important question is always the same: which live references remain before a physical blob is purged?