{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/activitypub/issues/319","repository_url":"https://api.github.com/repos/w3c/activitypub","labels_url":"https://api.github.com/repos/w3c/activitypub/issues/319/labels{/name}","comments_url":"https://api.github.com/repos/w3c/activitypub/issues/319/comments","events_url":"https://api.github.com/repos/w3c/activitypub/issues/319/events","html_url":"https://github.com/w3c/activitypub/issues/319","id":356566449,"node_id":"MDU6SXNzdWUzNTY1NjY0NDk=","number":319,"title":"Disable replies","user":{"login":"nclm","id":923008,"node_id":"MDQ6VXNlcjkyMzAwOA==","avatar_url":"https://avatars1.githubusercontent.com/u/923008?v=4","gravatar_id":"","url":"https://api.github.com/users/nclm","html_url":"https://github.com/nclm","followers_url":"https://api.github.com/users/nclm/followers","following_url":"https://api.github.com/users/nclm/following{/other_user}","gists_url":"https://api.github.com/users/nclm/gists{/gist_id}","starred_url":"https://api.github.com/users/nclm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nclm/subscriptions","organizations_url":"https://api.github.com/users/nclm/orgs","repos_url":"https://api.github.com/users/nclm/repos","events_url":"https://api.github.com/users/nclm/events{/privacy}","received_events_url":"https://api.github.com/users/nclm/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-09-03T17:04:59Z","updated_at":"2018-09-05T14:30:44Z","closed_at":null,"author_association":"NONE","body":"Almost all blogging platforms and a few social networks (for instance Dribbble) allow the author to disable replies on their post. So that ActivityPub-enabled platforms are up to usage on that, I think it’s necessary to have the possibility to send posts with a standardised “replies disabled” tag added to them.\r\n\r\n(Not knowing the standard, I’m using the “tag”, “post”, etc. without the proper terminology.)\r\n\r\nActivityPub clients must at least:\r\n- Respect the “replies disabled” added to posts by either hiding, greying out, or crossing any “reply” icon or other interface used for replying or commenting.\r\n\r\nClients probably should:\r\n- Hide any replies to posts with “replies disabled” enabled, if ever some got through the net. At least to the author.\r\n\r\nClients can if they wish, or if it makes sense, do one or a few or all among these:\r\n- Enable or disable this feature by default.\r\n- Allow users to enable or disable this feature for each of their post.\r\n- Allow users to change their default posting preference.\r\n\r\nFor platforms that have no sort of interface for displaying comments or replies, it could also make sense for them to enable this feature by default (unless they are fine with people commenting the posts on other platforms even if the discussion does not federate back)."},"comment":{"url":"https://api.github.com/repos/w3c/activitypub/issues/comments/418752441","html_url":"https://github.com/w3c/activitypub/issues/319#issuecomment-418752441","issue_url":"https://api.github.com/repos/w3c/activitypub/issues/319","id":418752441,"node_id":"MDEyOklzc3VlQ29tbWVudDQxODc1MjQ0MQ==","user":{"login":"cwebber","id":55698,"node_id":"MDQ6VXNlcjU1Njk4","avatar_url":"https://avatars2.githubusercontent.com/u/55698?v=4","gravatar_id":"","url":"https://api.github.com/users/cwebber","html_url":"https://github.com/cwebber","followers_url":"https://api.github.com/users/cwebber/followers","following_url":"https://api.github.com/users/cwebber/following{/other_user}","gists_url":"https://api.github.com/users/cwebber/gists{/gist_id}","starred_url":"https://api.github.com/users/cwebber/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cwebber/subscriptions","organizations_url":"https://api.github.com/users/cwebber/orgs","repos_url":"https://api.github.com/users/cwebber/repos","events_url":"https://api.github.com/users/cwebber/events{/privacy}","received_events_url":"https://api.github.com/users/cwebber/received_events","type":"User","site_admin":false},"created_at":"2018-09-05T14:30:44Z","updated_at":"2018-09-05T14:30:44Z","author_association":"COLLABORATOR","body":"So we have to be careful about \"request policy\" / \"advisory policy\" things that *ask* a good participant to behave correctly.  That can still be useful, but it's important to remember what will happen if either a bad or negligent participant ignores the behavior.  If we don't consider that, we might accidentally allow bad / negligent participants to be more abusive than they were before we implemented the protocol, because we will violate the expectations of good participants when what they suddenly see that intent is violated.\r\n\r\nSo let's consider what we can do.  There's what we can do within current reply conventions (not very powerful, but advisory) and what we could do much better if we changed things more dramatically with a capabilities approach.  I'll focus on the former, but if people are interested in the more capability-centric approach which *can* more powerfully restrict these things I could write it up as a separate post.\r\n\r\n- So, initially Alice makes a post about her cat with no explicit `replyPreference`, which defaults to \"replies are ok\".  Her friend Bob replies, and Alice favorites his reply.  This is the simplest case.\r\n\r\n- Alice makes a post about her recent dancing performance but marks it as `replyPreference` to `NoReplies` or some such value.\r\n  - Bob's client politely disables the reply button, and Bob does not reply.\r\n  - Mallet's client, through malice or negligence, does not disable the reply button, and Mallet distributes a snarky message `inReplyTo` Alice's post.  We must remember that the protocol *cannot prevent* an `inReplyTo` another person's id that is already known, so instead we should ask, how do Alice and Bob's clients render the reply thread?  If they were expecting that clients MUST not render the reply button or send replies, perhaps their clients would be lazy and expect that any inReplyTo objects must be fine because all clients are behaving correctly.  But clearly this would be upset and hurtful to Alice.  So we might say, their clients should actually expect that other clients might behave badly, in which case maybe they check the `replyPreference` to decide whether to allow any further replies.  At any rate, there is nothing we can do to prevent bad or negligent actors to continue commenting on the post and to continue seeing those replies, even if nobody else does.\r\n\r\n- Alice makes a post about some food that she cooked and initially gets a reply from Bob that she likes, but then people start dogpiling and she decides to change her `replyPreference`, and well behaving clients respect this but Mallet still sends replies.  This is the hardest case because a new problem appears: should we render the messages that happen before Alice updates her replyPreference?\r\n  - If we say \"no\", Bob and Alice might be upset that Bob's comment now disappears, because Alice did not intend for *previous* posts to stop appearing, only new ones.\r\n  - If we say \"yes\", we have now added a new complex state management problem where all participants need to tag posts as being displayed or not displayed comments depending on when the reply comes in.\r\n\r\nAnyway, that's all to say that this is trickier than it appears, and writing the code to \"enforce\" whether or not the client MUST show the reply button or not does not actually enforce itself the behavior in the system, and there are complex decisions and state management problems we must consider if this feature is introduced.\r\n\r\nAnyway, @nightpool is right, there's absolutely a couple of ways to do this from a capabilities perspective that get the behavior that people want to be able to more carefully control what are and aren't considered legitimate replies, but that's work-in-progress research on my end and may end up requiring that servers rethink how they do things."}}
{"actor":{"display_login":"cwebber"}}