Yes, but not within the current single-feed-space design.

Right now, person A’s reply is written into your feed space in actions.ts. The access check only asks whether the reader is mutual with the feed owner in checkUserAccess.ts.

Once person B receives a credential for your feed space, Spaces lets them read every record in it. The protocol explicitly says that read access is all-or-nothing at the space boundary, with no per-record or per-author grants. Permissioned Data proposal

The proper fix is to partition interactions into spaces based on their audience:

• Your original post stays in your at.secretsky.feed/self space.
• A’s reply goes into a separate audience space.
• For a direct A → you reply, that space authorizes viewer X only when X is mutual with both A and you.
• B fails that check, so B’s PDS cannot obtain a credential for the reply’s space.
• The reply keeps a cross-space strong reference to your original post. Our reply schema already represents the parent as an AT URI plus CID.

For nested conversations, the audience space should inherit the parent’s requirements and add the new author. Records can share a space only when they have the same audience. That may mean one space per distinct audience set. Spaces’ managing-app policy supports this kind of dynamic authorization using the on-protocol follow graph. Managing-app policy

Reactions have the same leak and should use audience spaces too.

We could immediately hide unauthorized replies in the secretsky UI, but that is only cosmetic. B could still fetch the reply through the Spaces APIs while it remains in your feed space. Existing replies would need to be deleted and recreated in their new spaces, changing their AT URIs, and anything already downloaded cannot be recalled.

I recommend implementing audience spaces rather than relying on filtering. That gives the privacy rule actual protocol enforcement.