One login has to work across doozer.work, elks.club, nearbymenow.com and every other root — but third-party cookies are dead. So identity rides a first-party token handoff, not a shared cookie.
Doozer is one product spread across many registrable domains: doozer.work, elks.club, nearbymenow.com, doozer.cloud, and the wildcard roots. A person who signs in on one should be recognized on the others. The textbook answer is a shared session cookie on a common parent domain. That answer is gone: browsers now partition or block third-party cookies, so a cookie set for doozer.work is simply not readable from elks.club. Anything built on cross-site cookies is already broken.
Nothing is shared ambiently. Identity is handed from one root to the next through the link the user actually follows, and re-established as first-party on arrival.
doozerEcoLink($url) to carry ashort-lived ?dzauth= token. The destination root reads it via get_user_token / adopt_user_token, mints its own first-party session, and drops the token from the URL. The user lands signed in, on a cookie that root is allowed to set.
get_admin_jwt and kept in localStorage,which is per-origin. Each standalone surface bootstraps admin state from its own storage rather than expecting a shared cookie (see admin tools must never reach regular users).
The non-obvious part is refusing the shared-cookie mental model entirely and treating every root as a separate origin that must re-earn the session on entry. The token lives in the one thing that does cross origins cleanly, the link the user clicks, and never in ambient storage that the browser will quietly wall off. Any new root (NBMN today, GoHe.re tomorrow) is not "wired into the cookie"; it just has to implement the handoff endpoints. It is more moving parts than a cookie and it is the version that still works in a partitioned-cookie world. Same instinct as implicit verification: carry exactly the minimum identity signal, exactly when it is needed.