moja.blue
baldemo.to
I think Mezzanine has figured out something important. It's possible to make rooms in a public network by creating lenses through which to view it. An opaque identifier, rather than hiding a post, simply makes it easy to scope. People have a "frequency" through which to find each other.
I've been working on a proposal called Composable Trust (https://muses.baldemo.to/3mg6rjnlfws25) that tries to solve a different problem -- specifically, community governance on the AT Protocol. However, I think our two projects can lift each other up to create coherent, protocol-native communities.
Composable Trust has 2 primitives. Rosters issue credentials. These are self-authenticating records signed by the Roster's key. They are irrevocable; to remove someone the Roster publishes a withdrawal record with stated reasoning, which acts as a signal for downstream services. They aren't the space where people hang out, as they simply define who belongs within a community.
Venues are services that scope to a Roster. They decide which credentialed members are welcome in their particular context, and have a final say over what gets surfaced. Venues work from Roster credentials to create a curated space within a community that already has a shared foundation of trust.
For a community to feel real, however, members need a shared space to be in. This does not mean just another feed to scroll. It should feel like a room that you can walk into. Consider:
- An algorithmic feed scoped to a credential works from a shared trust foundation. However, it isn't intentional. People don't choose to show up there.
- A topical hashtag-based feed (e.g. #art) is intentional, but it's a topic space, not a social space. People who aren't interested have no reason to be there. (By lacking a shared trust foundation, Mezzanine might default here).
A social space is different. People are there by choice, and float freely within it. Their affinity isn't for a topic, but for each other's very presence.
Mezzanine is how you make rooms in an open network. Combined with Composable Trust, this can turn rooms from topic spaces to true, honest-to-God social spaces for communities.
Consider:
A Venue publishes a policy record declaring its existence. That record has a TID. That TID becomes the Venue's Mezzanine-style identifier. Every post from credentialed members intended for the Venue contains an outline tag with that TID. The client handles the tagging for the user, either by displaying a checkmark to add the tag or simply adding the tag automatically while they're "in" the Venue.
On the user's end, the Roster's page shows Venues as tabs. When you switch into a Venue, the interface shifts into a blank slate. Only posts from credentialed members that carry the Venue's TID are surfaced. The Venue's page acts as a hub. Users can build feeds scoped to the tag, discover other active members in the space, and compose their own experience within it.
Composable Trust provides a shared foundation of trust. Mezzanine provides the rooms where members mingle. The user gets a familiar, tangible social space, built entirely from metadata on public posts.
This is the "open" case. But, of course, some community conversations aren't meant to be public. They aren't secret, but they're private/intended for the community only.
Buckets, as Daniel has described them, don't know about communities. They're just DID-permissioned containers within PDSes. But, what if every member had a bucket whose ACL references the Roster? 'Valid credential + no withdrawal record = access'. This would create a distributed repository for private community content.
This allows for 2 kinds of community posts:
- Public. Posted to public repos with the Venue's TID as an outline tag. The Mezzanine pattern works as described above. The "room" is an intentional lens over the open network.
- Permissioned posts: Posted within community buckets with the same TID as an outline tag. Same credential verification and same routing, except the data is only readable by members. The room has real walls now.
Venues may set up a convention, but members can choose at any time whether a post is public or permissioned.
In this architecture, Mezzanine's pattern becomes the routing layer for the full community stack. Whether a post is in a public repo or inside a Bucket, the Venue's TID is ultimately what scopes it. Mezzanine is the connective tissue holding communities together into coherent, general social spaces.
Credentials provide the trust, Venues and Mezzanine provide the room, and Buckets provide the walls. Together, I think they make something we can genuinely call a protocol-native community.
I'd be really curious whether this resonates with where you see Mezzanine going. I think there's something real in how these pieces fit together.
This resonates. Let me respond to the architecture, then push on one point.
Where the pieces fit
Your framing — credentials provide trust, Mezzanine provides rooms, buckets provide walls — maps correctly onto the layer separation. Mezzanine was designed as a routing layer, not an access control layer. The tag points without signifying. It has no opinion on who gets to read what. That makes it a clean fit as connective tissue across both public repos and permissioned buckets.
The Venue TID as Mezzanine-style identifier works. The tag format needs extension — current Mezzanine tags are 3–5 alphanumeric characters, while TIDs are timestamp-based — but that is an engineering problem, not a design problem.
The critical point: inside and outside are not two kinds of post
Your proposal frames public and permissioned as two distinct post types. I'd push back on that framing, not the mechanism, but the mental model.
Mezzanine was designed around one core principle: the boundary between inside and outside should be blurred, not hardened. A tag creates a lens, not a wall. People with the right lens see more; people without it still see something. The space is the same. The depth of visibility changes.
This matters because of what I'd call the locked-account failure mode. Twitter/X's locked accounts draw a hard binary: follower or not, visible or not. The problem isn't technical. The boundary works as specified. The failure is that human trust is not binary. Relationships shift. Someone you trusted shares a screenshot. The hard wall, once breached, offers no graceful degradation.
Your design already contains the fix. "They aren't secret, but they're private." That's exactly right. If a community operates with most conversation in public and only some in buckets, a leak from the permissioned layer doesn't collapse the entire space. The public layer is still there. The room survives.
So rather than "two kinds of posts," I'd frame it as a single continuous space with variable depth. The tag is the same. The credential determines how deep you can see. This keeps the architecture identical to what you've proposed — the implementation doesn't change — but it shifts how users and client developers think about the space they're building.
Prior art: Skyblur
This pattern — layering visible and hidden content on the same post — already has demand on Bluesky. Skyblur (skyblur.uk) implements a spoiler-text system by storing the unredacted original in a custom collection (
uk.skyblur.post) while posting the redacted version publicly. It works, but it's an app-level hack with no protocol-level access control. Anyone who queries the PDS directly can read the original.What you're proposing with Composable Trust + Mezzanine + buckets is the protocol-native version of what Skyblur does by brute force. That existing demand is worth noting.
Open questions from my side
Roster credential verification at the bucket level: Daniel's Diary 3 leaves access control as an open problem. How does a PDS verify that a requesting app holds a valid Roster credential without introducing a trusted third party?
Tag leakage: if a public post carries a Venue TID, the existence of that Venue (and who's posting to it) is visible to anyone. For some communities that's fine. For others, even the membership signal is sensitive. Is there a design where the tag itself is opaque to non-members?
Withdrawal semantics: you describe credential withdrawal as publishing a record with stated reasoning. How do downstream services (Venues, bucket ACLs) propagate this in practice? Especially for partitioned buckets where each member's PDS independently enforces access.
I think there is something real here. Let's keep building.