@zenithlight that would reduce PDS-to-PDS traffic. The signature could also actually come from the account's signing key (facilitated by the PDS), which would work better with future account migration. A big benefit would be that while new writes would block until the PDS has responded (or be impossible if the PDS has downtime), reads would continue to be served, and read volume would not overwhelm a small PDS.

One complexity to work out would be key rotation: when an account (or PDS) signing key is rotated, do all the existing reply post records need to be updated with new signatures? Who is responsible to ensure that actually happens?

This feels like a fairly realistic solution for reply threads and quote posts.

This kind of gating would also work for other scenarios - for example, you could have a followers-only reply section, or "approved replies only" - it's up to the PDS to apply arbitrary criteria for allowing replies.

Rather than signing directly, why not "wrap" replies with a record that points at it? The record would be signed indirectly as a record in the repo, and so key rotation doesn't need any special consideration. It can also be federated though the existing federation mechanisms.

To elaborate, if user B wants to reply to a post by user A, user B creates and publishes a new post record like normal. However, this reply would not yet be visible in compliant clients. User A's PDS sees this record, and if it decides to (e.g. if there are no blocks in place), it creates an "authorizedReply" record, which simply contains a strongref to user B's reply. It acts as an endorsement - "I approve this reply to my post". Compliant clients will see both this endorsement, and the referenced reply, and decide to show it.

This has the bonus effect that 3rd party instances that directly federate with user A but not user B will still become aware of user B's reply, via user A's endorsement record.

Users could decide at time-of-posting whether they want replies to require verification in this way, with a corresponding flag set in the post record. If the flag is not present, replies can default to the original visibility behavior - so that users ok with "PvP" posting don't need to incur the overhead

This would also give users a lot of control over replies to their own posts. If they decide they don't like one, after the fact, they can delete the corresponding "authorizedReply" record.

We have separately been planning "interaction controls" to gate reply threads. Either simple "anybody/follows/nobody", or with composed reference to list. And probably OP labels would be applied to the entire thread to allow thread-local moderation, which helps with the "delete this post from my reply thread" feature. All of those mechanisms are public though, the difference with what is being discussed here is doing the gating via PDS interaction.

Another variation on the same ideas would be to only allow replies from a special "allowed-to-interact" list, published publicly similar to follows. Accounts that want to reply would connect to the OP's PDS and request to be added. The a negative reply would be private, a positive would be public (aka, added to the list automatically). All other network actors can see the list state and render accordingly, but the blocks and policy are not public. Solves the key rotation problem with regular repo process. Might scale weird with hundreds of thousands of replies? But even at the highest volume probably not crazy.

The "authorizedReply" concept is interesting. Similar to some ongoing discussions about forum-shaped spaces and interactions, which reply threads are spiritually similar to. It results in some reply amplification (multiple records in multiple repos). Does this need to be implemented for both the root of the reply thread (OP) and parent? If the parent blocks the "leaf" replier? I can't remember the specifics in that case.

Having PDS-to-PDS interaction at all will be a bit of a heavy lift if we ever decide to implement it.

There are two problems with the approach described in the SNARKBlock paper:

1. It requires a user that we are comparing against the blocklist, or some trusted service on their behalf, to do work linear in the blocklist size per attestation. There are various trade-offs for how you split up blocklists, and using newer techniques we can get the constant down (although the paper already includes some of the most obvious optimizations), but the linear-time asymptotic complexity is fundamental to the approach. Eventually you're going to have hundreds of billions of blocks, and there is not likely to be a proof system efficient enough to support that with reasonable latency for the foreseeable future. You can't even upgrade the proof system for those blocks; you're committing to doing those cryptographic operations (I think for each pair of users who try to interact, although like I say there are various trade-offs) for the lifetime of the platform — unless you just drop existing blocks at some point, which would be bad.

2. The blocklist contains the nonces of posts in the clear, and an author also has to know this nonce for their own posts. You don't get the id of the user who blocked you, but on another dimension this is more fine-grained information than you get from a public blocking system. In a public system you only get the fact that you've been blocked by a user, not which post caused them to block you (granted, you could possibly infer which post it was by timing).

Consider the consequences of feeding this data to an large language model AI. The AI gets fine-grained information about which of its posts are blocked, and after a while it gets very, very good at producing content that is propagated without being blocked. This is likely to be content of little merit (with some good stuff, but probably copied good stuff, mixed in) that people nevertheless want to propagate. It's going to be very plausible but completely without understanding, and when you interact with this thing you're going to be frustrated but just not frustrated enough to block it. Sounds like a nightmare to me.

I'm enthusiastic about applications of zk proofs, but I really don't recommend this approach.