[protocol] Questions and remarks about Interaction Policies

[ClearlyClaire]

Hi!

We are currently working on quote posts in Mastodon, and one essential feature we want is control by the quoted person on who can quote them. Given the similar purposes, we had a look into your Interaction Policy proposal (we are also interested in at least reply controls, but that's something we'll tackle later, and quote posts may be a good way to evaluate that approach in practice and at scale).

In doing so, we have encountered a few shortcomings, possible improvements or questions. I will try to summarize them.

Implicit policies

Our most immediate use case is to represent policies for quoting, which is not defined in your document, but a canQuote policy seems like a natural extension of your proposal.

However, we would not immediately support interaction policies for the other kind of interactions, so it would make sense leaving them out, but according to your documentation, leaving a policy out is equivalent to outright denying interactions, which is not what we want to do.

I suppose we could have as:Public in always, but it slightly bloats the messages while kind of implying that we support those policies in any way, and it brings up the issue of changing the policy after the fact (this is expanded on later in another section).

Revocation of previous approvals

One thing people tend to expect, and that we are intent on allowing wrt. quote posts in Mastodon, is revoking approval for an interaction (see Bluesky's functionality to “detach a quote”).

I suppose it could be done by occasionally re-checking the approvedBy activity or sending and forwarding Reject activities (with no guarantee they would reach everyone who processed the approval in the first place though), but this is not discussed at all in your documentation.

Changing an existing policy for a more restrictive one

Say a post exists without a policy, or with an "always": "https://www.w3.org/ns/activitystreams#Public" policy, and gets some interactions.

Because those interactions are immediately allowed by the always policy, they bypass the approval flow and do not carry an approvedBy attribute.

Now, say the user has changed their mind (or the software they use has been updated to support policies) and do not want any more interactions without approval, specifying a more restrictive policy. From the user's perspective, this should not invalidate existing interactions.

However, already-issued interactions did not need and did not produce an approval activity, and do not refer to one in approvedBy, meaning that third-party servers cannot verify them.

One idea that I had though I don't know how much sense it makes, is mandate that the approval activity, if it exists, can be dereferenced at a deterministic address that would be enough for the approval-granting server to evaluate and grant approval on the fly, e.g.: the authorization for a reply https://reply.example.com/users/123/statuses/456 to a post https://origin.example.com/objects/1234 could be queried at https://origin.example.com/objects/1234/interactions/reply?uri=https%31%2F%2Freply.example.com%2Fusers%2F123%2Fstatuses%2F456

(This would not mandate that this is the identifier of the approval, but that would also be possible)

Ambiguity of approvals

In your proposal, you re-use Accept and Reject to represent approval or rejection of an interaction, relying on actor and object to identify the interaction.

This works for your examples, but can be ambiguous. Indeed, consider a reply that is inReplyTo two different posts are more (this is typically not handled by microblogging software, and in particular not by Mastodon, but this is allowed by the specs and some software support it). How to handle a rejection or an acceptance then becomes ambiguous. Even moreso if multiple posts being replied to are from the same person.

The issue rises in the context of quote posts as well: a quote post could be in reply to another post, and be subjected to two interaction policies of different kinds at once, a reply policy, and a quote policy, and you may want to react differently to a rejection from one or the other. For instance, in our design, a revoked quote approval would mean the quoting post still exists but the quote itself is replaced with a placeholder. But if we are quoting and replying to the same person and get a rejection (or an approval that gets retracted), it is not possible with your proposal to tell which interaction was denied.

Scaling

Your proposal requires every third-party server to fetch an approval for every interacted post, which can generate a lot of traffic if a post gets interacted with by a popular account.

I unfortunately do not have any idea how to improve that, except for the use of a short-lived inline signature to ease with the initial distribution, but it would still behave as badly if the interaction gets shared after the signature's expiry.

At least the approval document can get cached.