4 ms·

We’ve been building a small system called XCTBL. It’s an identity layer for tools that require persistent state — but it deliberately separates identity/authen

We’ve been building a small system called XCTBL. 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 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.

andai 10mo ago
I don't understand anything on your website or this comment. Maybe I'm not the target audience?
- viraptor 10mo ago
  The vibe I get is Urbit meets browsable S3 with Kerberos on the side as the XCTBL project. It's half serious half art and uses confusing vocabulary on purpose. (I mean both Urbit and this)
  - promptfluid 10mo ago
    That’s a reasonable read, and I won’t dodge it. 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.
    - photon_garden 10mo ago
      Are you using an LLM to write all your replies?
      - deleted 10mo ago
        [deleted]
      - x______________ 9mo ago
        -Personal comment opener -Paragraph with English words that loosely fit together yet fails to convey an idea -Heavy and predictable em dash use I'm going to miss the days where these signs were obvious.
- promptfluid 10mo ago
  Totally fair. If it didn’t click, that’s on me, not you. 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.
pineaux 10mo ago
So if I understand it correctly, its basically a system where AI gets a persistent internal memory? and authentication works on another layer and everything is wrapped in a sci-fi story-system? Is it because other tools always give dashboards that dont actually make a lot of sense, just "feel logical" but dont really give a lot of usefull context?
- promptfluid 10mo ago
  Close, with one correction: the memory isn’t AI-owned—it’s system-owned and user-agnostic by default. 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.
dwb 10mo ago
To me this is all insufferably pompous. Drop the big talking and marketing and I would pay more attention. The quality of the idea and implementation should speak a lot more for itself.
- promptfluid 10mo ago
  Fair criticism. 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.
reilly3000 10mo ago
Records and documents are usually private and owned for various good reasons. I don’t understand the core concept of decoupling them. What is the benefit? How does one make associations or use tools? Is everything public? How can you prevent spam?
- promptfluid 10mo ago
  Good questions. Records aren’t public by default — they’re decoupled from accounts, not from access control. 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.

andai 10mo ago

I don't understand anything on your website or this comment. Maybe I'm not the target audience?

viraptor 10mo ago
The vibe I get is Urbit meets browsable S3 with Kerberos on the side as the XCTBL project. It's half serious half art and uses confusing vocabulary on purpose. (I mean both Urbit and this)
- promptfluid 10mo ago
  That’s a reasonable read, and I won’t dodge it. 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.
  - photon_garden 10mo ago
    Are you using an LLM to write all your replies?
    - deleted 10mo ago
      [deleted]
    - x______________ 9mo ago
      -Personal comment opener -Paragraph with English words that loosely fit together yet fails to convey an idea -Heavy and predictable em dash use I'm going to miss the days where these signs were obvious.
promptfluid 10mo ago
Totally fair. If it didn’t click, that’s on me, not you. 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.

pineaux 10mo ago

So if I understand it correctly, its basically a system where AI gets a persistent internal memory? and authentication works on another layer and everything is wrapped in a sci-fi story-system? Is it because other tools always give dashboards that dont actually make a lot of sense, just "feel logical" but dont really give a lot of usefull context?

promptfluid 10mo ago
Close, with one correction: the memory isn’t AI-owned—it’s system-owned and user-agnostic by default. 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.

dwb 10mo ago

To me this is all insufferably pompous. Drop the big talking and marketing and I would pay more attention. The quality of the idea and implementation should speak a lot more for itself.

promptfluid 10mo ago
Fair criticism. 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.

reilly3000 10mo ago

Records and documents are usually private and owned for various good reasons. I don’t understand the core concept of decoupling them. What is the benefit? How does one make associations or use tools? Is everything public? How can you prevent spam?

promptfluid 10mo ago
Good questions. Records aren’t public by default — they’re decoupled from accounts, not from access control. 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.