Can we have moderation and blocking ideas built into this?

[inmysocks]

I think that these should be in the specifications in order to help with moderation tools in the applications themselves.

I think that at a minimum we should have definitions of how to handle when one server doesn't want to hear anything from another server (so on the sending side what behaviour is required when there is no response, or a connection is refused and on the receiving side this should be allowed)

I am sure that there are other times, like handling specific identities on a server.

It is certainly something I would appreciate on GitHub and something like this is going to need moderation tools of some sort.

[pwoolcoc]

this, for sure. I'm of the opinion that any kind of social platform that doesn't incorporate mod tools from the start, is just asking for trouble

[yookoala]

Can you suggest what could be done in the protocol to facilitate moderation?

[inmysocks]

I do not think that there are a lot of things that would need to be added at the low specification level, but things like in the pull request part of the spec put something like 'The upstream server MAY silently reject any downstream pull requests based on the configuration of the upstream server.'

There is nothing in what I have read that disallows it, but explicitly stating that it is a possibility at that low a level would prevent a lot of the trouble when people start implementing compliant servers and add tools to them because they won't have to argue about if it is breaking the spec or not.

I think that the general rule should be that anywhere that describes a server responding to a remote request should include the explicit possibility that the request can be rejected silently. It is much less adding behaviour that is required as explicitly saying that there are places where doing nothing is acceptable.

The silent part is important for moderation tools because if there are problems telling someone that they are explicitly banned often leads to harassment via other channels, or in more extreme cases it is used as a badge of pride to be banned from server x, while a silent rejection of the request or failure is just something not working.

[marrus-sh]

It seems like some aspects of this are still under discussion/development, but definitely in the case of any ActivityStreams objects which are created; e.g.,

{
  "type": "Branch",
  "id": "https://git.example.org/my-repo/",
  "name": "My Repo",
  "inbox": "https://git.example.org/my-repo/inbox/",
  "outbox": "https://git.example.org/my-repo/outbox/",
}

it should be clear that access to these objects (the URLs https://git.example.org/my-repo/, https://git.example.org/my-repo/inbox/, and https://git.example.org/my-repo/outbox/, in the above example) MAY require authorization.

ActivityPub outlines behaviours regarding this clearly in Section 3.2, but it should be made clear that this applies to GitPub objects as well.

(This seems particularly important for whitelisted servers which may not want to federate out information to anyone without credentials———although i'm not sure if all of the pieces are quite in place on the ActivityPub side to support that just yet. It's also how ActivityPub softwares like Mastodon keep their not-public things not public?)

[jaywink]

ActivityPub already has the vocabulary for this, mainly the Block, Ignore and Flag activities. So IMHO nothing new is required on the protocol level.

Behaviour patterns should also IMHO be defined higher up in the ActivityPub - there is nothing VCS or code hosting specific in these kind of blocking/moderation processes.

I seem to remember there was lots of discussion related to blocks and whether they should be federated or not during the SocialWG but I don't think anything ended up in specification. I think this spec is the wrong place to make those recommendations though, would continue in the SocialCG repo: https://github.com/swicg/general which is the ideal group to discuss these kind of common elements in the social web.

[inmysocks]

publicly viewable actions taken like that aren't helpful in terms of avoiding harassment and the like. The silent part of what I suggested is important.

[nightpool]

@inmysocks block ignore and flag aren't inherently publicly viewable actions. In fact, activitypub specifically says that block activities shouldn't be delivered to their target, and etc.