[Deep Dive #30] Redirect Braids - discussion
Deep Dive #30’s thesis is basically: redirects are fine, but only if you treat them as a composed flow with a braid ledger — targets are explicit, render navigation is intent, and the route leaves evidence so nobody feels “teleported.”
If you’re using redirect targets in routes, do you render evidence of the braid (phase/target/last) like the post recommends, or keep it hidden? How do you avoid redirect braids turning into an open-ended “to can be anything” situation? Have you had real bugs caused by render-time navigation intent, and what guardrails made it survivable?
Comments (10)
Back to latestThe “teleport” feeling is real. If you don’t render target + phase somewhere, users will assume the app glitched.
The post ties together three things we normally separate: open redirects, render intent, and an evidence ledger.
If you’re going to do it, you have to make it surface-visible.
Related: Security and Safety and Routing and Navigation.
We copied the “braid ledger” idea and it made redirects less spooky:
tsx
const ledger = useLiveState('braid-ledger', { phase: 'start', target: '/home', last: '' });
ledger.write('last', ledger.read('target'));
return <div data-braid={ledger.read('phase')} data-target={ledger.read('target')} data-last={ledger.read('last')} />;Counterpoint: render-time navigation intent is still a footgun for teams who don’t have discipline.
One jump.to() in the wrong place and you’re in a loop that only reproduces for one user with one token state.
100% — the deep dive’s “visibility” argument is what made it feel acceptable.
If you can see phase/allowed/target in the UI, loops become debuggable instead of mystical.
That’s fair. Invisible loops are the nightmare. Visible loops are at least fixable.
We had a braid bug where “target” came from three places (query param, global default, and local hint) and it was impossible to reason about.
Rendering “resolved target” next to “hint target” was the only way we found it quickly.
Guardrail we used: only allow redirect targets from a small allowlist and store the selected one as a route contract key.
If the target isn’t a contract key, it’s not stable enough to be part of a braid.
The post’s “braids only work when visible” warning is dead-on.
We started attaching a short message string (“why you were redirected”) and it reduced support tickets massively.
Also worth cross-reading: the trust rails deep dive (#25). The redirect braid posture inherits that “security decisions are UI decisions” framing.
If the braid ledger isn’t in the UI, it doesn’t exist when you need it (support, screenshots, “what happened”).
I like the braid concept mainly because it forces you to pick a resolved target deterministically.
Without that, redirects become a chaotic intersection of “who wrote to last”.