[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.

[ClearlyClaire]

Adding a couple questions I thought about when the repository was locked for the holidays:

Approval type swap

An attacker could obtain approval for one kind of interactions (e.g. liking a post) before swapping the activity and type with something else (e.g. a reply). That being said, this is a difficult issue to solve, as having the type hardcoded would not prevent e.g. swapping a reply with another one that has different contents. The only way to fully avoid that kind of things is to sign the accepted activity in the approval, but that comes with many drawbacks.

Private collections in always

Your documentation says valid URIs for always include the followers and following collections. However, in multiple fediverse software projects, the contents of these collections can be private. I was not able to find anything in your documentation that describes how a third-party server can check that an interaction is indeed allowed when such a private collection is in always.

[tsmethurst]

Alright! Back from holidays, gonna have a crack at answering these questions now :) I'll start with the brief ones.

Private collections in always

This one's covered here: https://docs.gotosocial.org/en/latest/federation/posts/#validating-presence-in-a-followers-following-collection Basically, in this case the interacter should wait for approval from the interactee before broadcasting the activity with the Accept URI attached, as there's no other way in the current setup for remotes to validate presence in a followers/following collection. We could implement some FEP or follower synchronization method for this in the future, maybe, but for now this was the simplest way of handling it.

Approval type swap

Yeah it's definitely not watertight, indeed someone could swap the contents of an approved reply for something else. They can also do this using edits if they want to. In future we might want to encourage interacters to revalidate statuses or something by requesting a new Accept from the interactee, or having the interactee put a digest in the Accept activity so that remotes can check what's actually Accepted. Not sure yet.

Scaling

Indeed we rely on in-mem caching and request throttling for this. The situation isn't much different from someone with lots of followers boosting a post. So far we haven't seen any issues with this but it's worth bearing in mind as Mastodon servers (which tend to have a lot more users + users with a lot more followers) also start to adopt interaction policies.

Implicit policies

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.

This is definitely open to changes :) I'm the one who wrote that part of the document, but afaik it's not really being used yet, GtS always just sends everything. I only added it for the sake of trying to eliminate undefined behavior. If you'd rather that leaving a policy out is equivalent to as:public then that could work as well, all good for us!

Revocation of previous approvals

Yeah that's definitely a gap! If I remember rightly in the code we treat Reject as a revocation, and handle side effects appropriately but that's not mentioned in the document. This is something to ponder and something that should definitely be added.

Changing an existing policy for a more restrictive one

I guess this is similar to revocation in that if you're changing to a more restrictive policy, we'll have to think about this one a bit more as it's quite tricky indeed, especially the point you raise about interactions that are implicitly permitted and therefore don't carry an Accept URI with them.

One way of handling this, I suppose, would be for the interactee's server, when the policy changes, to send out Accepts to all interacters whose interactions were already implicitly accepted due to as:public, so that the Accept URIs could be added to those interactions at the moment the policy changes, allowing those interactions to remain.

Alternatively, though this creates a lot more traffic, would be for the interactee to always generate + send out an Accept even for interactions that are permitted implicitly.

A third (much less preferable) option would be for the interactee's server to send out Rejects to all interacters whose interactions would be rejected by the new policy, essentially "clearing" those interactions. I don't really like this though. When you close discussion on an issue or a forum or whatever, you don't wanna delete the history of the discussion :') At least, not usually.

a deterministic address that would be enough for the approval-granting server to evaluate and grant approval on the fly

I was toying with a similar idea, I think maybe we discussed this on the fedi or on discord at some point? I don't quite remember. Ideally I'd like to avoid introducing a new endpoint if possible, as it requires further protocol extensions. But maybe it will be necessary. Not sure!

Ambiguity of approvals

Yeah! This is similar to something mentioned here: #3460 Basically I wanted to avoid introducing types like AcceptReply, RejectReply, AcceptLike, AcceptAnnounce etc etc as it's just a bloody mess when you consider all the different types of interactions you might want to accept or reject. But perhaps there's a neat way of hinting within an Accept or Reject exactly what you're Accepting or Rejecting.