NCE Feature Update 2026-05-06

It’s here — DFOS 1: Hacienda. What follows is the build-side runthrough that picks up from Yancey's last post. The next few weeks are going to be lively: a lot is landing in your space, the platform itself is changing shape under your feet, and the architecture is starting to open outward toward the wider DFOS protocol and the people building on top of it

Quick orientation on what's actually shifting. Spaces stop being a layout we ship and become something you compose — a desktop you fill out by installing and arranging apps. Those apps run on a kernel that's been deliberately shrunk to not know about chat or feed or any specific feature; chat is the first one to land on the new substrate, with effectively zero custom endpoints into the kernel itself. What's been an internal substrate up to this point is, this month, also starting to open outward — the same APIs we use ourselves, this time as a hard external surface for the wider DFOS protocol and the people building on it.

In your space today

The entry point is on your space's home screen — a Desktop Research icon you can click into for the new desktop experience. The desktop itself starts empty; you fill it out by adding apps, folders, and shortcuts, arranging them where you want them, and customizing each piece individually.

The new chat app is the centerpiece for now. Each room gets its own contained surface, with a quick room switcher instead of a long sidebar of channels, and the chat affordances you'd expect — threads, mentions, reactions, redaction, server-driven read state, pin/unpin — all carry over.

Check out the new chat in NCE now

The model these apps run on — chat being the first to land on it — is built to be small, modular, and instantiable in multiples. A space can install one chat app, or several, for whatever topology makes sense — one chat for the team's working rooms, another for casual rooms, another scoped to a specific group. The same will be true of the apps that follow. You're not committing to a single global layout for any of it; you can rearrange, split, merge, and rename as the space evolves. For existing spaces with current chat topics, migration tooling will move those topics into the new room model when you cut over, and once you're inside the new chat, rooms can be moved, merged, and renamed freely.

Around chat sits the rest of the starting kit. Folders that nest into other folders for real organizational depth, full drag-and-drop layout for arranging the surface the way you want it, and per-item icon customization so each app or shortcut on the desktop can carry its own visual identity rather than being forced into a global theme.

Shortcuts are doing more than they look like at first. A shortcut can point at any post on DFOS — yours or anyone else's, in any space — which is the first time we've supported cross-space post links at all. Access stays viewer-dependent the way it always has: if you don't have access to the post, or it isn't public, you don't see it, while other members of your space who do have access can. Shortcuts also work for any space on DFOS or any URL on the open internet, with custom names and icons baked in. This is the early shape of what cross-space interactions look like in the new model — connections between spaces that preserve the dark-forest property each space carries, where what each viewer sees is determined by their own access rather than by global broadcast.

What this amounts to is a desktop you compose, rather than one we ship you with our defaults baked in. Two spaces running Hacienda end up looking nothing like each other if you don't want them to.

What arrives over the next few weeks

Feed comes next, as a second app on the same platform that chat now sits on. It's also the next test of how cleanly the abstraction generalizes — how fast feed lands is itself a signal of how well the substrate is doing.

Feed landing also surfaces a property of the new model that's been mostly latent so far: the kind of cross-app surfacing you've already seen in legacy chat (post cards showing up in the relevant chat rooms) becomes a more general capability between apps, where any app can wire signals into any other in whatever combinations make sense for a given space. Over time, that wiring extends across spaces too — a chat app in one space surfacing activity from another, all of it preserving the dark-forest property where each viewer only sees what their access permits.

A few things from the previous platform are also getting their next pass in the coming weeks. Groups are the big one — segmenting a space's membership and gating access at the group level, with money and payment options layered on top for paid groups. Alongside groups, the finer-grained access control that's been missing comes back too: who can write in a chat versus who can read it, more nuanced permissions on posts, the kind of subtlety the older permission system was supposed to give you but mostly buried in cascading toggles. Each app, in this new model, handles its own permissions inside its own surface — less to reason about than one global access matrix, and more expressive in the leaves.

The post experience is also getting its next pass — viewing flows, drafts, the publishing surface — closing out the loop Yancey alluded to yesterday.

On the migration side: new spaces are about to start defaulting into Hacienda, and we'll keep running side-by-side for existing spaces until their migration tooling is ready and a clean cutover is in front of them. The eventual hard cut comes on its own timeline, with plenty of notice.

DFOS the product, DFOS the protocol

The other thing happening in parallel is on the platform side. The APIs we use internally today to ship our own apps — where the boundary between us and our apps is a soft trust line — will become a hard physical boundary for everyone else building on DFOS, with the external surface shipping this month.

Bigger picture: DFOS the product is a deliberately opinionated surface for integrating with DFOS the protocol underneath — the content chains, the relay mesh, the cryptographic substrate that all DFOS data actually sits on. As that surface opens outward, four things become possible, roughly in the order they'll arrive:

• Sign-In With DFOS — outbound identity, so external tools and services can authenticate against your DFOS identity rather than asking for another account. The spec is already published, integrations are queuing, and this is the closest of the four.

• External integrations — programmatic read and write against app data inside a space, from outside. Today this is the MCP shape, with people in this community already using it. Tooling parity and agent-aware permissioning follow.

• Third-party apps in your space — apps other people build, installing on the same kernel as 1p apps, with the same install model, the same realtime, and the same composability against the rest of the kit.

• Custom protocol frontends — apps built on the DFOS platform with full UX latitude, oriented around protocol-level constructs (content chains, beacons, identity flows, managed relays) rather than around a particular space's ecosystem. The platform mediates the protocol mechanics; the app shapes the product surface on top.

And true across all four: every app on DFOS, ours or anyone else's, sits on top of the protocol — custom space-level virtual relays, content chains, durable identity, replication. The protocol carries the heavy lifting, and the app gets to be a nice product.

Next week's update goes deeper here, especially on the SIWD piece. If you're building anything adjacent, or imagining where DFOS identity or protocol could plug into work you're already doing, this is the moment to start scoping it out.

A note on cadence

The way we're building the rest of the kit is to build the apps first — against the same interfaces that will eventually become the external API surface — and only then, once those interfaces are clearly shaped from real internal use, establish the physical boundary around them. Chat was the first big pass through that loop, and a lot of the OS interface design happened in the course of building it. The next few internal apps will go faster, because the substrate will absorb less of the work each time. By the time the internal app suite is rounded out, what "shipping the external API" means is essentially just establishing a physical boundary around an interface that has already been working internally for a while.

Practically, Ilya and I are building the rest of the kit live now, in shorter and shorter loops between something existing and someone using it. The persistent feedback dialog in the bottom right of your space is part of that — the more direct your input on what's working and what isn't, the more the things we ship next will reflect what people are actually doing in their spaces rather than what we think people might want.

What's in your space now is the foundation you build the rest from. The pieces still coming will keep showing up in front of you rather than behind a curtain — stay close, and let us know what you want to see.

More soon ✌️