A face you have to earn

The last post here was in May. Work stopped for a while for reasons that had nothing to do with the product — what follows is a few days of building, not a quiet summer of it.

What landed is the part of ForestLynk that was always missing: people having a presence beyond a handle.

Your own profile — prompts, pinned roots, and the diary underneath

A diary, not a feed

A profile opens on a gardening record. Everything you’ve planted, branched and leafed, in the order it happened, with no ranking of any kind — the oldest thing you did is as reachable as the newest.

It is deliberately not a feed. Nothing is scored, nothing surfaces because it performed well, and a quiet week looks like a quiet week.

The diary in full — entries grouped by forest with relative timestamps, each showing what was planted or branched, filterable by kind. — Strictly chronological, filterable by kind, and never reordered by anything else

Underneath it sits a fingerprint — a grid of the forests you spend time in, week by week. It shows shape rather than counts. Where attention actually goes, without turning it into a scoreboard.

A grid where each row is a forest and each column a week, cells shaded by how active that forest was, in each forest's own accent colour. — Rows are forests, columns are weeks — intensity, not totals

What each person is allowed to see

Almost none of this is public. A profile is projected through your stage with the person looking at it, so the same profile is a different document to four different people.

A stranger gets an outline: sections named, contents absent, each one saying what it would take to open it. Someone Close gets the whole record.

To a stranger — the sections exist, and say what would open them

The locked parts are named but empty, which is the point: you can tell something is there without seeing any of it. What you aren’t entitled to never leaves the server, so there is nothing on the device to leak.

The same profile, to someone Close

Different faces for different people

Identity marks arrived with all of this: a photo, or a drawn tree mark in a species and accent you choose. It appears wherever a handle does — the folk roster, search, the panel that rises when you tap someone, the members along the top of a personal forest.

A mark or a photo, and an accent — no banners, no themes, no fonts

You can show your photo only to your Close folk; everyone below sees the tree mark instead. And a face can be set per forest, so the room you were tapped from decides which version of you turns up. Open someone cold and you get their global face.

One handle shown across four rooms, with a switcher for each — the same person carries a different display name, accent and rooted line depending on the forest, while the handle and stages stay constant. — One handle, four rooms — the handle and your stages never change

A face you haven’t earned isn’t dimmed or withheld. It was never sent.

Tech notes

Where images live. This is the first thing the product stores that isn’t a row in a database, and the obvious place to put it — the same machine the application runs on — is the wrong one. That disk is finite, its bandwidth is shared with every other request, and a container replacing itself takes the files with it while the database carries on pointing at them.

So images live in object storage behind a content delivery network, and image bytes never pass through the application server at all. Uploads go through it — the client never holds storage credentials — but reads resolve straight to the edge. Photo traffic is the heaviest thing a social product ever serves, and keeping it off the application is the difference between a viral moment being exciting and being a bill.

Links that expire. A media URL is a capability: anyone holding it can fetch the picture, because the edge serves bytes without asking who is calling. Every large platform works this way — the alternative puts a database lookup in front of every image, which is why nobody does it.

What that model lacks on its own is an ending. A link, once shared, works forever, so revoking someone’s access revokes nothing they already hold. Media links expire, which makes a permanent capability a temporary one. It doesn’t stop someone screenshotting a photo they were allowed to see — nothing does — but it does stop a link pasted somewhere public from working indefinitely.

Caches don’t hear about deletions. Destroying a file reaches the place it was stored, not the copies an edge network is already holding. Whatever the cache lifetime is, that’s how long something can go on being served after it’s gone. It’s a straight trade — longer caching is cheaper and faster, shorter caching makes removal mean what it says — and for anything a person can delete, it’s worth buying the shorter one.

Two layers disagreeing about one instruction. Worth knowing if you ever chase this: an edge platform’s own cache defaults can quietly rewrite the cache headers an application sets, so the edge and the browser end up following different numbers for the same response. Only one of them appears in your own logs, which makes the disagreement hard to see and easy to misattribute.