Who can reply (discuss) in ActivityPub

InReplyToPolicy.md

--- --- ---
see https://github.com/w3c/activitypub/issues/319

“ With that said: Sure, why not have something like:

a vocabulary item that is a property on Objects (same domain as as:inReplyTo) that is like "replyPreferences": "http://your-vocabulary.com/replyPreferences/NONE". There could even be specific pre-baked policy URLs somewhere for "don't reply to me" or "don't reply with curse words" or "don't reply with images" or "don't reply with r-rated images"
language that says clients
SHOULD inform potential repliers about these preferences
MAY prevent replying if the replyPreferences indicate preferring no replies.
language that says that servers
SHOULD try to enforce the replyPreferences when receiving replies in the inbox

” --- --- --- “The Q&A scenario becomes a bit more complex because there is a natural workflow aspect. ”

inReplyToPolicy

PixelFed "commentsEnabled": false, "capabilities": { "announce": "https://www.w3.org/ns/activitystreams#Public", "like": "https://www.w3.org/ns/activitystreams#Public", "reply": null },

DISCUSSION ITEM I author a post, who can reply?

inReplyToPolicy (functional, range: ReplyProfile | ReplyCollection) Class ReplyProfile is a subPropertyOf Profile

inReplyToPolicy MUST be of `ReplyProfile` which
- may have `startTime` and `endTime`
- MUST have `describes` which may be (ordered by precision)
-- an addressed Actor
-- as:actor      only I can reply (the Activity author).
-- as:to         matches only “Primary Audience”, Actors specified in `to`.
-- as:audience 		default behaviour, same as no value at all:
									the Actors that represent the total population of entities
									for which the object can considered to be relevant.
-- :followUnion 	matches people who are following me which I am following.
-- as:following  matches people I am following.
-- as:followers  matches people who are following me.

Anybody who replies must then be an Actor addressed in the audience. If multiple values allow an Actor to reply, then startTime and endTime are determined by the order of precision which means e.g.: as:to is more precise than as:audience.

Examples

// = "Only people in the `to` field can answer":
{
  "type": "Article",
  "name": "»Vögeln, fördern, feuern«",
  "url": "https://www.spiegel.de/wirtschaft/unternehmen/bild-chefredakteur-julian-reichelt-und-die-internen-ermittlungen-voegeln-foerdern-feuern-a-456152ee-eff8-4d8f-9b47-1284b4c36c09?d=1642429358",
  "inReplyToPolicy": {
    "type": "Collection",
    "items": [{
      "type": "ReplyProfile",
      "describes": "http://www.w3.org/ns/activitystreams#to"
    }]
  }
}
// Complex example:
{
  "type": "Event",
  "inReplyToPolicy": {
    "type": "Collection",
    "items": [{
      "type": "ReplyProfile",
      "summary": "appellant Max can answer",
      "describes": { "type": "Person", "name": "Max Schrems" }
    }, {
      "type": "ReplyProfile",
      "summary": "accused Meta can answer until 4th of July",
      "describes": { "type": "Organization", "name": "Meta Platforms, Inc." },
      "endTime": "2022-07-04T06:00:00-08:00"
    }]
  }
}

Nice idea. I like that Policies are a way to indicate the behaviour / heuristics that must be applied by a receiving endpoint.

Some remarks:

• Since inReplyToPolicy is a collection, shouldn't it be named inReplyToPolicies?
• Wouldn't a generalization to policies be a better approach? See below.
  • After all on all those objects there may be many different policies that apply.
  • An example for Article might be e.g. ReviewPolicy, RetentionPolicy, etc.
  • A receiving application processes policies it understands, ignores others.
• I don't find the vocabulary to be descriptive in terms of the semantics it expresses.
  • Without the summary I wouldn't be able to deduce what this does.

{
  "type": "Article",
  "name": "»Vögeln, fördern, feuern«",
  "url": "https://www.spiegel.de/wirtschaft/unternehmen/bild-chefredakteur-julian-reichelt-und-die-internen-ermittlungen-voegeln-foerdern-feuern-a-456152ee-eff8-4d8f-9b47-1284b4c36c09?d=1642429358",
  "policies": {
    "type": "Collection",
    "items": [{
      "type": "ReplyProfile",
      "describes": "http://www.w3.org/ns/activitystreams#to"
    }]
  }
}

The above was the result by the group discussion about “Who can reply”.

Since inReplyToPolicy is a collection, shouldn't it be named inReplyToPolicies?
See above, inReplyToPolicy is a functional property.
This means, there can only be 1 inReplyToPolicy per Object.
The difference between owl:Class, owl:ObjectProperty, owl:DatatypeProperty, owl:FunctionalProperty is important.

Wouldn't a generalization to policies be a better approach?

Semantically yes but technically not.
We would need to put constraints.
If we just have any Collection for policies then anyone could add e.g. 2 RetentionPolicy and 104 ReviewPolicy and 9 ReplyProfile-Objects.
We can do it but then we would need to specify if they form unions or intersections (like owl:intersectionOf, owl:unionOf, owl:complementOf) …

And we need to prove a need cause ReviewPolicy is basically used as ClaimReview in most places.
(The author of ActivityStreams is working for wikimedia/wikidata where “Everything is a Claim”) –

Normally a ReviewPolicy is not for Objects but for Actors.
See in the proposed extended Vocabulary for example number 94 which has for example
1754 actionable feedback policy
1874 corrections policy
1913 diversity policy
1914 diversity staffing report
1940 ethics policy
2073 masthead
2088 mission coverage priorities policy
2100 no bylines policy
2127 ownership funding info
2278 unnamed sources policy
2286 verification fact checking policy

so I think it might be better to specify such at the Actor level.

I can imagine that policies would be a nice session for the fedicamp !

Just wanted to point out that we currently allow the comment policy to be changed for any post/conversation (just like the audience), and tying this specific policy to the actor level appears to preclude this kind of granular setting.

@macgirvin Yep, all cited policies are at the Object level of course.
The domains/ranges/subclassOf are yet just in the OWL file, need to rewrite it to SKOS soon.
What I meant was specific for ReviewPolicy (in reply to Arnold).
In the world where I come from, a ReviewPolicy is what The Associated Press, NYT or Der Spiegel defines as an Organisation-wide Policy for all published things (correct me if a different thing was meant).
Also: What would a RetentionPolicy specify, what we can't do with AP directly?