ReelPile
chapter 12 of 18

Sending a board to a client

The share button in the toolbar, or Share… in the ⋯ menu.

What happens

The app builds one self-contained HTML page from the board and uploads it, with the cover images, to a Cloudflare Worker. The link looks like:

https://<ReelPile's share host>/b/<22 random characters>/

Twenty-two random characters is the whole of the secrecy: the address is not guessable, and it is not listed anywhere. Anyone you give it to can open it.

The link lives on share.reelpile.com. The long tail after /b/ is not an id that could be shorter and prettier — it is the secret itself, 128 random bits, and it is the only thing between a private board and anybody who guesses. That is why the link looks the way it does.

Exactly what travels, and what does not

Uploaded: the board's name and emoji; per card, an id, position and size, the poster image (JPEG), author, caption, views, likes, duration, {track, artist}, the embed URL, a link to the original, a platform label, and two flags (unavailable / no link). Plus text notes (text, position, size, colour).

Never uploaded: video files, ever; audio; the full original URL (only a stripped version); any path on your disk; the filename of your own uploads; comments; dates; board ids; error text; drawings.

The module states the rule itself: "A shared board carries POSTERS ONLY — no video path, no local file path, nothing that reveals this machine."

This is verified three ways: the uploader only ever writes p/<id>.jpg and index.html; the Worker rejects any other path shape with a 400; and playback on the client's side runs through the platform's own iframe, not your server.

What the client sees

They open the link in any browser. On a desktop it is the board with your layout preserved, pannable and zoomable; on a phone it collapses into a single column (ordered at publish time by rows top to bottom, left to right within a row, so a note above a group reads as its heading).

Clicking a card opens the platform's player, a link out to the original, a heart, and close. No account, nothing to sign up for.

Hearts and review: two limits worth knowing

Your review link is the same link with ?liked=1 on the end. Open it and picked cards are outlined in red, the rest dim, and the header reads "Client marked 7 of 24".

Limit one: one link, one client. The picks live in a single record that is overwritten wholesale: last write wins. Send one link to two people and the second erases the first's choices. Publish separately for each client.

Limit two: ?liked=1 is not a secret. Anyone holding the client link can append it and see the picks, and technically overwrite them. The only protection is that the link itself is unguessable.

Also: the picks never come back into the app. You read them in a browser. There is no "show only the picked ones" filter and no export.

Managing a published board

  • Update re-uploads the current state. The link does not change.
  • Unpublish asks "Unpublish this board? The link you sent will stop working." It removes everything, including the client's picks. Publishing again afterwards mints a new link; the old one is dead for good.
  • No expiry. The link lives until you take it down.
  • One board, one publication. Limit: 20 new publications per IP per hour.
  • The page is marked noindex,nofollow, though the host serves no robots.txt.
  • The panel shows "Last published <date>. The client sees the board as it was then."

Things to say plainly rather than gloss over

  • No password. The link is the only key. Anyone it is forwarded to can open it.
  • Your own uploaded mp4s are dead weight on a shared board. They have no platform link, so the client sees a still frame they can never play, badged no link to open. This will be the most common support question.
  • Playback goes through Instagram/YouTube, so the platform can see your client opening it.
  • Posters are cached on the client's side for a year. After an Update, someone who already opened the board may keep seeing the old thumbnail for a long time.
  • Publishing is not instant: each Instagram post is probed to see whether it is still alive (6 in parallel, 5 s timeout).
  • Publications live only on this machine. The share id and the write key are stored in db.json, so they travel in every backup — the plain ⬇ Backup download and each silent auto-snapshot, not only the full one. Treat any backup of a library with a published board as carrying a live credential: the write key is what lets its holder overwrite or take down a link a client is looking at. On a fresh machine without restoring that backup, you cannot update or unpublish your own live link.

Something here wrong, or something missing? Tell us — the manual is corrected against the app, not the other way round.