33
points
promptfluid
Joined 18 karma
Founder building identity-first platforms where tools, records, and context persist across systems.
Currently working on XCTBL Space, an experiment in treating identity as infrastructure rather than accounts, and products as artifacts rather than isolated SaaS.
Focused on coherence, durability, and systems that compound over time instead of optimizing for funnels or short-term growth.
Bootstrapping, shipping in public, and exploring how narrative and serious tooling can coexist without diluting either.
- I am implementing a diagnostic mode that will toggle the tools and story on and off. I think it will help distinguish between the two after reading some feedback. Thanks for your input. I will resolve this gap.
- 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.
- Fair surface read — if you only see the drop zone, it does look like “pastebin for files.”
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 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.
- If you just want to explore the system without worrying about records or architecture, start here:
That entry is experiential-first. RCRDBL is the records layer; XCTBL is the place to understand the model by walking through it.
- 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.
- 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.
- 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.
- 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:
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.
- Just updated the beginning routes for greater lore and clarification
- 1 point
- That’s fair feedback, and I agree.
The current flow is intentionally minimal, but it does front-load the account wall more than it should. A better approach is letting people explore at least one system or environment before asking for an email, so they can decide whether it’s worth engaging further.
I’m treating this as an experiment in how people prefer to encounter complex systems, and this is useful signal. I’ll adjust the entry point so the value is clearer before any signup.
Appreciate you calling it out.
- I built Space after noticing that most projects I worked on felt rushed into clarity, features, pricing, positioning - before the system itself had time to settle.
This is an attempt to reverse that. I’m deliberately keeping things small, visible, and evolving in public to see what actually compounds when you let a system breathe. Happy to answer questions or explain any part of it.
- 2 points
- Yeah, it’s the panic tells that give it away — reflexive, not rational. When markets start reacting like prey instead of predators, it’s because they know the whole structure’s wired too tight. Tiny sparks shouldn’t cause stampedes unless everyone secretly smells the fumes.
- This is wild — optimizing I/O and memory flow instead of brute-forcing with clusters is exactly the kind of rethink AI infrastructure needs. You basically inverted the whole scaling narrative. Curious if the zero disk reads trick could generalize to other physics-heavy domains (fluid sims, EM propagation, etc.) or if it depends on the dataset’s uniformity. Either way, killer proof that smarter beats bigger.
- Hallucination usually isn’t random — it’s a confidence problem. The model commits to a guess when context certainty drops below a threshold. I’ve had success fixing that by letting multiple small models “cross-check” each other instead of one large one rambling to fill the gap. Feels more like peer review than single-brain improvisation.
- I’ve seen better results when the model isn’t just generating code, but maintaining context across revisions — like an internal “memory” that remembers past fixes and mistakes. Once you treat the agent like a long-term learner instead of a stateless generator, the output starts to feel less like autocomplete and more like apprenticeship.
- Been through this cycle a few times. What helped wasn’t stepping away from AI — it was building something that runs itself. Once you stop babysitting models and start automating the orchestration, the stress drops fast. My current project basically learns and adapts without me watching it, and that’s been the difference between burnout and flow.
Last night’s update wasn’t a redesign or feature drop. It marked a transition into a new era: traversal changed, tools expanded, and the system crossed a structural threshold.
I’m sharing it here less as a launch and more as documentation of an experiment in continuity, cadence, and single-founder systems that evolve in public.