Daniel's been collecting pictures of desks for years. Not his own. Other people's. Specifically, the private offices of heads of state, the places where presidents and prime ministers actually sit down and do paperwork when the cameras are pointed the other way.
And he turned them into a coffee table book.
He did. It's called World Leaders at Their Desks, and having flipped through a few of these images myself, I'll say the premise holds up. You learn more about a government from the desk lamp than from the podium.
Which is a strange thing to be true, but it is. There's a whole genre of this, by the way. Photographers who shoot the rooms after the people leave. The Resolute Desk with nothing on it. A French president's office with one pen and a folder. You can read a lot into what's absent.
The absence is the tell.
The absence is always the tell. Anyway, that collection lives on Pinterest, along with a few others. Corporate office design. Multi-monitor workstations, with a heavy emphasis on emergency dispatch centers. More recently, modular storage. Hannah's on there too, being an architect and all. So this is a house that uses the site.
And then Daniel hit the wall he always hits.
Right. Here's what he wrote. He says he's been a fan of curating images of great design and ergonomics in the wild for years, and he thinks Pinterest is a great service. But he has one major objection as a, quote, backup purist. If he's going to the trouble of building an archive of images, he wants to maintain the actual data, which is the images themselves. His read is that under the hood Pinterest is more like a pointer service, a metadata interface gathering together photos and pointing to where they actually live. And he's not sure that meets his needs for data sovereignty.
That's the whole question right there.
There's more. He explicitly says to put copyright to one side, because he doesn't think there's anything illegitimate about saving a copy for offline personal use with no intention to publish, and because it detracts from the actual logical options. And then the real ask. He wants us to look at the best tools and approaches for curating collections of images. Whether you're planning a renovation, drawing energy from examples of work that interests you, or any other reason.
Four or five questions bundled into one, which is normal for him.
It's a good bundle, though. Because the copyright thing really would eat the whole episode.
It's a legal question, and the architectural question is more useful anyway. If you spend twenty minutes on fair use you never get to the interesting part, which is that the tool he's using and the job he's asking it to do are two different things.
And honestly, the copyright question has a pretty settled answer for personal use. The interesting question is whether the tool can even do what he wants, and the answer is no, and the reason is structural.
So let's start with what Pinterest is actually doing under the hood. Because the answer is more interesting than it sounds.
The first thing to understand is that a Pin is not a picture. It's a promise that a picture exists somewhere else.
Say more.
A Pin, structurally, is a URL. That's the core of it. On top of that URL sits metadata: the title, the description, which board it's on, who uploaded it, when. And then there's a cached thumbnail, which is a derivative image, sized and compressed so the feed loads fast.
So the grid you're looking at is real.
The grid is real. The grid is a rendering of the metadata plus a downsampled copy. What generally isn't stored on Pinterest's side is the full-resolution original. That lives on the origin site, wherever it was pinned from.
Which means the board is a beautifully organized index of things that belong to other people, on other servers, under other terms of service.
And that's not a bug in Pinterest. That's the whole product. It's a discovery and referral engine. You see something, you want the source, you click through, somebody's website gets a visit, the original creator gets a look. That loop is the business model.
So storing full-resolution originals for hundreds of billions of pins would be a massive cost with no referral upside.
Exactly that. You'd be paying to warehouse other people's images for no return. Nobody builds that on purpose.
And this is why the word sovereignty is doing real work in Daniel's prompt.
Because sovereignty isn't about who owns the copyright. It's about who holds the asset. And Daniel's test is the right test. If Pinterest disappeared tomorrow, or changed its terms, or reorganized its URLs, what do you still have?
You have the index.
You have a list of things that used to be somewhere. Which is useful until the somewhere stops existing.
Link rot wearing a nice grid layout.
That's the phrase. And it's not hypothetical. Take the dispatch center board. A good chunk of those images come from municipal websites. City fire departments, county emergency management offices. Those sites get redesigned every few years, and when they do, the image paths change. The page still exists, the image doesn't live at that address anymore.
So the pin survives as a card.
The card survives. The thumbnail might still show, because Pinterest cached it. The click-through goes nowhere. And if the thumbnail was never cached at high enough resolution to be useful, you're left with a small blurry rectangle and a title.
Which is worse than an empty box, in a way. It's a box that looks like it should have something in it.
It's a ghost. And here's the part that makes it worse over time. The pins that rot fastest are the ones from small sites. The big design blogs, the ones with real infrastructure, they keep their images up for a decade or more. It's the little municipal page, the personal portfolio, the small firm's project gallery, that vanishes first. Which means the archive decays unevenly. You lose the obscure stuff first, and the obscure stuff is usually the reason you were collecting in the first place.
The mainstream survives and the interesting dies.
Every archive has that problem. It's just faster on the web.
Now, this is the point where people say, wait, doesn't Pinterest keep a copy? And the answer is, sort of. It keeps a derivative. It's sized for a feed. It's compressed for bandwidth. It is not the archival original. So the objection isn't that they have nothing. It's that what they have is a rendering, not the asset.
And a rendering is a lossy thing. If you ever wanted to zoom in on the detail of a desk lamp, or read a label on a monitor, or count the ports on the back of a workstation, the thumbnail won't get you there. It's been resampled down to the size of a phone screen.
And for mood-boarding, a rendering is fine.
For mood-boarding, a rendering is exactly what you want. You're not going to print a Pinterest thumbnail as a poster. You're going to look at it and go, oh, that's the shelf system I like, and then go find the actual product.
But Daniel isn't mood-boarding. He's archiving.
He's using a discovery tool as an archive, and that's a category error on the user's side. It's not a betrayal. Pinterest never claimed to be your backup.
There's a second layer to this that's worth naming, which is that boards are socially entangled.
Followers. Collaborative boards. Related pins. The algorithm sliding things into your feed because you lingered on one.
And all of that is what makes the export messy. Because the thing you built is not sitting in a private folder on a disk. It's a node in a graph.
Which brings up the export question, and this is the one that catches people. Pinterest does offer a data export. You can request your data.
And what comes back?
Metadata and links. That's it. You get a file that tells you what you pinned, when, to which board, from which URL. What you don't get is a folder of images.
You can leave with the index, not the library.
You can leave with the card catalog. The books stay where they are.
Which is a very clean way of putting the whole episode. So if the pointer model is correct for Pinterest and wrong for Daniel, what does the right shape actually look like?
It depends on which of three things you actually want. And they're different jobs, so it's worth separating them.
Go.
Option one, you want a folder of files. Option two, you want a searchable library with tagging and face recognition and text search over the images themselves. Option three, you want something in between, a self-hosted service that behaves like the cloud product but runs on your hardware.
Start with the folder, because that's the answer nobody wants to hear.
A plain directory tree plus a naming convention plus a real backup strategy. That's it. That's the purist answer.
And it's the most durable one.
It survives every software transition. Every application that has ever tried to organize your photos can read a folder of JPEGs, because the operating system reads a folder of JPEGs. You never have to migrate a database. You never have to export from a format that's been discontinued.
The cost is that search is only as good as your folder names and your filenames.
If you name things well, you can find things. If you drop two thousand images into a folder called inspiration, you've built a shoebox.
Which is still better than nothing, but it's a shoebox.
And the shoebox problem compounds. Two years in, you've got a folder called inspiration with two thousand files, and you're scrolling through it looking for the one desk lamp you remember, and you can't find it, so you pin it again to a board you forgot you had. Now you've got the same image in two places and you don't know which one is the "real" copy.
Which is the same problem as the index, just relocated.
It's the same problem relocated. That's the theme of this whole episode.
So option two, the digital asset manager. Tools like Hydrus Network, or Eagle, or digiKam. These give you tagging, duplicate detection, and search across your own files, sitting on your own disk.
What's the catch?
The database becomes a second thing you have to back up and migrate. You've split your archive into two halves: the files and the index, and now you have to keep them in sync and keep both alive.
Which is precisely the problem you were trying to escape.
It's the same shape of problem, moved inside your own house. That's not a reason to avoid it, but you should know that's what you're buying. You're trading a vendor's index for your own index. You own it, which is the point. But you also have to maintain it, which is also the point.
And if you're the kind of person who's been meaning to organize their photos for six years, you're now the kind of person who has to maintain a database.
You've just given yourself a second job.
And option three.
Immich. That's become the reference implementation for self-hosted photo management. Open source, runs on your hardware, mobile apps that back up your phone's camera roll, facial recognition, object search. You can search for dog and it finds the dog.
And it stores your originals.
On your disk. The originals are yours, in your file system, in a structure you control. That's the pitch, and it's a real one. It's explicitly positioned as a Google Photos alternative, and for a lot of people it is.
So where does the sovereignty story get complicated?
This is my favorite part, because it's the honest part. Self-hosting shifts the dependency. It doesn't eliminate it. You're no longer dependent on Google's terms of service, but you are now dependent on your own hardware, your own backups, your own electricity, and the third-party infrastructure that you don't think about.
Like what.
The Immich project documented an incident where Google flagged their domain as dangerous. That's the project's own domain, the place people go to find out what Immich is and how to install it. Flagged and blocked.
By Google, about a self-hosted project.
Which means a browser warning stood between the project and the people trying to use it. Nobody in that story was doing anything wrong. It's just that the distribution layer, the pipes, belong to somebody else.
So you can be sovereign over your data and not sovereign over how anyone finds out your software exists.
And if you're on a phone, the app store is another landlord. You don't own the shelf your app sits on. If it gets pulled, or your account gets suspended, the app doesn't update and eventually it doesn't work.
The sovereignty is real, it's just narrower than people imagine.
It's narrower and it's specific. You control the files. You don't control the pipe, the shelf, or the electricity. And honestly, controlling the files is the part that matters most, because the files are the thing you'd lose.
So what's the workflow that actually fits what Daniel is doing?
The hybrid. And it's not complicated. Use Pinterest as the discovery layer. It's excellent at that. You browse, you find something, you pin it because you want to remember it exists.
And then.
And then you save the original file the same day. While the source is still live. You download the full-resolution image, you drop it into your local folder with a name that means something, and you're done.
The pin becomes a bookmark, not the archive.
The pin is the lead. The file is the asset. Different jobs, different layers.
Which means the failure mode isn't pinning something. It's pinning something and meaning to come back to it later.
Later is where the archive dies. Later is six months, the site's been redesigned, and the image is gone. Save it the day you find it, or accept that you might not get it at all.
And the naming part matters more than people think. If you save the file as image dash four seven two dot jpeg, you've saved the pixels and thrown away the meaning.
You want the name to carry the context. Who made it, what it is, where you found it, when. A filename is a free metadata field that never breaks, and almost nobody uses it.
So what about the physical end of this?
The physical end is the interesting end. Daniel's already made coffee table books out of his boards. He's already got World Leaders at Their Desks sitting on a table somewhere.
Which is the most sovereign format available.
It's the only format with no URL, no vendor, no format migration, no file system, no operating system. A book from nineteen fifty opens the same way a book from today opens. It doesn't need a driver. It doesn't need a software update. It doesn't need the internet.
It needs eyes.
That's the whole requirement.
Although.
Although it's expensive, and it's fixed. When you print a book, you've frozen the collection at that moment. You can't reorganize it. If you want to add something, you print a second book. If you want to reorder the pages, you print a third.
And there's a physical version of this question that I think gets overlooked.
Hilbert: It's not an archive if the drawer won't open.
Hilbert: A book. You can't take a page out. You can't put two of them side by side and see which one is better. I bought a flat file. Plan chest. The kind a surveyor uses for drawings.
How big.
Hilbert: Five drawers. About fifty by forty inches. Each drawer deep enough to lay a mat board flat without touching the one above it. Solid oak, because it was built when the office was built and nobody had invented anything lighter.
How heavy is a full drawer.
Hilbert: Depends what's in it. Prints, at that size, maybe fifteen pounds. Drawings on vellum, less. Photographs, more, if you use good paper. The chest itself was four hundred pounds empty. It came out of a surveyor's office that closed. The man had been in it forty years and they sold the building.
And you bought it.
Hilbert: I bought it for the drawers. The drawings were still in it when I got it home. Whole thing, forty years of it. Site plans, elevations, a subdivision that never got built. I called the office, asked if they wanted them back. They said no, keep them, we're closing Friday.
So you own a stranger's archive.
Hilbert: I own a stranger's archive. It's sitting in the bottom drawer. I never met the man.
Do you know his name.
Hilbert: It's on the corner of every drawing. Small hand, bottom right. Same initials for forty years.
That's the thing about a book. You don't get to be surprised by what's in the drawer.
Hilbert: You don't. A book is a decision you made once, printed onto paper, and then you can't take it back. A drawer you can open in the morning and put things in a different order by lunchtime. You lay four of them out on the table, you look at them next to each other, you decide. That's not printing. That's thinking.
So you'd take loose prints over a bound book.
Hilbert: Every time. A book you reprint to change your mind. A drawer you just open.
You've never migrated a photo library.
Hilbert: Not once. Not one. I've had four computers and I couldn't tell you where a single picture went. That's on me. That's not a software problem. I tried, twice, and both times I ended up with two folders and no idea which one was the real one.
That's more common than people admit.
Hilbert: It's the folder you don't open that's the real one. And you forget which one that is.
The surveyor's drawings are just... part of your collection now.
Hilbert: They were in the drawer when I bought it. I'm not going to throw them out. He spent forty years on them. Somebody should have them.
Which brings us back to the drawer.
It does. And I think Hilbert's point is sharper than it looks. The coffee table book is finished. It's frozen. It's the most durable thing you can make, and it's also the least flexible. The flat file is the opposite. It's a collection you can still argue with.
The open question is why so few services let you occupy both layers at once. You've got Pinterest, which is a discovery engine pretending to be a board. You've got Immich, which is an archive pretending to be a photo app. Nobody sells you the thing where you find it in one place and it lands in the other without you doing anything.
Because the referral engine wants you to stay in the feed, and the archive wants you to leave it. Those are opposite incentives. A company that solved both would be working against its own business model on one side.
Which leaves you doing the handoff manually. Pin it, save it, name it. Three steps, forever.
That's the honest answer. The best tool is a habit. It's not glamorous, but it's the only thing that's survived every platform change so far.
Every archive is somebody's temporary arrangement. Hilbert's surveyor thought he was keeping forty years of drawings. He kept them for forty years and then they ended up in a stranger's bottom drawer.
Which is a better outcome than the alternative, honestly.
It is. The question isn't whether your archive outlives you. It will. The question is whether it's still legible when it does. A folder of JPEGs from a service that shut down in twenty thirty-one and a format nobody can open in twenty sixty. That's the version we're all building right now.
Unless you print it.
Unless you print it, or put it in a drawer, or hand it to somebody. Because the surveyor's drawings are still readable. They're ink on paper. You can hold one up to a window and understand it immediately. No software involved.
Which is why the physical endgame keeps winning.
If you take one thing from this, it's that discovery and archiving are separate jobs, and the tool that's good at one is almost always bad at the other. Pinterest is a fantastic discovery engine. It was never your archive.
The archive is the folder you actually maintain. The one you know the name of. Everything else is a lead, not an asset.
That's the whole thing. Find it in one place, land it in the other, and know which drawer the real one is in.
Which is a lot harder than it sounds, based on Hilbert's four computers.
It is. We'll be thinking about that for a while.
Thanks as always to Hilbert Flumingtop, our producer, who has never once printed a coffee table book and I assume never will.
This has been My Weird Prompts. If you've got something you want us to look into, or you want to argue with us about whether a flat file counts as an archive, email us at show at my weird prompts dot com. If you're enjoying the show, a review helps other people find it.
We'll be back soon.
See you tomorrow.
