Mezzanine and Composable Trust

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.