A Portable Scheme for Semi-Private Community Spaces in the AT Protocol

This writeup was based on a conversation about @furryli.st between me and lead dog @codingpa.ws .

Assume the existence of an app.bsky AppView which can only be used by a curated, public list of users. This whitelist consists of a tightly knit cluster of users (furries) who frequently communicate amongst themselves, while still interacting with the broader network regularly. In all other respects, the AppView is functionally identical to the current bsky.app AppView.

As with many tightly knit clusters, this cluster has internal cultural norms and discourse which clash with the wider network. These clashes often result in negative social interactions. Because of this, users within the cluster limit their engagement with certain discussions pertinent to their cluster. This discourages open, constructive conversations within the cluster.

One possible way to ameliorate this problem is to implement private cryptographic records, such that certain posts can only be seen and interacted with by users within the whitelist. However, this solution is hard to implement conventionally.

The list used for this gating must either remain static from the time of record creation, or change dynamically with new additions and removals in the list.

If the list remains static from the time of record creation, this would lock out new users from old discussions. It could also present safety issues if users removed from the list can still see and interact with the posts.

If the list changes dynamically based on the current state of the list, this would allow the host of the whitelist complete control over who can interact with gated posts.

Moreover, any cryptographic solution would likely be difficult to scale to lists with tens or hundreds of thousands of users.

A better solution might be a 2-pronged approach using already existing tools:

Create a “shadow” lexicon for records intended only for the cluster. This shadow-lexicon would be identical to and interoperable with the original lexicon. However, other AppViews would be explicitly discouraged to publish or parse these records if they do not intend to cater to the cluster.

Within the AppView, exclude shadow-lexicon records by users who are not a part of the whitelist.

This has several benefits. The most important one to me is the lack of lock-in to the cluster’s AppView host. It’s already possible to create a duplicate whitelist if the original list is compromised. In a similar way, with this design, if, for any reason, an alternate party wishes to create an alternate AppView for the cluster, they simply need to spin up a new AppView that serves the shadow-lexicon, and use the existing whitelist to exclude non-cluster replies.

This would also create a new network dynamic to tinker with. It’s entirely possible for an AppView to serve both the app.bsky lexicon and the shadow-lexicon. Yet, it’s also entirely possible for an AppView to only show posts using the shadow-lexicon. This, in conjunction with whitelist filtering, would essentially create a cluster-specific social app.

It is important to note that, unlike a cryptographic solution, this scheme does not provide true network-wide privacy. Any actor could spin up a client and see records using the shadow-lexicon. Furthermore, if a large AppView decided to serve records using shadow-lexicon, records using that lexicon might still lead to negative social repercussions for members of the cluster.

However, by using a high-quality whitelist (such as @furryli.st ) as an AppView-wide filter, the AppView could nonetheless create a safe space for members of the cluster, free of any unwanted intrusions by outsiders. Although the conversations would remain public, the impact of bad actors on cluster-specific conversations would be mitigated.