DFOS Feature Update (2026-03-05)

Yancey's roadmap post covered the big picture — realtime rebuild, permissions, follows, announcements, moderation, MCP. This is the hands-on companion: what the new systems actually look like, how Yancey already used them to reshape this space, and what you can go try right now.

The short version: spaces can govern themselves and members can control their own volume. Within hours of these tools going live, Yancey had NCE reconfigured — four channels curated, four open, a new contributor role handing out posting rights. These sorts of controls are now available to all spacerunners. This post explains what they are and how to use them.

Access control

The roadmap post said "permissions got real." What does that actually mean? It means three layers that stack.

Space-wide defaults — admins toggle whether members can post, comment, or chat. Everything defaults to open, so nothing changes until someone decides it should.

Topic-level overrides — individual channels can break from the space default in either direction. In NCE right now, #share-your-work, #links-lore-memes, #art-circuits, and #chorus are open — anyone can post and chat. #ama, #dfos-nce-updates, #feedback, and #introduce-yourself lock posting — you can still chat there, but only admins and role holders author posts.

Role grants — unlock things for specific roles. NCE has a new one: Forest Keeper (you might have known it as Sicko). Forest Keepers carry a posting grant that lets them post everywhere, including the locked channels. Everyone else posts in the open channels and chats everywhere.

If you run a space, same tools are in Settings > Permissions. Lock posting and carve out one open topic. Create a role with scoped grants. Or go further: hide a topic entirely and grant visibility to a role — the channel only materializes for role holders, invisible to everyone else. The UI always reshapes to match what's available to you. If you can't do something, the surface just isn't there.

Space shape

Separate question — not who can do what, but what the space even offers. Admins can now kill chat entirely (posts-only), constrain post formats (short only, long only, both), and pick where members land when they enter. At one point yesterday NCE dropped you into the posts feed. We've since switch back to the home page. This is easily configurable.

Chat off means no chat tab for anyone. Short posts only means no long-form editor. A newsletter, a social feed, and a full community with everything on are just three configurations of the same thing.

Your volume

Everything above is admin-configured. This part is yours.

Notification settings are personal, per space — open them from the bell icon or space menu. The roadmap post mentioned these were coming. They're here.

Seven categories across broadcast (new posts, member joins, chat messages), conversation (comments, thread replies), and mentions. Defaults lean quiet — you hear about things directed at you, not everything happening in every channel. Turn things up or down per category to match how you actually want to use each space.

Watch and mute let you get more surgical than that. Watch a post to hear about every comment on it. Mute a thread to make it shut up. These override everything else.

This directly addresses what Yancey named last week — the notification anxiety, the feeling that being on DFOS means your phone is always asking something of you. It doesn't have to anymore. You set the volume.

For best results: add DFOS to the homescreen of your phone, then turn on notifications in your user settings. This will get push alerts sent to your mobile.

Other new things

Link previews — URLs in chat and posts now unroll into rich preview cards with title, image, description, favicon. You're probably already seeing these. Next up: in-app embeds — link to a DFOS post and get an inline post card instead of a bare URL.

Quote-reply — select text in any post or comment and hit the floating comment button to reply with a blockquote and auto-tag. This one's already getting a lot of use in longer threads.

MCP — the roadmap post mentioned the MCP server. What it didn't get into is the open question: how should agents and spaces relate to each other? How are they represented, what can they do, where are the boundaries? Some members are already running agents in their spaces. We're treating this as a live experiment and figuring it out as we go. There's a longer writeup and good conversation in clear.txt if you're there.

Legal — draft Terms of Use and Privacy Policy are up and pending review. Not final — we'll share more when they are.

What's next

Everything above is the raw system — all the knobs, no opinions. Here's where it goes from here.

The grants surface is already expanding. This week: announcing, moderating, and pinning become grantable — meaning a space runner can hand those capabilities to a role without giving out admin keys. More actions follow (inviting, topic management, etc). Same story on the notification side with more categories as new event types land, and the feature config surface grows too — things like disabling realtime presence in a space, opting into experimental features, controlling which surfaces exist and how they behave. The system doesn't change shape; it just gets wider.

Subscriptions and one-time purchases are shipping as another raw primitive in the same vein — plans, prices, Stripe binding, checkout, the ledger underneath. Expressive but mechanical, same as the permission system. Get the infrastructure right first, opinionated UX after.

Groups are that opinionated UX. A group bundles a role, its grants, topic ownership, and optionally a subscription price into one thing an admin creates. You don't think about grants and overrides and plans — you make a group and the group handles it. Subscribe, get the role, the role opens the doors. Groups are what make all these raw primitives feel like one system instead of six settings pages.

App shell and navigation refresh — right now every space looks basically the same. That's changing. Deeper homescreen functionality so space runners can shape what members see when they arrive — pin a post, feature a channel, surface a specific feed. Yancey's been sketching this and the design team is exploring the UX. Every space should feel like a different place, not a different instance of the same template.

Posts as distribution — announcements were step one. Next: consent-gated publishing to a space's public profile, announcement emails that grow into newsletters, and eventually cross-space reposts. Content travels outward from the dark forest selectively, deliberately, with author and admin control at every step.

Open source SDK and public API — the crypto and identity primitives extracted as open-source packages. A public API at api.dfos.com for DID resolution, operation logs, and proof verification — no auth required. If you're in clear.txt there's a longer post on the direction. The protocol layer becomes visible and portable without the social layer opening up.

View Source — an in-app experience that lets you inspect the cryptographic proof layer underneath any post or profile. The signed operation, the signer's DID, the content hash, the chain links back to genesis. Every piece of content in DFOS is already signed and content-addressed — View Source just makes that legible instead of invisible.

A lot of threads converging at once. The through-line is that spaces become more distinct, members get more control, and the platform gets more transparent about what's happening underneath.