An Experiment in Separating Identity, Memory, and Tools
Key topics
Delving into the uncharted territory of identity, memory, and tools, a developer's experimental project, XCTBL, has sparked a lively debate about its purpose and design. Some commenters, like viraptor, liken it to a fusion of Urbit, S3, and Kerberos, while others, like andai, admit to being baffled by the project's dense vocabulary and sci-fi undertones. As the project's creator, promptfluid, clarifies the scope and intent behind XCTBL, a more nuanced discussion emerges, with some, like pineaux, grasping the concept of a persistent, user-agnostic memory system, while others, like dwb, remain skeptical, calling out the project's "insufferably pompous" presentation. The thread remains engaging as it navigates the fine line between innovative thinking and obfuscating jargon.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
N/A
Peak period
11
36-42h
Avg / period
3.6
Based on 25 loaded comments
Key moments
- 01Story posted
Dec 26, 2025 at 8:42 PM EST
8 days ago
Step 01 - 02First comment
Dec 26, 2025 at 8:42 PM EST
0s after posting
Step 02 - 03Peak activity
11 comments in 36-42h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 30, 2025 at 1:42 AM EST
4d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It’s an identity layer for tools that require persistent state — but it deliberately separates identity/authentication from recording and retention.
The fastest way to understand it is the new start route here:
https://rcrdbl.com
RCRDBL is the records layer. It accepts signals (files, text, artifacts), retains them permanently, and does not authenticate users.
XCTBL is the external system that creates identities (“Stars”) and manages access to tools that need persistence.
The separation is intentional:
• One system remembers. • One system authenticates. • Tools sit on top.
There’s optional narrative framing, but it’s not required to use anything. Tools work without engaging with the story layer.
This is early, opinionated, and intentionally constrained. Curious how others think about permanent records, identity boundaries, and whether this kind of separation makes sense.
The difference (for me) is scope: I’m not trying to replace an OS or invent a new universe. It’s intentionally narrow—persistent records first, identity second, tools layered on top.
The language is opinionated, but the constraint is real: records shouldn’t depend on accounts by default.
I'm going to miss the days where these signs were obvious.
The short version: RCRDBL is just a place to drop things that should persist (text, files, artifacts) without accounts. XCTBL is a separate system for identity/auth when persistence needs ownership.
If you’re not interested in permanent records or identity boundaries, it probably won’t resonate—and that’s okay.
The story layer exists because most tools hide weak models behind dashboards that feel coherent. This flips that: the system model is explicit, and the UI adapts to how people actually reason.
You can ignore the story entirely and still use the tools.
Check back on the first of the month. Space will double in size.
I’m trying to be explicit about the constraints rather than persuasive about the outcome. If the ideas or implementation don’t stand on their own yet, that’s useful signal — I’d rather expose that than hide it behind polish.
Appreciate you calling it out.
The benefit is durability and reuse: records can persist, move, or be re-associated without being owned by a single app or login. Identity is layered on top rather than baked in.
Tools operate on records they have explicit access to (by Star / capability), not global visibility. Spam is constrained by identity cost and rate limits, same as any system — decoupling doesn’t imply openness.
If this ends up being a bad abstraction, I want that to fail visibly rather than hide behind a conventional model.
The deeper bit is the default: records persist without accounts, and identity/auth is a separate layer that only shows up when ownership is needed. The UI is just the thinnest slice of the model.
“Fair point — that’s totally valid…” come on, are we supposed to just pretend this is an acceptable submission? I’m all in for vibe coding but at least be upfront about it and don’t waste other people’s time and energy.
What’s this supposed to be?
https://XCTBL.com
That entry is experiential-first. RCRDBL is the records layer; XCTBL is the place to understand the model by walking through it.