Mastodon: “Disable replies” feature

[nclm]

Most blogging systems and some social networks like Dribbble (possibly Instagram?) have a “disable comments/replies” feature. I wonder if it could be of use in Mastodon?

Adding a “Disable replies” checkbox in the privacy controls when posting a message would remove the reply icon (and possible other related UI) to the toot once it is posted. It won’t prevent the person to be contacted about the toot, but will not make it a one-click affair any more and might be an explicit way to dissuade potential comments about it.

If someone is posting something personal/controversial/etc in order shoutout/vent/etc about without the aim of starting a conversation, it could be useful.

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[Cassolotl]

I'd be curious to hear from the thumbs-down people why they feel this is a bad idea!

[codesections]

I strongly support this suggestion.

One additional suggestion: Could we have privacy settings for replies? In my ideal world, users could set three settings:

• Public (the current setting—anyone can reply)
• Follower only
• No replies

This would let someone receive some replies, but still retain some control over the number (especially if combined with approving follows).

[codesections]

I think this is a very positive suggestion in part because it would reinforce something I like a lot about Mastodon's culture: It is very welcoming to strangers joining in to a conversation (and making new Internet friends).

In contrast, Twitter has a strong culture of "what are these randos doing in my mentions?". That culture seems fairly toxic—not only does it explicitly push people away from some conversations, it also makes people who don't want to annoy anyone significantly more reluctant to join in conversations—even when their contributions would be welcome. I'd very much like to see Mastodon avoid this same dynamic.

Why do I think this feature would help avoid the dynamic? Wouldn't it just give people more tools to keep strangers out of their mentions?

No. What this feature would do is allow users to enforce something with technology instead of social pressure. The result of implementing this feature would be that people who don't set No Replies are explicitly welcoming replies—if you see a post that allows replies, you can be certain that the original tooter welcomes those replies. In contrast, right now or on Twitter, users have to guess about whether their reply would be welcome.

[Cassolotl]

I used to get a lot of unsolicited advice/criticism etc. in my mentions on Mastodon until I locked my account, way worse than on Twitter, so yeah - I think giving people the tools to make their lives easier and reduce the work involved in just posting something a bit controversial would be extremely helpful.

Mastodon-the-project talks a lot about anti-abuse features and curating a safe environment for yourself and whatnot, and we have a lot of tools now that make communication start with consent. I think this feature would be in line with that, giving people a tool to withdraw consent to respond.

I think for me I wouldn't need such granular control for the don't-@-me. If I wanted only my followers to be able to reply, I would probably set the post to followers-only anyway. But that's me!

[saper]

@codesections I was wondering a lot about reply "reach" (dislike the word "privacy" here) of the replies. I really miss replies on the public timelines - this is what I like on Pleroma that those get displayed there. I think that "no public timeline" could be the default setting for a reply if most people are concerned.
Having said that, I am not always sure if my reply to the existing thread is really welcome.

@Cassolotl thanks for calling me out, I'll consider that. For now I believe the emoji is quite an appropriate reaction.

[saper]

@codesections one thing that struck me once I re-read my reply. I think it is a pretty common case when two people are engaged in the exchange about something and not necessarily want to have somebody else joining in. How could this be solved (apart from switching to DMs of course)?

[rysiekpl]

I see why it's needed but I am just a tad concerned it could be used for dogpiling. Scenario:

1. Person A publishes a toot that is not popular with a particular crowd
2. people from the particular crowd start @-mentioning Person A in their toots, attacking them, but disabling replies on these toots, making it harder for the person to respond.

I still like the idea, so perhaps two potential ideas for a solution here:

1. make it impossible to disable replies on a toot that contains any @-mentions; or
2. if a toot has @-mentions, "disable replies" does not disable the replies from people who are @-mentioned in it.

I think I like 2. better here, since it would also enable the "public, but limited conversation" functionality (i.e. having a public conversation but with only select parties, as opposed to using DMs for that).

[codesections]

@rysiekpl, I really like your suggestion 2. I hadn't considered that threat, but you spotted it and came up with a great solution.

And that fits in well with how DMs currently work—anyone @ mentioned in a DM is included in the DM. So I think this would fit well with existing UX conventions.

[saper]

@rysiekpl but still even if solution 1 or 2 is implemented, people can still @ Person A ... (threat scenario 2), or am I missing something?

[Cassolotl]

@saper Like any abuse-reducing move, there are ways to circumvent it that take a little more effort. Like how we can't quote-toot, but we can take screenshots of toots in order to draw negative attention to them. I remember when people used "but a bad actor could refuse to honour delete requests" as a reason to not have a "delete toot" option. Sure, abusers will find a way to abuse, but making abusers have to work harder is still a good idea. Any barrier to abuse that has no downsides for good people is a good thing!

[rysiekpl]

@saper these were not two threat scenarios, this was a single scenario with two steps. And both solutions I propose solve it, since there is no way to dogpile on Person A by @-mentioning them but disabling replies (thus not giving them a chance to respond).

And that fits in well with how DMs currently work—anyone @ mentioned in a DM is included in the DM. So I think this would fit well with existing UX conventions.

@codesections exactly.

[saper]

ah, now I got it @rysiekpl - quite clever :)

Having said that I don't like this feature since this, again, creates artificial barriers in the conversation on the site.

I was thinking about something similar to this issue - to add an expiration date (say a week by default), after which it is no longer possible to respond or to boost the message. It could be useful to prevent spreading of messages that have only limited temporal importance and making sure old requests for help do not get boosted around forever, creating chain toots.

[thebaer]

Chiming in to say that besides liking this feature, I'd look forward to the Mastodon UI reflecting other AP platforms' choice in what they do with replies. For example, you can disable comments on PeerTube videos, and Write.as accepts no comments by default. Having some way for other platforms to set that preference on a per-post or per-user basis, and a visual indication of it in Mastodon, would be great.

[rysiekpl]

Having said that I don't like this feature since this, again, creates artificial barriers in the conversation on the site.

I really don't feel it does, @saper. It's as if you said DMs create artificial barriers in the conversation on the site. In fact, DMs create even stronger barriers! But they're useful and needed. So is this feature.

Most people will not use it for most things. But when it's needed it will be there.

Question is how to express this correctly in the UI/UX, but this is something that can be worked out, obviously.

[saper]

@rysiekpl You are right of course, but I am that kind of person who does not understand one-way channels on Telegram, always looking for a reply button there. Internet is a read-write medium to me :)

[kyefox]

Strong agree. I would like to have a way to make this default, at least for myself. I know, for example, when I toot about some annoyance/opinion with technology, I'll be bombarded with unsolicited advice/criticism that is one of:

• Irrelevant
• Missing the point
• Assuming too much (usually that they understand what I'm trying to do better than I do, which they usually don't)

500 characters is just not enough room to expand on the whole problem space I'm working with, so it's necessarily insufficient for seeking advice even if that's what I'm doing.

I could just avoid the whole block/mute dance and disable replies on the majority of toots where I'm really not looking for a response in that medium.

[matildepark]

Strong disagree. This bolts on strongly counter-intuitive features, in direct contradiction to the product’s strengths, because some users don’t understand what the product is for.

The Mastodon front end facilitates conversation, not broadcast.

In addition I’m unsure how you could enforce this outside of the Mastodon front-end itself. The entire setup is based on privacy and selective conversation. If users want to avoid most replies, there are tools to cultivate your conversation partners better. But this hypothetical feature introduces a ton of problems from a UX perspective and is the wrong solution to a user problem.

I think the tools are in place as it is; we can simply highlight their efficient use better.

[Madeorsk]

What's the point of disabling social features of a social network?

[kyefox]

Different people seem to have different ideas of what Mastodon is for, and none of them are alone. It's not as clear to me as it is to some that Mastodon has a single set of things it's for.

For me, it's broadcast-default like microblogs were originally made for, before Twitter twisted it into an impression-focused machine to please advertisers.

For others, it's conversation-default. Neither is wrong, but they are incompatible.

[Cassolotl]

What's the point of disabling social features of a social network?

A whole bunch of social features have been removed to discourage harassment, dogpiling, etc. Like, we don't have full text search, we don't have quote-toots, we don't have replies show up in the public timelines any more, etc.

Why would someone want to turn off replies/comments on any platform? It's a common feature on social networks and blogging platforms, that people use for various reasons, a lot of them outlined in the comments of this issue.

[saper]

This also has disadvantages: unjust statements go just unchallenged and left "as-is". Some people just vent out but they should be aware they do it publicly.

[Cassolotl]

Any barrier to abuse that has no downsides for good people is a good thing!

This also has disadvantages: unjust statements go just unchallenged and left "as-is".

If it's code-of-conduct-breaking, that kind of stuff can be reported. But if it's "unjust" people still have a right to withdraw consent for replies, no? The downsides (some people say some bad things and get blocked and if it's bad enough they'll get reported) don't outweigh the upsides (lots of people who are sick of speaking about their experiences/problems and getting trash in their mentions can save themselves a lot of work and anguish).

I get the feeling that you are approaching this from a very different perspective, because unsolicited awfulness is a very common experience for me, and to me it is an easy choice. Do you not get a lot of annoying responses when you talk about stuff that's important to you, or if you do, do you find it super easy to deal with them?

Edit: What I'm trying to say is, I think the good that could be done by introducing this feature would far outweigh any bad, but I am coming from the perspective of being a person who has to work quite hard to reduce the quantity of unsolicited 'splaining, criticism, advice, abusive comments, etc. So when someone who doesn't need the feature can simply ignore it, and people subject to a lot of that crap (especially marginalised people) could benefit from it a lot, and Mastodon claims to be a software that gives marginalised groups ways to reclaim their power and keep themselves safe, it seems like a very easy decision to introduce a beneficial change that would give a lot of people some peace of mind.

[saper]

I am sorry, I don't think the admins and code of conduct should be invoked every time "someone is wrong on the Internet".

Yes, I am that kind of person that responds to random messages on the timeline. Sometimes it is greeting new people, sometimes some discussions going on. I seek actively engagement. I guess my usage is totally different than yours (I thought you have left the network...).

I must say my signal-to-noise ratio is very high on Mastodon. I follow some people who annoy me with their opinions to challenge my point of view and I respond to them very carefully. I might have even respectfully responded once or twice to the "do not @ me" messages, since that was a right thing to do.

The thing is, how those two radically different visions can be combined on one network. There are some platforms (Wikipedia, for one) which have extreme ability to create communities with people of radically different worldviews to work together on one goal with relatively minimal friction. They don't do it by cutting out features; just people have common topic/issue to work on it and present different views.

I don't think that one-sided unchallenged venting off contributes to general health of the community.

[Cassolotl]

I don't think the admins and code of conduct should be invoked every time "someone is wrong on the Internet".

If "someone is wrong on the internet" then the world doesn't end if you can't reply, though!

I thought you have left the network...

I did leave for a couple of months, and I appreciated the break. It gave me time to think things over, and while I was mulling I thought of some ways to reduce the negativity I kept getting, and I'm giving it another try. I'm gradually making things better for myself on Mastodon, and it might still not work out but I'm at least going to give it a try!

I follow some people who annoy me with their opinions to challenge my point of view and I respond to them very carefully. ... The thing is, how those two radically different visions can be combined on one network.

Well, I'd say, don't follow people if they regularly post with don't-@-me if that frustrates you. And if you don't want to use the don't-@-me setting and you get replies from people who annoy you, what I would do is just mute them or block them. I think all of that can happily co-exist if you give people the right tools.

There are some platforms (Wikipedia, for one) which have extreme ability to create communities with people of radically different worldviews to work together on one goal with relatively minimal friction.

It's interesting that you bring up Wikipedia as an example, I had to stop editing there too when someone kept undoing my perfectly valid edits and the justice system in place there basically ignored me... :P

Wikipedia is a great example of a site that has very little "friction" and the users themselves deal with rule-breakers. If we're aiming for that, we too might end up with a userbase that's 84% male and has a serious sexism problem...

[zcdunn]

This is a federation issue therefore it should be handled by ActivityPub, not Mastodon. And based on this comment,

https://github.com/tootsuite/mastodon/issues/8565#issuecomment-417937457

other AP platforms already have this feature so it makes sense for it to be standardized.

[codesections]

Strong agree … [I dislike that] when I toot about some annoyance/opinion with technology, I'll be bombarded with unsolicited advice/criticism. … For me, [Mastodon is a] broadcast-default [medium]

Strong disagree. … The Mastodon front end facilitates conversation, not broadcast.

I want to put these two comments next to each other to highlight something: Right now, there are some people who use Mastodon for broadcast, and are annoyed by "random" users "butting in" with unsolicited advice/criticism. There are other people who use Mastodon to start conversations with strangers, and who welcome the ability to have new people join in.

I don't think that either of those approaches are right or wrong (disclaimer: I'm in the second group). But I think they're (frequently) incompatible.

Even worse, as an outsider, it can be very difficult to know which group someone else is in. It's very easy to accidentally view someone as starting a conversation when they just wanted to broadcast—which leads to hurt feelings. It's just as easy to mistakenly view someone as broadcasting when they wanted to start a conversation—which leads to missed opportunities for human connection.

This feature would neatly solve both of those problems. If people want to broadcast, then they can; if people want to start a conversation, they can do that too. And all the rest of us can know what someone wants just by checking their toot settings (and without having to guess).

[saper]

@zcdunn is this a part of a protocol or just what I call "client convention" (the way a client interprets incoming data) ? The spec seems to be pretty vague: https://www.w3.org/TR/activitystreams-vocabulary/#audienceTargeting

Also:

Responses to questions are expressed as Objects containing an inReplyto property referencing the Question.

I think there is nothing on the protocol level that prevents to set inReplyTo property by the client that does not know about the "no replies please" indicator.

[saper]

@codesections That's very insightful thanks! Sometimes I wonder what a broadcast mode really is. It reminds me of some corporate Twitter accounts. I think I have some issue with dealing with people who want to take air time but refuse to listen.

[Cassolotl]

Ahh yeah, corporate Twitter accounts! I think I'd probably hate them less if it wasn't possible to @ them at all - there would be no pretence that anyone might listen or reply...

[kyefox]

@saper

I think I have some issue with dealing with people who want to take air time but refuse to listen.

This is kind of bizarre to read. What gives you the impression that someone's refusing to listen when they broadcast? Even the things we get the word broadcast from have mechanisms for feedback! But that doesn't mean people responding have to sit there in the booth with me. I don't understand where you're coming from.

[saper]

Interesting point of view. I just thought it would be perfect feature for corporations to embrace Mastodon - "look, no stupid comments under our ads!"

[saper]

@digitalscofflaw if the replies are going to be disabled for the "broadcast mode", the only way to refer to what they are saying is subtooting, linking or something even worse (screenshots). That's what I'd call to refuse to listen. Of course the right to free speech includes the right to not to listen, if not interested. In other words: feel free to block me forever if you don't like my replies after seeing one or more. Or just ignore what I am writing.

But responding in the correct context is not the same as sitting in the booth with you. Besides, this booth is not only yours. Or did you purchase Mastodon frequency license and you are the only one allowed to talk here?

[kyefox]

@saper Still not seeing it. There are other ways to respond that help diffuse the toxic stuff I want to avoid by disabling replies. Setting a standard for response to protect my finite capacity to deal is not refusing to listen.

How about this: instead of disabling replies, set a preferred method of response and maybe provide a place to list expectations. I'd be okay with DMs since it takes out the performative aspect driving most of it, but I want people to know what to expect beforehand. I want them to know certain kinds of response will lead to a block or mute.

[Cassolotl]

I just thought it would be perfect feature for corporations to embrace Mastodon - "look, no stupid comments under our ads!"

Heh, maybe. :D But I think it's fair to say that:

1) If companies join Mastodon they'll get kicked off all our favourite instances.
2) Then they'd be forced to make their own instances (like how they make their own email domains) and then we'd block those too.

Also, because the world is a diverse place, there will be people out there who want to join Mastodon and also want to be able to follow their favourite companies on there to keep up to date with things and occasionally @ some companies with customer service type queries, etc. For some people being able to connect with their favourite companies is a selling point of Mastodon.

Anyway, I feel like I'm getting way off-topic so I'll stop there. :P

[saper]

@Cassolotl it's a valid point. There are few companies here, both on large instances as well as on their own. None of them are blocked.

[trwnh]

Looks like there are several threads emerging in this conversation...

1) What is the audience and intended purpose of any given post?
2) Which purpose or use-case should Mastodon support? What is Mastodon, fundamentally?
3) How does Mastodon interact with other ActivityPub platforms in this regard?
4) How can either preference be circumvented or lead to abuse?

Audience: who can reply, and when?

@codesections

One additional suggestion: Could we have privacy settings for replies? In my ideal world, users could set three settings:

1. Public (the current setting—anyone can reply)
2. Follower only
3. No replies
   This would let someone receive some replies, but still retain some control over the number (especially if combined with approving follows).

As @matildepark says, though:

I think the tools are in place as it is; we can simply highlight their efficient use better.

Under Mastodon's current privacy settings, the "public" privacy setting is, well, public. It has public reach. Not only can anyone see it, but you are also consenting to have it inserted into the public timelines where any random person can see it or reply to it. There seems to be some confusion about whether this consent is implicit or explicit -- you can and should post unlisted if you want it to be "public, not really public", i.e., audible to anyone nearby (your followers and visitors to your profile), but not blasted through the megaphones of the public timelines. If you want only your followers to be able to reply, then you can and should post followers-only.

These expectations are important because of...

Purpose: how/why are you using Mastodon?

@digitalscofflaw:

Different people seem to have different ideas of what Mastodon is for, and none of them are alone. It's not as clear to me as it is to some that Mastodon has a single set of things it's for.

For me, it's broadcast-default like microblogs were originally made for, before Twitter twisted it into an impression-focused machine to please advertisers.

For others, it's conversation-default. Neither is wrong, but they are incompatible.

Mastodon is opinionated software by design, and those opinions are largely based around making it a better place to communicate. But as this is an opinion, others may disagree. I would say that Mastodon is conversation-default and facilitates conversation; technologically and culturally, the software is primed toward emphasizing conversations. You follow people and dip into public timelines in order to find interesting things to talk about. It's a gathering place, not a soapbox or outlet. You are speaking in the company of others (the audience), not printing a journal without an inbox.

The inbox analogy is especially important, because of...

Interoperability: how does this work outside of Mastodon?

@thebaer:

For example, you can disable comments on PeerTube videos, and Write.as accepts no comments by default. Having some way for other platforms to set that preference on a per-post or per-user basis, and a visual indication of it in Mastodon, would be great.

@saper:

I think there is nothing on the protocol level that prevents to set inReplyTo property by the client that does not know about the "no replies please" indicator.

As we can see, platforms like PeerTube and WriteAs have found ways to disable comments, largely because of the way they are designed and the purposes they are intending to serve. The way they do this is entirely on the receiving end: PeerTube discards inReplyTo messages. Write.as has no inbox at all, AFAIK; ActivityPub there is mostly a read-only affair, so your boosts are ignored and your favorites become nothing more than private bookmarks.

It's still worth noting that those replies don't cease to exist outside of those softwares. Nothing is stopping you from replying to a Write.as post, and then your followers will receive that reply and can boost it, and it can propagate through to every single server on the network, potentially. As far as you and your followers are concerned, you made a reply. There is no such thing as "disable replies", only "ignore replies". As long as you have an inbox, your server WILL receive those replies. Your server can always discard them, but they exist elsewhere.

Because outside servers can ignore any potential feature, we need to consider...

Safety: what are the consequences?

@rysiekpl:

I see why it's needed but I am just a tad concerned it could be used for dogpiling. Scenario:

1. Person A publishes a toot that is not popular with a particular crowd
2. people from the particular crowd start @-mentioning Person A in their toots, attacking them, but disabling replies on these toots, making it harder for the person to respond.

@codesections:

It's very easy to accidentally view someone as starting a conversation when they just wanted to broadcast—which leads to hurt feelings [...] right now or on Twitter, users have to guess about whether their reply would be welcome.

@saper:

I don't think the admins and code of conduct should be invoked every time "someone is wrong on the Internet" [...] I don't think that one-sided unchallenged venting off contributes to general health of the community.

@Cassolotl:

we have a lot of tools now that make communication start with consent. I think this feature would be in line with that, giving people a tool to withdraw consent to respond.

What do these comments all bring up? Exercising power. Feeling hurt. Being wrong. Consent. Fundamentally, there are "expectation vs. reality" and "power play" dynamics here.

Worth bringing up https://xkcd.com/386/ here:

Are you coming to bed?
I can't. This is important.
What?
Someone is wrong on the internet.
(Alt text: What do you want me to do? LEAVE? Then they'll keep being wrong!)

If someone says something wrong and disables replies, then that's still within their right. Yes, it feels bad to see something go unchallenged, but also we should realize that a LOT of stuff goes unchallenged. You don't need to challenge everything. In fact, you _can't_ challenge everything. And even if you do, it probably won't be effective. Think of all the times you may have replied to some random thing on Twitter; did it change anyone's mind? A random passerby, perhaps? Maybe even the original poster? Probably not. In fact, they might have already muted you, or muted the conversation. They won't see it.

Now, the question becomes, do we want to encourage or facilitate that behavior? If we're going to do so, then what we gain should be significantly more valuable.

---

With those 4 things in mind, I think that any "disable replies" feature is not going to work how most people expect it to work.

What you can do right now:

• be mindful of your privacy settings and your audience; post unlisted or followers-only if you don't want your post to be broadcast to the general public
• click "mute conversation" on your own original posts; maybe it's worth automating that, maybe not?

What can be implemented in the current ecosystem:

• "discard replies", so that replies to that post are dropped, and loading the permalinked post on the original server does not show any replies to it; if this happens, users will have to accept that other servers may contain replies to that post. This may be what PeerTube does.
• finding, modifying, or building some other ActivityPub software that is explicitly targeted for broadcasting use cases, as opposed to conversational ones; this is what WriteAs does.
• a Mastodon-only extension of ActivityPub to make the reply button disappear on posts that are marked with some flag; similar to how currently private posts cannot be boosted, even to their original audience.

Whichever path is chosen, a lot of discussion needs to happen to assess the merits and negative downsides that it may bring.

[sireebob]

kind of a side note regarding management of replies: even if you block someone, they can still reply to your toots, and those replies are visible to other users, both on other instances and on your own instance (which doesn't prevent this at a server level).

the web app makes it harder, but if they're using a standalone app like tusky, and they are looking at one of your toots already, and you block them, they can still reply to it as much as they want. you won't see the replies, but other users will.

[kizu]

@sireebob I wonder if it is something that works as intended? As I (and a lot of other people) would totally prefer to hide the blocked people's comments from their posts for everyone, and this would be a totally proper thing to implement, as well would help with dogpiling.

Re: the disable replies feature itself — I'm strongly for it.

People should have a way to limit the replies to their toots. It is a question of comfort and safety. It is not something that would be enforced on everyone, so it is premature to think that all the accounts in Mastodon would suddenly become Telegram channels.

But no one shouldn't be obliged to listen to strangers from the internets. And no one should expect that another party wants to have a dialogue. Or to have a dialogue with those who they do not know (so — I'd want a “followers/mutuals-only” variant of this feature as well).

[ultimape]

A different way of framing this is implementing the "don't @ me" convention as a feature at the protocol level? A way to tell the originating server to "ignore all messages targeted to this toot when an activity is marked as a reply to", and a facility to expose this on boosted toots so that people who see it on their instance are able to tell that the author will not receive replies.

This could perhaps be construed as a mechanism by which 'this user has decided to mute replies to this toot thread' is optionally surfaced so that other's aren't talking into the void.

Of course this could be ignored by other servers, but we encounter that problem with regard to visibility settings already, so I don't see that as a good reason to not move forward.

Arguments toward "users fail to understand the purpose of this medium being about conversations" could be said about all the privacy and limited toot visibility features, but I understand the sentiment. I would counter that if people already are treating it as a broadcast medium by trying to police the "don't @ me" convention manually, then we should try to understand where that is coming from before rejecting it outright. There would be a lot less headache around that if it was codified in the UI somehow.

I personally use my account to talk to myself as a sort of public journal, and seek out those who do the same. We still have conversations over time by passively reading each other's toots despite being primarily in a broadcast way of thinking. Its still a conversation oriented medium when used this way - so personally reject the sentiment that this would be preventing the ethos of mastodon, but I understand that my particular usage is non-standard.

---

I propose we could make the idea simple to understand by displaying the feature as 🚫 symbol overlaying the reply arrow, surfacing it similarly to the CW button on the compose form. not-reply-able toots, we could display the same symbol in the space where you would normally hit reply. This would further leverage the symbolism around the dont-@-me convention that people are already gravitating toward in the wild.

A mock up of what it might look like

[aadilayub]

@ultimape wouldn't it be simpler and cleaner to just remove the reply icon?

[ultimape]

@aadilayub I don't think so. We'd get a million people complaining the reply icon is missing / a bug. The idea is to show that replying is not possible. This would be useful for cases where activitypub capable nodes, like peertube videos, have comments disabled etc.

Being explicit about it signals it was intentional. But It also allow for "at a glance" being able to see that you can not reply. It also can double up with the hover-text to give screen-readers a means to say "this post cannot be replied to" in a similar way that the lock icon says "this post cannot be boosted".

[ccoenen]

I'm not particularly _for_ or _against_ this feature (I haven't needed something like this, but I can understand everyone in here who expressed the usefulness of such a feature). What I am STRONGLY against is "just putting up another button" in the editor.

Oh my god, this dialog is starting to look like an MS Office Toolbar. I am _very much_ against that. Perhaps this is conceptially closest related to the privacy setting, maybe it can be incorporated into its dropdown? Or maybe there's another good solution somewhere else. But please let's not make this yet another button 3% of the userbase may or may not use.

[sireebob]

why not get rid of all the buttons, then, and just make a single button that does something different depending on how long you hold it

[kizu]

…and if you press the button exactly 4.2 seconds it would delete your account.

If being serious, then I'll welcome an extra button, but I think the best solution would be to have a button like the glitch-soc's … button, used for everything that is not needed right now.

And, ideally, I would like to see a way to configure everything in the settings — move some features inside this button to make the whole toolbar lighter, or more some features outside, if you're using them often. Or you could just disable some of those features in the settings if you're not using them much.

Giving people control over what is present in their toot toolbar (tootbar?), so they could set it up according to what they use the most would be nice.

[SWannell]

Was going to down-vote, but if this change request was met with rysiekpl's @-ing amendment, then I'm no longer against it!

One remaining word of concern - have seen comments in this thread along the lines of "I like this because if a person hasn't actively opted-out of replies, then I know it's fine to reply". Someone not withdrawing consent isn't the same as them consenting to something; people may want replies in general, but still not want replies from you.

[rysiekpl]

Oh my god, this dialog is starting to look like an MS Office Toolbar. I am very much against that.

Dunno, doesn't seem that crowded to me:

Perhaps this is conceptially closest related to the privacy setting, maybe it can be incorporated into its dropdown?

Yeah, that's probably the best solution. Although it would have to be a toggle/checkbox (you might want to select both: "only local timeline" and "disable replies", for example).

[kaniini]

@ultimape's proposal looks like it is fairly reasonable: if you enable the mode, the server will drop any replies to the post from your timeline/notifications, and a visual indicator is included to indicate that the author has muted any replies to the conversation thread. it also follows proper ActivityPub semantics.

[fsnk]

It seems like there's a lot of argument in favor of a feature to support users who want a "broadcast only" setting but what about the users who want conversation-based social media?

I haven't seen a proposal to give people the ability to filter broadcast-only posts out of their timelines. The suggestion of how this could be useful for brands who don't want negative replies is a perfect example of why, if people are going to have the option to broadcast @ without replies, people should also have the option to say "I'm not interested in being broadcasted at."

Also I don't really understand what this does for people who don't want replies that posting a normal post and immediately muting conversation doesn't. It doesn't actually stop people talking about the post and they can just post @ the user anyway, with whatever they wanted to say, which would make it harder to ignore the unwanted replies, especially in the case of a post which a lot of people may have strong opinions about.

This may also encourage sub-tooting, screen shots, etc, because people aren't going to sit quietly in their chairs and not talk about a public post just because the OP marked it for broadcast only. I think that's an unreasonable expectation when putting words out in the public areas of a social medium.

[Cassolotl]

It seems like there's a lot of argument in favor of a feature to support users who want a "broadcast only" setting but what about the users who want conversation-based social media?

They can just not use the feature...! Unless you mean, what do we do about people who are sad that they can't just reply to anything they like, in which case, I like your suggestion:

give people the ability to filter broadcast-only posts out of their timelines.

Stuff like that usually happens later, because it makes the feature a bit more attainable I think? But if someone who wrote a PR wanted to include that then that'd be fab, probably.

Also I don't really understand what this does for people who don't want replies that posting a normal post and immediately muting conversation doesn't.

So like, if there is a post and I want to reply to the person and it's not clear from context whether they're open to responses, it would be nice to know for sure that my reply won't be seen. If it's set to not accept replies, I'd rather not waste my time. I don't want to intrude into someone's conversation/life if they don't want responses.

It doesn't actually stop people talking about the post

As a person who would totally use this feature, I would be 100% okay with this. My point is that I don't want replies on this post. If they subtoot me I might never know and I'm okay with that!

and they can just post @ the user anyway, with whatever they wanted to say, which would make it harder to ignore the unwanted replies, especially in the case of a post which a lot of people may have strong opinions about.

I imagine it'd be a known thing, that if you @ someone about a post that was set to not accept replies, you will probably get justifiably blocked.

I think that's an unreasonable expectation when putting words out in the public areas of a social medium.

(source)

I keep seeing this all over the conversation here and on Mastodon, and it bothers me. Posting something where someone can see it does not automatically entitle anyone to respond and take up my attention and time and energy. Something posted online is not automatically fair game for debate and discussion.

Maybe back in the day when the internet was new and dominated by that kind of person it was okay and a fair assumption to make that all responses were welcome, but these days the internet is a lot busier and populated by more and different kinds of people, and the etiquette has changed accordingly. People @-ing me with unsolicited advice is rude, people @-ing me with anything when I just wanted to vent and be heard is not okay. If I want to just vent and not have anyone respond trying to help me with my problem that should be okay, and people shouldn't assume they can just reply to a total stranger without checking first if it's an open conversation.

Mastodon already has tools to limit who can see and interact with your posts. In fact the developers have put quite a lot of work into stuff like privacy settings. People objected to those features too, at the time.

[kizu]

It is fascinating to me how people still try to enforce their sealioning on other people.

There can be a lot of metaphors of what a toot, or a thread, or a conversation in a Mastodon is, but I don't think there can be (or should be) a single interpretation of it. Some people want to see it as a public forum. Others — as a conversation in a bar. Others — as a conversation in a cafe, only with friends by their table. Others — as a conversation in their kitchen with a closed door. Others — as a monologue. Others — as something else.

Everyone should be able to choose how they treat the service for themselves, but they shouldn't enforce their vision over everyone. Your right to talk is not bigger that their right not to listen to you.

And another thing I'd want to add — automuting the thread after posting wouldn't be the same at all. There should be a clean and strict way to disallow replies. As replies are oh so often used not to _have a conversation_, but to vent or harass, to make it so other people who would go to see replies to a toot would see this harassment. Harassers often want for everyone to see the trash and dirt they're throwing at people. There should be a way for people to protect them from this kind of harassment (and a linked issue — removing the replies by blocked people for everyone would also fit there as already mentioned in this thread).

[joereddington]

TIL about sealioning. Thank you. I've been so impressed by the tone of this debate.

I like the intent of this proposal, but I think conversations are good. I think the potential for abuse is enormous. I think it makes personal attacks easier, more impactful, and harder to defend against. It's exactly the tool I'd want if I wanted my 'team' to hound someone off a system.

[Cassolotl]

@joereddington

I think it makes personal attacks easier, more impactful, and harder to defend against. It's exactly the tool I'd want if I wanted my 'team' to hound someone off a system.

Do you think making it so that mentioned people can reply would help with that at all? I don't have an imagination for cunning abuse tactics!

[fsnk]

@Cassolotl

I keep seeing this all over the conversation here and on Mastodon, and it bothers me. Posting something where someone can see it does not automatically entitle anyone to respond and take up my attention and time and energy. Something posted online is not automatically fair game for debate and discussion.

I feel like this is getting off topic, but I'll reply anyway.

I don't think that's true as stated; something posted online _is_ fair game for debate and discussion. I don't think that something posted online automatically entitles you to a response from the creator (which I think is probably what you meant) but if you-the-creator put something out in a publicly accessible space, you don't get to control whether other people talk about it. This applies to the world in general, so I'm not sure why online would be a special case. Other people are allowed to have opinions on things, and they are allowed to say those things in places where the creator might be exposed to them.

I also think there's a distinction between _anywhere online_ and _social media_ specifically, where social media is designed with the intent that it's _social_ and there's a user expectation that interaction is the norm.

I don't go into an IRC channel, for instance, and start saying things and then finish by telling people not to reply. On the other hand, I turned off comments on my blog a lot and finally got rid of them altogether. Not even because replies are unwelcome; I just wanted people to be able to read and not feel obligated to reply because a comment box is being shoved in their face. Sometimes it should be okay to not interact.

People do occasionally email me or comment to me in other channels and I'm fine with that, because I said what I said where other people can read it and have feelings about it. (I either respond or ignore as I choose, because it's up to me whether or not to engage back.)

That said, I understand people want different things from social media. I think @codesections sumed it up well.

Right now, there are some people who use Mastodon for broadcast, and are annoyed by "random" users "butting in" with unsolicited advice/criticism. There are other people who use Mastodon to start conversations with strangers, and who welcome the ability to have new people join in.

I don't think that either of those approaches are right or wrong (disclaimer: I'm in the second group). But I think they're (frequently) incompatible.

I also think @codesections is spot-on about the frictions that those different uses cause.

I can see uses for locked reply, like you said, as an indicator that someone would be wasting their time responding, or with bots or crossposted posts where the account owner doesn't check or interact on the platform, it would prevent the misconception there might be a reply. I'm less convinced of arguments for its ability to prevent interaction with active users who feel that replies to something they post are an intrusion because of the reasons I've already explained, and there are some reasonable concerns in the discussion about how it could be used in an abusive way.

As @kizu said:

Everyone should be able to choose how they treat the service for themselves, but they shouldn't enforce their vision over everyone. Your right to talk is not bigger that their right not to listen to you.

Which is basically my point.

I'm not arguing against the feature.

I'm saying if there are specifically implemented features to enable non-interactive broadcasting, then features that allow the people who want interactive discussions to filter out the broadcasts should be part of the discussion.

[Laurelai]

https://www.rawstory.com/2018/07/meet-reply-guys-obnoxious-twitter-trolls-try-challenge-prominent-women-fail-miserably/

[nclm]

Hi! I wasn’t expecting this little idea to attract so much interest :)

I was wondering when I posted if it made sense, and after reading all of the conversation, I think it does a lot. So I am now strongly in favour of it. The pros go far beyond the cons, which seem to me mostly about not having personally a use for it or not matching a certain vision of the platform that is not based on relevant experiences for this issue.

In any case, whether it is adopted (hopefully!) or not on Mastodon, it has to be standardised anyway, and I can’t see any reason not to as it is a common feature on blogging platforms and sometimes social networks. It would be good if ActivityPub enabled any common usages that we’d like to replicate in a federated way. So I opened this issue over there: https://github.com/w3c/activitypub/issues/319 (I hope it is the right space for it).

As for having it on Mastodon I’m looking forward to see the following of that conversation, and I’ll try to think about and sketch an interface some time soon.

[Cassolotl]

I don't think that something posted online automatically entitles you to a response from the creator (which I think is probably what you meant)

That is not what I meant. I literally meant that readers are not entitled to directly respond to the writer about something the writer wrote.

but if you-the-creator put something out in a publicly accessible space, you don't get to control whether other people talk about it.

That is not what this feature request is about. I'm not saying people shouldn't subtoot and talk about their opinions about stuff. I'm not saying people should be able to control whether other people talk about their posts. I'm saying that people should be able to control whether other people can directly reply to a post they wrote.

[rysiekpl]

If anyone doesn't want to have "non-repliable" toots in their timeline, they can not follow people who use this feature.

I see how a "filter out non-repliable toots" feature could be interesting, but that's a secondary feature to the one here, so how about let's have this one implemented and then talk about the other?

I honestly fail to see where the problem is. There is literally zero chance this feature would change the character of Fediverse considerably and make it a "read-only medium". I mean, is anyone here going to suddenly only or predominantly post read-only toots? I am not!

On the other hand, as noted time and again, there are people who need it and there are situations where this is clearly a welcome feature.

I see zero reason to not implement it and plenty reasons to do it.

[codesections]

I feel that this conversation is missing an important element here: the option to disable replies can be a powerful anti-harassment tool. As @nolanlawson explained in his prominant blog post (https://nolanlawson.com/2018/08/31/mastodon-and-the-challenges-of-abuse-in-a-federated-system/), replies can be used as a powerful tool for coordinated abuse:

The attack vector looks like this: a group of motivated harassers chooses a target somewhere in the fediverse. Every time that person posts, they immediately respond, maybe with something clever like “fuck you” or “log off.” So from the target’s point of view, every time they post something, even something innocuous like a painting or a photo of their dog, they immediately get a dozen comments saying “fuck you” or “go away” or “you’re not welcome here” or whatever. This makes it essentially impossible for them to use the social media platform.

If a user is facing this sort of attack, then the ability to (temporarily) disable replies would be extremely helpful. Using this feature, the target of the attack can still communicate with their followers without that communication itself involving a large flood of harassing messages. True, the attack can shift to @messages—but those go only to the attacking user's followers and to the target. Crucially @messages do not go to other followers of the target, who may well end up seeing replies to the target's toots (indeed, they'd be likely to if they ever expand any of the target's toots).

This isn't a perfect solution to that sort of attack: the target would still face significant harassment that would need to be dealt with. But it would be enough to prevent the worst of it—the attack would no longer "make[] it essentially impossible for [the target of the attack] to use the social media platform"

For this reason, I suggest that it is worth including this feature even if we are not convinced that it's non-abuse-preventing utility would otherwise justify inclusion.

[fsnk]

@codesections as Mastodon is now, and given the nature of federation, I'm not sure that it's really feasible to implement post publication changes in visibility levels. Are you suggesting that users should have the ability to disallow @ mentions instead? I don't really understand how one post that people couldn't reply to anyway would stop the kind of thing you're describing?

[DawnPaladin]

Crucially @messages do not go to other followers of the target, who may well end up seeing replies to the target's toots (indeed, they'd be likely to if they ever expand any of the target's toots).

@codesections Why is this so crucial? How does preventing the followers from seeing the messages help the target of the harassment?

[ultimape]

I'm in agreement with the responses to my suggested mock-up with regard to the UI becoming cluttered. I believe that remaking the UI may be beyond the scope of this issue. It suggests that any changes in the compose-form may require rethinking the underlying infrastructure for the interface. There is a usability/learning curve/accessibility trade-off triangle here that those changes would touch upon and we would need to consider that issue separately.

It seems there are multiple concerns that could be addressed (or become issues) with this 'disable replies' feature. Some of which sound like they conflict with each other. Other conflated issues seem to step on the sacredness of Mastodon's purpose on our lives. Many seem to stem from fundamental senses of how we view social spaces at a cultural level.

With that in mind, I think its useful to see if we can carve off pieces of this idea that don't conflict with larger norms in the platform, and do not require a fundamental redesign of the UI.

---

A current design issue we are encountering in the wild is how other ActivityPub systems do currently have both 'no replies allowed' and 'replies accepted' mode, and it is awkward. There is currently no way to see the state of these activities within the Mastodon UI as there is no way for the user to infer this.

As currently implemented, learning about if they accept replies involves going directly to the other server's page and confirming there are no replies. Not only is this more complex than it should be, it will get massively more difficult as more and more ActivityPub systems come online.

We can not expect the user to maintain mental models of arbitrary software packages - services outside of the mastodon ecosystem. It is also worth considering that mastodon is accessed from a myriad of devices, and the activity's associated page may not even be functional in a browser.

So all the other issues aside, I think there ought to be a mechanism to show this state on a toot, even if being able to author 'dont-@-me'/disabled reply toots is not part of the mainline mastodon interface.

[codesections]

@codesections Why is this so crucial? How does preventing the followers from seeing the messages help the target of the harassment?

Because it makes the harassment private instead of performative. Consider a journalist writing for a major newspaper who gets a lot of hate mail. That really sucks and constitutes harassment. At the same time, it (usually) doesn't stop the journalist from writing—they can still submit their stories, and the vast majority of their readers don't even know that the journalist is receiving awful hate mail. That gives the journalist space to deal with the harassment in some other way—hopefully by getting it to stop, maybe by finding a way to filter it out of their inbox.

That sort of private harassment sucks, but it doesn't "make[] it essentially impossible for [the target of the attack] to use the social media platform"—which is what @nolanlawson said happens when every toot someone posts receives numerous harassing replies. Now, you might disagree with @nolanlawson; you might say that getting that many harassing replies visible to all followers shouldn't be any worse than getting private hate mail. But humans are social creatures, and I'm inclined to agree that being publicly criticised in front of people you care about is much harder to deal with than private hate mail. For one thing, it's much easier for the target to ignore something when they know that no one—or no one they care about, anyway—is hearing that harassing statement.

Are you suggesting that users should have the ability to disallow @ mentions instead? I don't really understand how one post that people couldn't reply to anyway would stop the kind of thing you're describing?

No, I'm not suggesting that users should have the ability to disallow @ mentions (in part because I wouldn't want that and in part because I don't think that's technically feasible). What I am suggesting is that a user could chose to turn off replies to all (or nearly all) of their posts for a short period of time when facing the sort of attack @nolanlawson outlined. Recall, @nolanlawson discussed an attack where a mob decides to attack an individual by replying to all of the target's posts with harassing comments. One feature of this sort of attack is that it takes a motivated mob—that means it's simply not possible to sustain for a long period of time. If the target could turn off replies for a short period of time, they'd have a good chance of waiting out the anger/energy of the mob. (Relatedly, the mob is likely to gain energy/momentum from making harassing statements; conversely, if replies are off, it seems more likely that the mob will get bored and lose energy/cohesion.)

[Cassolotl]

@DawnPaladin

Why is this so crucial? How does preventing the followers from seeing the messages help the target of the harassment?

I think another factor is that people are more likely to become aware of harassment and even join in with harassing someone when they see that other people and especially their friends are doing it. Some people follow other people just so that they can become aware of a harassment campaign and join in and back each other up.

[SWannell]

One of the philosophical differences here may be how we see 'piling on' as a tactic – (a) totally harmful (b) mostly harmful but sometimes useful (c) mostly useful but sometimes harmful.

If it's (a) then this is probably an uncontroversial feature request e.g. it provides vulnerable people a way to protect themselves from haters.
If it's (b) then this could be seen as a necessary evil.
If it's (c) then this brings a lot of risks e.g. it provides people who are repeatedly perpetuating harm one way to mask their behaviour.

Feels like this could be supported by some more formal outlining of requirements, costs, benefits etc.?

[DawnPaladin]

@codesections In that case, it seems like the goal of discouraging harassment campaigns would be better served by a toggle on the user's profile that would disable/enable replies to _all_ of a user's toots rather than having them go through every one of their toots toggling the feature on each one.

Any time you design a feature (even a feature intended to prevent harassment), it's important to consider "How could this feature be abused to harass someone?" In this case, I am concerned that no-reply toots will be used to defame people, who will then be prevented from defending themselves.

[codesections]

@DawnPaladin I think there's an important distinction between speech about someone and speech to someone. If I wrote a blog post that said "@DawnPaladin is a horrible person" and then went on to criticize you harshly, I don't think that would be harassment. It might, as you say, be defamation (if my criticisms contained false factual statements). It might also be awful, hurtful, or otherwise bad. It also might lead to harassment, if people read the blog post and then started harassing you directly. That hypothetical blog post may well be a sort of harm that Mastodon should be concerned with preventing. But I don't feel that it would be harassment: it's just speech about you.

Speech to you would be very different. If I sent you repeated DMs saying "You're a horrible person" and continued doing so after you'd asked me to stop, that would definitely be harassment—even if it didn't bother you nearly as much as the defamatory blog post.

It's my view that we ought to build Mastodon in a way that protects against harassment, even at the expense of not prioritizing protection against defamation. In part, this is because protecting against defamation seems much harder—it's always possible for people to harshly and falsely criticize others; so long as people have a platform to reach an audience, they can use that platform for defamation. Plus, many harsh criticisms are true and thus not defamatory at all. Social media, at its best (rare!) can provide a platform for speaking truth to power, and I'm not interested in taking that away.

So, in sum, I agree that we should think about trade-offs. But I think that the trade offs here favor protecting against harassment, even if that means that some people will be unable to respond (in a particular thread—they can always respond elsewhere) to defamation.

(Also, just to be perfectly clear: all examples above were purely hypothetical. I have absolutely no reason to think you're a horrible person!)

[codesections]

@SWannell

One of the philosophical differences here may be how we see 'piling on' as a tactic – (a) totally harmful (b) mostly harmful but sometimes useful (c) mostly useful but sometimes harmful.

I agree that this would be a major philosophical difference. It will be hard for people in your (a) and (b) groups to share a social space with people in your (c) group—they would favor totally different social norms and technical implementations.

My hope is that the Mastodon community can/does mostly agree on (a)/(b). My perception is that (c) is mostly a holdover from Twitter or other sites with badly broken moderation policies—when the "official" justice system is badly broken, sometimes vigilante mob justice is the least-bad outcome. But I wouldn't participate in the Mastodon community if I thought our moderation was that badly broken, and I hope that we can form a community of people who trust their local mods enough that they won't favor empowering mobs over those mods.

But that could be overly optimistic.

[oct2pus]

I don't have a personal problem with 'no reply' toots and i'd certainly welcome them, but I would prefer if they were unboostable because it could lead to abuse scenerios of call out posts based on bogus/misinterpreted/or otherwise based on really, really old content being passed around with 'replies' turned off, so nobody can find context/defense within the thread itself.

[mattbk]

I would prefer if they were unboostable

I like this idea because it balances the gain of one power with the loss of another.

[niacat]

Please make this an "untag me / disable all notifications from this post and hide all replies" button instead.

[DawnPaladin]

@codesections Thank you for your thoughtful response. I think you've described the trade-off eloquently.

According to the OP, this feature is intended to make it easier to "vent" without starting a conversation, and to post controversial stuff without actually starting a controversy. This may be an unpopular opinion, but I don't see those as valuable contributions to the Mastodon community. I think if you're considering saying something, but you know it will attract negative commentary, you should either be willing to stand up for your opinion (remaining open to the possibility of changing your mind) or remain silent. I am afraid that normalizing don't-at-me by building it into the software will result in lots of people sniping at each other, throwing grenades into the open from behind cover, instead of having an honest, pleasant discussion like we're having now, where people are open to the possibility of having their minds changed. I fear that having a button in the software labeled "give me the last word in this conversation" will be too tempting for people to resist.

But you've made your point well, and the abuse-prevention benefits may outweigh that. So I will hope I'm wrong, and wish you the best of luck.

[nclm]

According to the OP, this feature is intended…

Hi! I haven’t had time to read the current state of the conversation, but just popping in to make it clear, that I had no intent for the feature at first. I just saw the feature in every blog platforms and in some social networks, and opened the conversation to discuss its relevance in Mastodon. The example case that I wrote was a quick hypothesis, and I agree that “controversial” was a poorly chosen word here. If anything, I rather meant “sensitive”. But that doesn’t matter, the important thing is that the true use cases have been described afterwards by people actually wishing or needing the feature. Just don’t consider the clumsy first post as a note of intention that is still relevant :)

[Cassolotl]

I think if you're considering saying something, but you know it will attract negative commentary, you should either be willing to stand up for your opinion (remaining open to the possibility of changing your mind) or remain silent.

I have said a few times here already that being not-a-man on Mastodon means that all you have to do to attract negative replies is post something.

This may be an unpopular opinion, but I don't see those as valuable contributions to the Mastodon community.

None of us really get to decide what is valuable to the Mastodon community, and the community itself is very diverse, diverse enough that some bits of it will find venting and posting controversial stuff valuable to the community. It's also diverse enough that there are people who get reply guys all the time, and it also apparently contains so many people who are into this feature request that it's the second-most thumbsed-up open issue on the issue list after only a few days, when everything else that close to the top was opened in 2017 or earlier.

[saper]

I have said a few times here already that being not-a-man on Mastodon means that all you have to do to attract negative replies is post something.

I think using a "not-a-man" is just a moniker, which is only sometimes appropriate. A notorious asshole posting unacceptable stuff will and should attract negative replies from those who haven't muted/blocked that person yet.

[Cassolotl]

Yeah, obviously notorious assholes will get negative responses, and whether or not a mob of righteous people arguing with an asshole is good for the Mastodon community is very debatable.

But that's sort of separate from the point I'm making. A notorious asshole should be reported, blocked, suspended, etc.

[nclm]

A notorious asshole posting unacceptable stuff will and should attract negative replies from those who haven't muted/blocked that person yet.

A notorious really nice person posting totally acceptable stuff will but should not attract negative replies from those who that person haven’t muted/blocked yet. And still it seems to happen a lot, and in most cases that person is, precisely, "not-a-man".

[kizu]

A notorious asshole posting unacceptable stuff will and should attract negative replies from those who haven't muted/blocked that person yet.

No. It should attract the Report button, and should be handled by moderators. People shouldn't waste their time arguing with the assholes.

Basically: there are two possible scenarios:

1. Someone posts unacceptable by instance's CoC stuff with disabled replies. The only proper response — report it.

2. Someone posts acceptable by instance's CoC stuff with disabled replies. Well… where is the problem? If it is acceptable, then you're not entitled to have a conversation with the author. You sure can talk about it in your own timeline and with your friends, but you don't need to contact the author about it.

[trwnh]

@ensra

Please make this an "untag me / disable all notifications from this post and hide all replies" button instead.

That exists already; click the three dot menu and click "mute conversation". You will no longer receive any notification of replies below that point. If you do this at the top level immediately after posting it, you won't see any replies. The replies will still be there, though -- in general, you can't stop people from talking about you, you can only stop people from talking to you. This issue is fundamentally about breaking the chain between your post and the other people's posts (https://github.com/tootsuite/mastodon/issues/8565#issuecomment-417954590)

@DawnPaladin

I fear that having a button in the software labeled "give me the last word in this conversation" will be too tempting for people to resist.

I think this can be avoided with something several people mentioned above: prevent it from being used that way. One suggestion given was to let mentioned users always be able to reply. Another suggestion might be to limit the feature to top-level posts; that would be analogous to disabling comments on a YouTube video. If it's midway through, it'd be analogous to locking a Github issue; locking it to commenters/collaborators is analogous to only mentioned users/staff.

It can also be side stepped entirely by making a separate channel for no-reply posts, similar to Telegram channels (I think? I've never used Telegram, but someone mentioned it above and said there was a channel with no reply button...) This might be done with a separate outbox or a separate Actor that has no inbox, or by waiting for an official ActivityPub extension regarding reply permissions/preferences. Or, as is already possible in e.g. PeerTube, simply drop replies (with the aforementioned caveat that you can't prevent replies on other servers).

[kizu]

I think limiting the replies only for those who're mentioned is the best solution, and it could also provide some other use cases. For example a public interview between multiple people, or something like a public analog of a textual podcast (text-cast?) in a way no one would interrupt the flow with their replies.

And another interesting use case for the feature came to mind: when you're writing a longer thread, you can disable replies to every message except for the last, thus making it so no one would interrupt it. Yes, you would lose the ability to get a reply to a certain part of the thread, but sometimes this is not needed, and sometimes the opposite would be preferred: enforcing people to read the thread to the end, and only then reply.

And there could be other cases not mentioned there — this is a rather simple feature, but allowing for a lot of stuff, given even more creative freedom to authors, giving them the control over their platform. I can't really see how this can be bad, as this doesn't remove an ability for other people, to use their platforms to reply (as people often do with blogs and articles — writing their own posts in response, having a more public conversation this way; conversation in replies actually would be less public).

[allo-]

You are trying to let the sender set a flag, which the receiver needs to respect.

A toot has a inReplyTo field. You would like to add a "doNotShowReplies" field to the OP toot and rely on clients not to add inReplyTo toots to the conversations.
Clients programmers and instance hosters / fork maintainers have an incentive to ignore the flag, as it provides a feature (show replies, which ignore the flag as well) to their users.

The problem here is, that you effectively would need to ban the inReplyTo field in replies, which is not possible as you are only sending the OP toot, not the replies.
Your instance could drop replies, but other instances possibly won't. This means you and your instance will not see the replies, everyone else wil.
I guess this is not what you intended, as it will leave you without the replies other people will see and interact with.

[kizu]

@allo- I don't know how things work on back-end, and if instances can do something about it, but even if there is no way to deny replies at all, I still don't see this as a problem.

As with almost everything on the internet, you can link to stuff you do not own. And the inReplyTo is basically this kind of a link. But as sites do not oblige to post the links to those who link to them, toots shouldn't as well.

If this functionality would be implemented in the most clients (and I can imagine that it would — if it would be implemented at all), the existence of some more marginal apps that would violate that convention wouldn't really matter.

Thought, this would bring us to another issue (which would be offtopic for this conversation) — can/should instances have ways to block not just other instances, but all the toots from specific clients used for writing them? I can imagine if there would appear clients that would violate the common conventions, and would be used for harassment campaigns, it would make sense to bad those at instance level.

[allo-]

As with almost everything on the internet, you can link to stuff you do not own.
Most links do not leave a option to track them back from the linked resource. So when I post something about your post in my blog, people reading your post won't find it.

Your (patched or just outdated) Mastodon instance has both posts and attaches your reply to my post using a reverse lookup of inReplyTo toots even for toots with "doNotShowReplies" field.

can/should instances have ways to block not just other instances, but all the toots from specific clients used for writing them?

No. It is very easy to create a new client ID. Some tools open source like toot even do so by default, as you would have to trust the author otherwise not to use his client token to get you to give him a access token for other use than in your client.

I think I do not dislike the general proposal even when (or especially when) clients can ignore it, as I think networks with asymmetric relationships should have asymmetric blocking as well.
So just because I do not want to read your reply, this does not mean you should not be able to post it and other should not be able to read it. It's just me, who does not want to read the interactions.

[hellekin]

Such a feature would not stop people from replying: nothing can stop copy-pasting and mentioning. But it would help trolls thrive. Most spammers don't watch replies, that's why grey-listing works.

I am entirely opposed to technical solutions to social issues. If you don't want replies, don't watch the replies and silence your own thread. There's no reason to impose on the rest of the community to not be able to interact on a thread.

A better option then, would be to mute thread, which would simply make you deaf to it, not others mute to the world.

[Laurelai]

Muting wont slow down harassment waves, it only encourages them and then they can feed on each others toxic behavior. While tech cant solve social problems it can create tools that help defend people from bad actors. It can increase the difficulty of starting a harassment mob, which reduces the overall intensity and number of them. This is value in itself.

[hellekin]

You can disable "show replies" in your timeline. It's an existing feature.

[Laurelai]

That again doesnt help for the reasons i stated.

[hellekin]

What is a harassment wave worth if you can avoid it by muting it? You won't stop haters from hating. All you can do is avoid reading them.

[kizu]

@hellekin Your statement that disabling replies makes someone else “mute to the world” is incorrect. There were enough arguments to why in this thread already.

If anything, the ability for those who want to harass to reply without going an extra mile is a thing that actually mutes a lot of people to the world, making them go into locked accounts, making them write “don't @ me” — and still getting replies even to those toots, from the people who think they know better.

Those who reply to those who don't want to get replies — they're simply breaking boundaries. An option to disable replies is a clear statement of boundaries. Someone going an extra mile to harass would be a much easier thing to report than just sea lions throwing their pseudo polite conversations in mentions.

[Laurelai]

You have never been the victim of a harassment wave i take it? I have, often on and off for years. Muting. Does. Not. Help. Because they just grow more and more toxic and eventually can escalate into life destroying intensity. Ignoring problems doesnt make them go away. Preventing them from gaining a critical mass helps.

[hellekin]

I can see that backfiring very easily.

[Laurelai]

I literally have lived experience with this topic and im telling you that you are wrong. Situations where i was able to shut down comments on my own posts vastly reduced harassment waves. Most of the people involved got bored because it became too much effort to continue, not all of course, but most.

[hellekin]

What's the difference with you "disabling replies" and the person replying getting notified that you did? To me, this very use case would bring the best of both worlds since your attackers would know their reply would be ignored, but no troll would be able to "fire and forget".

[Laurelai]

Ive already addressed what you have said please read my previous comments.

[lawremipsum]

I just want to point out what I consider to be the relationship and commonalities between this issue and #8427.

The proposals are to put more control in the hands of status authors. They are to implement reasonable limitations on engagement that users are requesting—in this case they are endeavoring to implement themselves with the "do not at" emoji. And there are strong (privileged, comfortable) voices here and there opposing both proposed features.

From my perspective, the arguments against both features boil down to a position that the software should prohibit users from exercising control over their experience, out of a sense that it is better (wiser, more reasonable, more ideal) that they not have the option to engage with the network in a manner of their choosing—specifically, to choose to limit engagement.

This paternalism is unwarranted, and anti-user. It serves the interest of the audience. It's not clear to me why the audience, the toot-consumption side of the equation, should have it's interests so systemically overrepresented at the expense of even basic choices for status authors. The people who provide this network its content and value.

Let people choose their preferred engagement level, and more people will feel comfortable posting more things. This is a folkway that should make its way into code, not be kept out because of some people's debate society ideal for social networks.

[saper]

The proposals are to put more control in the hands of status authors. TThe proposals are to put more control in the hands of status authors.

This is an issue as old as the Internet. Unlike centralized platforms, the network cannot give a total control of the message to the sender. If one prefers that kind of control one is better off with the centralized message exchange applications, since everything there is manageable with a single piece of software, for good or bad.

[lawremipsum]

"Go somewhere else because [philosophical excuse dressed as technical necessity for not adding a feature]" is, I suppose, a choice a social platform can make. But it's weak.

[ashkitten]

my two cents: first of all, i don't care what kind of control you're able to give to the sender in a technical sense. this is easily fixable by just muting replies and/or blocking/reporting.

Unlike centralized platforms, the network cannot give a total control of the message to the sender.

sure, you can't control what other people do with your messages, but the same is true of centralized platforms. anyone can screenshot or otherwise save the content of your post for themselves. the point is to protect the user in question from harassment, which i believe a mute replies button does fine (and if i'm correct there's already a button to do that)

[codesections]

@lawremipsum I think this is an unfortunately black-and-white way of looking at a fairly nuanced issue. I respect you a lot from your other posts, so I think that it's worth digging in to why I believe you're mistaken here.

You talk about how both "proposals [would] put more control in the hands of status authors" but both are opposed by people who focus on "the interest of the audience". I agree—I think you've correctly identified the trade off under debate.

However, you seem to suggest that we should always side with the status authors over the audience, and I think that's far too black and white. In my view, we should weigh the each issue separately and decide—on the merits of the particular issue—which set of interests should be prioritized. To take a (hopefully uncontroversial) example: many status authors would like to be able to quote-toot, but Eugen has determined that quote-tooting leads to bad effects on the audience—specifically, it encourages the sort of dunking-for-popularity dynamic that makes Twitter so awful. In that case, the interests of the audience outweighed the interests of the status-author; this doesn't tell us that the interests of the audience should always outweigh those of the status-author, just that they did in that case. Each case should be considered on its own merits.

(I'm talking about "status-authors" and "the audience" as though they're two separate groups, but of course all of us are members of both groups at various times.)

This paternalism is unwarranted

I disagree that this is paternalism at all. As you identified earlier in your comment, what's really at issue is trading off interests of different groups. No one is saying (paternalisticly) that status-authors themselves will be better off if they're not allowed to limit replies. Instead, some people in this thread are saying that status-authors should not be allowed to prohibit replies because their interest in doing so is outweighed by the audience's interest in replying. As I've discussed at length earlier in this thread, I side with the status-authors in this case.

In the other issue you cited, the debate is similar: reasonable people agree that status-authors want to make local-only posts. However, we need to weigh that against the interests of audience members who want to follow local events without creating a second account or moving their primary account to that particular instance. And, for reasons I've expressed in that thread, I side with the audience in that situation.

My point is not to relitigate the merits of either of those issues. It's just to say that, in both cases, we're talking about trade offs between one group and another; neither issue is about paternalism; and both issues should be decided on their own merits—not by applying a general rule of "always side with the status-authors" or "always side with the audience".

[kizu]

One thing I want to note. When looking at arguments, there is a big difference between those.

The arguments of those who want an option to disable replies come from the actual cases of harassment people had experienced. And other platforms, that had this option to disable replies, that option helped tremendously and there were no substantial problems caused by this.

When looking at arguments of the opponents to the option to disable replies we see that they're all abstract theories and what-ifs, not really grounded in reality. The mute option, that those people say should be enough, already exists and clearly is not enough. The abstract thoughts about what the audience wants are just that — abstract thoughts not based on actual experience.

[koyuawsmbrtn]

If this feature is being implemented can the bot owners decide if they want to have replies to the posts the bots are making? Another thing is, that moderators should be able to disable replies, the same goes for the users to disable replies for existing posts all at once (for example posts older than x days or all posts before this feature was being introduced).

[niacat]

@kizu

Please explain how this is an anti-harassment feature.

User blocks, instance blocks, thread mutes, private posts (post visibility options in general), approving followers — those are all anti-harassment features.

What this does is prevent people from responding to misinformation. It doesn't matter if replies aren't visible to a user, that's their right. Removing the option entirely produces a different dynamic. I want anti-harassment technology to protect people's mental health. Not to protect and insulate the powerful from _other_ people seeing responses to their posts.

If the mute option already exists and isn't enough for people to browse their timelines in peace maybe it needs to be fixed?

[rysiekpl]

@ensra this has been explained multiple times in this thread. Among many others, here:

• https://github.com/tootsuite/mastodon/issues/8565#issuecomment-418209410
• https://github.com/tootsuite/mastodon/issues/8565#issuecomment-418131787 (by @kizu no less!)
• https://github.com/tootsuite/mastodon/issues/8565#issuecomment-418626575
• https://github.com/tootsuite/mastodon/issues/8565#issuecomment-418629655

If the mute option already exists and isn't enough for people to browse their timelines in peace maybe it needs to be fixed?

Clearly it does need to be "fixed" or improved upon. This feature request is exactly this kind of improvement.

[kizu]

@ensra Feel free to re-read this thread, “how this is an anti-harassment feature” was already explained there, and not once.

What this does is prevent people from responding to misinformation.

This is not true. People could still respond, just not in a form of direct replies.

Also, clearly, when there would be such feature and an indication that the replies are disabled to a toot, other people could as well understand the fact that there wouldn't be direct responses with rebuttals, and when in doubt, they could go and look for those responses themselves. And yes, author of a toot is not obliged to provide a platform for those who want to challenge their view.

If this is some harmful misinformation, then it would be much more effective to go and report such toots to mods, providing your sources.

[oct2pus]

@ensra i think an easy solution to this would be to prevent them from being boostable. It would allow the good benefits of 'no replies' (pinned posts, bot posts, vent posts, posts you just don't want to be @'d) while preventing malicious spread of misinformation (besides if you can't reply why even have it be boostable to begin with, what sort of post would want that? Why would you want your post to spread if you don't want any commentary?)

i have to agree with @kizu that we SHOULD be able to go to our moderator if such a toot is painful or bad, but I think preventative measures prior to moderator action allow us to reduce mod workloads and help main some sanity. We also have to consider bad/lazy moderators who might disagree with your assessment and/or agree with the poster, which can lead to further inter-server conflict.

[keiyakins]

What would setting this actually do? I mean, I agree in principle it's nice, but we can't straight up prevent people replying without controlling their instance. Here's what I think such a setting could do, and which I think in practice would be good enough for most purposes:

1. Your instance refuses to accept any replies. They're not shown to you, they don't show up on the original toot's page, etc. Any users on your instance who try to reply (using a third party client that doesn't understand the 'no replies' information, for instance) finds their toot is rejected entirely and not posted anywhere.
2. The toot has a flag set that requests other instances not allow replies. This isn't enforcable - in the most obvious case, old instances that haven't been updated or instances running other software might not understand what they're being asked at all. There's also malicious instances that deliberately disable that functionality. That's where the first thing comes in.

[Cassolotl]

but we can't straight up prevent people replying without controlling their instance.

That's not true.

If you try to reply to a post that has been deleted on its originating instance but the delete instruction hasn't reached your own instance, you get an error message, like "could not find post that you're trying to reply to."

So with replies disabled, it could be like that. It could behave like a deleted toot, but the toot is still there. The original post could have information attached to it that says "replies off" and the receiving instance could understand it and remove the reply button. But if the receiving instance didn't recognise that, as a last resort the originating instance could send out an error message when you try to reply, that says something like "error: the toot you're trying to respond to has replies turned off". It would send an error signal, but you wouldn't be controlling someone else's instance. (Edit: Unless you think that closing/locking your front door is controlling other people's ability to rob you, and then I don't know what to tell you. :D) The boundary would be on the originating instance.

I mean, I'm not a coder but if we can get error messages when replying to deleted toots I think we can get error messages for toots that have replies disabled.

[Cassolotl]

@oct2pus If the toot is unboostable but can still receive replies then it doesn't address this feature request at all, it just does an entirely different thing...? To clarify, are you suggesting that instead we have the option to post public but unboostable toots?

[oct2pus]

@Cassolotl i proposed that a toot that cannot be replied to also cannot be boosted, I realized now I failed to make that clear and assumed it was inferred, my mistake.

I don't have a preference if it appears on the public (federated) timeline or not actually, although considering that you would not be able to reply or boost it, it would probably not be a wise idea to put it on the public timeline.

[Cassolotl]

@oct2pus Oh I see! Excellent, thanks for clarifying. :)

[Natanji]

I am very divided on this issue. I'm part of multiple minorities, I know what it's like to be harassed, and I know how both quote-tweets and replies are used to harass on Twitter. I once posted an introduction to myself including being trans, made that my pinned tweet... and over time, the replies from harassers who left hurtful comments just kind of stacked, forcing me to eventually unpin that tweet. Reporting them did nothing (because Twitter), and since there is no common consensus in the Fediverse that remote instances will remove posts "You're not a real woman, you're a man", reporting also wouldn't do shit if this happened in the Fediverse. (This is one of the reasons why I don't have a pinned introduction toot here so far).

I believe I should be safe from this kind of harassment. And the currently available means aren't enough for it. I don't want these hurtful comments below my toots, I don't want people reading what I write to be exposed to that. Twitter has actually become kinda good at hiding hurtful toots or toots of users it detected to be posting questionable things, shadowbanning them and all that stuff. Those are anti-harassment features currently not available on Mastodon, and probably they'll never be due to its decentralized nature.

But I also see the other side of the issue. I absolutely disagree with @kizu that people can still adequately respond to misinformation when direct replies are disabled. I can then only toot at my own followers, but the people viewing the misinformation will be an entirely different set of people. I think stopping the spread of misinformation absolutely requires the ability to directly reply to this misinformation, i.e. the ability to post the corrected information pretty much at the same place so that people viewing the misinformation can see other views on the topic.

This is pretty much what we're deciding between. Both having this feature and not having it have clear benefits and risks associated with them. From an anti-harassment perspective, this feature would be amazing. (I also believe no replies should have this feature, but only top-level toots, because otherwise I can see this being abused) From the network perspective, this might invite the spread of misinformation and undisputed hate.

The reason why I still believe this feature would be good to have is because I believe the report feature can much better deal with more global issues like misinformation than local issues such as harrasment. The problem with misinformation is only really there if it spreads. If someone writes a no-reply toot with shitty stuff that people can't respond with, this will actually funnel the users into using the report feature more, because that's the most direct thing they can do against it. If someone harasses you, it's a very local, personalized thing that only a single user might experience - so the report feature will often not be used, bad actors will not be punished.

If you get 100 harassing replies you won't report every single one of them because it takes so much effort, you're down and overwhelmed already, and they can all just makes new accounts and keep harassing you if they want. But if misinformation is at the risk of spreading, then the user spreading it will have an account with quite some followers; removing the user or the toot is a much more effective means of extinguishing the misconduct here. They can also make a new account, but will have to start over with 0 followers.

So this is why I believe that within the overall ecosystem of tools for desirable conduct on Mastodon, this feature would ultimately be a good fit.

[kizu]

Thinking more about it.

If the replies are disabled, then the boosting would be disabled as well.

This would be a compromise, as there would totally be legitimate cases for having a no-replies boostable toots, but for a lot of purposes (like pinned tweets with some info, rants, sharing personal stuff, more private (in terms of who participate) discussions etc.) it would be ok?

I can also see how you could still make a shareable thread, with initial toots having disabled replies & boosts, and then ending it with a boostable & repliable toot which people could share, and which to use for the interaction. And if there would be harassment in response to this exact toot, it would be very easy to stop it by deleting it, but still keeping the original toots intact, thus disconnecting the discussions that followed from the original thread.

I still think it should be possible to make every toot, even in the threads, unrepliable, but there should be the following rules to it:

1. If the toot is a reply, and there are mentions of people in it, those people should still be able both to reply (not sure if they should be able to boost, probably not).

2. The author of the toot with disabled replies should still be able to reply, thus continuing the thread, and, as with other toot settings, the replies should still be disabled by default for this reply (but the author should be able to change those if they wish to, before sending it).

3. If the toot is a reply and all the @-mentions are deleted (and it is a reply not by the author of the original toot), then I'd say that this toot should lose the connection to the original toot, as this is something I can see being potentially used for harassment (it would be basically sharing a thread & disabling replies). This would have the same problem as no-replies itself (it would be up to a client to show or not show the connection I think?), but I think it could be done when possible.

4. I think that the disabling replies shouldn't be a binary checkbox, but should be basically almost a copy of the original privacy settings — you should be able to set the replies to public, followers-only, and no replies (or “direct”, as replies from those mentioned must be accepted). There is a problem with “followers only”, as it would be much more preferable to be “mutuals only”, but it is a separate issue of the privacy settings in Mastodon itself.

5. This is probably a separate issue, but very connected both idea-wise and implementation-wise — there should be some kind of a global “lock down” mode for an account, which an author should be able to activate, which should lock down all replies and boosts to everything.

Questions to every party: does this sounds ok?

Question to those who oppose disabling replies — do the disabling of the boosts at the same time would be ok of a compromise for you?

Question to those who are pro disabling replies — would the disabling of the boosts alongside be bad for some reason? Should we accept this compromise in order to make this feature more likely to be implemented?

It would be also nice to read what @Gargron would say about this whole issue as well, to understand if we should keep wasting our time in finding compromises, or this feature would be denied anyway in any form. And if this feature is welcome — what should the community do next in order to make it happen.

[Cassolotl]

I'm pro disabling replies, and I'd be okay with those posts being unboostable, I think.

[Natanji]

I think having no-reply toots be unboostable solves my concerns about them being used to be abused to e.g. mass-spread misinformation. The legitimate use case for no-reply toots is clearly more private in nature.

About the suggestion to have fine-grained controls over who can reply, eh, I'm very sceptical about this. Who would be able to reply to such a reply? Would it lock down reply-ability to the original user's followers, or to the followers of the person who replied? I also think this is typical tech-think, make it all very very fine-grained but from the UX side it would be huge confusing mess I think. Let's not make this any more complicated. If you want replies only from your followers, then set the toot visibility to "followers only" and allow replies.

[kizu]

I partly agree with the fine-grained stuff. This is also something that could be (if even should be) done later, as a separate issue, as it would be totally possible to start with just binary unboostable replies open/closed (with the mentioned people/initial author exceptions), and then, after some time and experience with this new mode, it would be easier to understand if the more control needed, or is it would be enough.

[keiyakins]

@Cassolotl And someone could alter their instance to post it anyway, ignoring the error message. The door analogy doesn't work because different instances have different laws of 'physics'

[Cassolotl]

@keiyakins Oh, I see what you meant in the first place then!

Well, I've seen "a bad actor could modify their instance to disrespect that" used to argue against every anti-harassment feature.

The reply to the no-replies toot would only show on the modified instance, which could be damaging, but would also be reason for instance-blocks I'm sure, so good admins would hesitate before doing it and bad admins would be providing evidence that their instance could be immediately blocked for malicious behaviour (deliberately modifying the Mastodon code to break a consent boundary).

But if up-to-date and well-intentioned instances respect the no replies setting, no-replies toots would never show replies on the originating instance even if someone had modified another instance to ignore the error message and post anyway.

[Natanji]

This. Quoting toots would also be hell easy to implement on a "rogue" instance, but people on most instances won't see it as a quoted toot and so it works against harassment. @Cassolotl is absolutely right that this is no reason to not implement this.

[trwnh]

@kizu

I think that the disabling replies shouldn't be a binary checkbox, but should be basically almost a copy of the original privacy settings — you should be able to set the replies to public, followers-only, and no replies

This is too confusing and would create a factorial explosion in complexity with the current privacy system. It opens the door to "public" posts that aren't really "public", "followers-only" posts that could potentially be replied to by non-followers if they leak, and other very weird results. It would be very difficult to do over ActivityPub without adding an entirely separate matrix of object capabilities -- that really goes beyond the scope of a simple feature addition, and it becomes a protocol issue.

---

To re-iterate (https://github.com/tootsuite/mastodon/issues/8565#issuecomment-418505761), we can do the following in the current ecosystem:

• signal a reply preference using a new field/value, which may be implemented as a Mastodon-only extension for now
• drop any incoming replies that make it through, so that they do not appear linked below a status (with all the caveats detailed in earlier comments)
• wait for object capabilities to become a fleshed-out standard like ActivityPub, so that you can arbitrarily grant (or later revoke) "the ability to reply" as opposed to treating replies as "something that you receive"

Especially with respect to the 2nd and 3rd point, currently, revoking "the ability to reply" is modeled as a "block" (which is also revoking "the ability to request delivery", incidentally). In the current paradigm, anything you can locate, you can also reference. If you know a Web resource's identifier, then you can refer to it -- and in reverse, if you can refer to something, then you can de-reference. This is how locations (URLs) are dereferenced to identifiers (URIs) by servers. And you can't prevent people from referring to things they know about; you can only ignore or throw away incoming references based on certain rules. This leads to potentially infinite rules, and an even greater infinity of interaction between rules.

Essentially, each post needs its own separate reply ID, which can only be requested cryptographically; the inReplyTo should then be pointed at that secret ID, which is only given out upon valid requests. As long as replies refer to public URIs, we can only keep adding rules for how to treat incoming replies. It's exactly like publishing a phone number or email address.

[nightpool]

@trwnh i've been trying to keep my comments to the AP ticket, but there are probably other ways to federate more complicated semantics without going full ocap (for example, requiring Accepts for replies like we currently do for Follows). Obviously this is still "adding rules for how to treat incoming replies", but it's not particularly difficult to conceive of adding in the same way.

i think we should focus here on what the simplest desired UX should be, and then worry about how to implement it later.

[trwnh]

@nightpool I think that would certainly work, but not offer any security guarantees; it's what I called above "signal a preference and then drop any invalid incoming replies", yeah. Replies still might exist on remote servers as long as they can continue to refer to posts. Then again, that's mostly an implementation detail -- any server can link any two posts, and can even forge posts in its local database if it wanted to. I still wonder if it isn't too hard to simply ask the originating server which valid replies exist... worth discussing more in-depth on the AP ticket though

[bgcarlisle]

What would it take to get this seriously considered?

[barzamin]

@bgcarlisle this is currently blocked on a standards-level snag (cf https://github.com/w3c/activitypub/issues/319); afaict, it has been seriously considered on the AP side of things, and if we reach a decision there, doing this in mastodon proper would then be an exercise in implementation. pleroma also seems to have interest in doing this; there are a lot of people interested in AP extensions for finer-grained interaction scopes.

[spaceottercode]

So what's the status and prospects of having a non-boostable no-reply no-frills option at the time of toot authorship?

[trwnh]

@spaceottercode It can be done locally by simply discarding all incoming interactions, but lacks a signaling method to let others know that interactions will be discarded, so your preference will be ignored by other servers.

[nclm]

PeerTube, PixelFed and WriteFreely now all support this feature (some details in this thread: https://mastodon.social/@dansup/101865787856824731 ). Something Mastodon can start doing is removing the reply button (and hiding any comments that might have got through the net) on posts from other platforms with disabled replies.

[Laurelai]

So now we know that its not olny possible to do this, other federated services have already done so. So that begs the question why has this been completely ignored.

[trwnh]

"Others have done so" is not really the full picture -- what matters is that everyone does it in the same standardized way. The way Pixelfed announced it is to have a commentsDisabled field that is either true or false, and it can be changed with an Update if someone decides to toggle enable/disable state after posting.

This is not the same as the way Peertube does it, which is currently with a commentsEnabled field. And WriteFreely has not yet implemented any sort of comments at all, but their dev is waiting for agreement on a standardized property. Pixelfed is currently considering switching to commentsEnabled as well.

There are also questions about how to represent a "requires approval" policy, and not just a binary enabled/disabled. So what might end up happening is to start sending out Accept/Reject in response to received activities that are marked inReplyTo something else on the receiving server.

All of this would still only be a signal and not technically enforcable outside of the authoritative server. In Pixelfed's case, incoming comments are discarded, and there's some work being done to start sending out Accept/Reject as a signal as well. But that does nothing if the comment's authoring server has no idea how to process Accept/Reject. At minimum, all that can be guaranteed is that replies are hidden on your server, that you receive no notifications for any replies that are made by ignorant remote servers, and that a signal is sent out for compatible implementations to handle.

So all of this is possible, sure, but it depends on multiple implementations agreeing on what to do, in a way that's a little better than "who did this first". With Pixelfed, we went ahead and at least implemented the logic to hide the button locally and discard incoming replies, which would hopefully encourage a wider discussion on how to standardize this over ActivityPub.

[ccoenen]

Ignorant remote servers don't really bug me that much, to be honest. One could also argue "how do we fix people sending a link via email and commenting _that_ way?" - we don't because we can't. In extreme cases those remote servers will probably get blocked, so there's an incentive for server maintainers to honor the standard.

I would love to see a single standard emerge. That said: personally, I feel "comments are allowed" is the default. This is why I think commentsDisabled: true makes more sense: If it is missing, the default is still "enabled". So the default is the simple thing and backwards compatibility is also easier. I am not going into if "comment" is the right phrasing for us, because I do not know enough about the internals of Mastodon.

[optikfluffel]

commentsEnabled, the way peertube does it, seems to be the way writefreely and pixelfed are going for. There's also an open Issue for anfora proposing the same.

[trwnh]

@optikfluffel Pixelfed switched to using commentsEnabled: false instead of commentsEnabled: true purely because that's how Peertube does it right now, but the Peertube dev has expressed that they are willing to adopt a standardized definition if a better one is developed (as inter-project talks are still underway on what is the best vocab to use here).

@ccoenen:

personally, I feel "comments are allowed" is the default. This is why I think commentsDisabled: true makes more sense: If it is missing, the default is still "enabled". So the default is the simple thing and backwards compatibility is also easier. I am not going into if "comment" is the right phrasing for us, because I do not know enough about the internals of Mastodon.

This is all internal vocabulary that is part of the ActivityPub spec and its extensions. AP defines Like even though in Mastodon it's called a "favourite", and what we call "boost" is actually Announce. Using comment/reply is irrelevant as long as it's consistent.

I do agree that the disabled flag is better because ignoring it implies the default is enabled. But again, that's still being developed. Pixelfed switched to commentsEnabled simply to match Peertube, until a better property name is agreed upon (perhaps to allow manually approving comments as well, and not just binary enable/disable).

[optikfluffel]

@trwnh All I'm saying is, there are 3 fediverse platforms that use commentsEnabled: false, and none doing it the other way around, for now.

willing to adopt a standardized definition if a better one is developed

I guess that means they'll stick to it, until w3c/activitypub#319 is resolved.

[ccoenen]

Thanks for clarifying @trwnh :-)

[thebaer]

Indeed, we'll officially support this in the next version of WriteFreely.

I agree the semantics aren't necessarily perfect (maybe rejectsReplies would be more apt) but we could bikeshed this forever. I think what matters most is consistent behavior across implementations -- and we're all already doing that today.

So I'd echo @nclm that a great next step would be for Mastodon to simply disable the reply button if commentsEnabled is set to false. Is there any interest in doing that?

[Gargron]

Speaking about consistency, "comments" makes no sense, that's Diaspora vocabulary. ActivityPub denotes replies with inReplyTo, so presumably, any property affecting that behaviour should also use reply (also, all ActivityPub properties use singular form, e.g. tag and attachment even though they usually contain multiple items)

[thebaer]

Thanks @Gargron, so replyEnabled? Or replyAccepted? Again, keeping in mind the limited scope of whether or not the authoring platform has disabled replies to a post, as currently implemented in PeerTube, Pixelfed, and WriteFreely.

Looking forward to having a name we're all happy with so implementers can start using it.

[thebaer]

Just FYI, decided to go ahead with commentsEnabled in WF since the interested projects settled on that.

[trwnh]

i like 'replyAccepted', especially if it's coupled with indicating an actual Accept/Reject flow! i'd expect values of 'auto', 'manual', or 'none'.

this might also be used to generalize/standardize the existing 'manuallyApprovesFollowers' extension that mastodon uses for locked accounts (which is extremely awkward). there could be a 'followAccepted' property in its place, with same possible values of 'auto'/'manual'/'none'. this could be applied to anything that could expect an Accept/Reject flow. seems kind of too limited to use that only for Follow activities and basically nothing else in practice.

[thebaer]

Yeah, I agree replyAccepted is probably an ideal name, and an Accept/Reject flow for replies (and maybe other interactions) would be great.

But I think for now we're just looking for a simple standard that could represent this very small, very limited bit of UX: disabling or hiding the reply button when an author chooses. That's really it -- no granular controls needed, or moderation, or cryptographic assurances that replies are rejected across the fediverse, etc.

The boolean property we've picked addresses the fact that 3 AP platforms support this option today but can't communicate that with the fediverse. Now others can at least pick up on that and do something in their own UI. So it'd be great to have support in Mastodon, as I think it'd help make the wider fediverse more intuitive and user-friendly. But if there's hesitancy because this isn't a perfect solution, that's okay -- we can at least keep building for now, and always adapt when/if Mastodon adds support.

[nightpool]

I would prefer to eventually do the OCAP like thing that we talked about
on the corresponding AP issue (which as far as i can remember, had zero
cryptography :/). I also dislike that this process is happening on
individual issue trackers and post threads instead of in actual standards
group spaces. I think i'm okay by compromising and hiding the reply button
in the mastodon interface as a sign of good faith, but i wouldn't want to
put into core something that allows mastodon users to set this property
until we also have some better assurances.

On Sun, Apr 7, 2019 at 2:21 PM Matt Baer [e-mail] wrote:

Yeah, I agree replyAccepted is probably an ideal name, and an
Accept/Reject flow for replies (and maybe other interactions) would be
great.

But I think for now we're just looking for a simple standard that could
represent this very small, very limited bit of UX: disabling or hiding the
reply button when an author chooses. That's really it -- no granular
controls needed, or moderation, or cryptographic assurances that replies
are rejected across the fediverse, etc.

The boolean property we've picked addresses the fact that 3 AP platforms
support this option today but can't communicate that with the fediverse.
Now others can at least pick up on that and do something in their own UI.
So it'd be great to have support in Mastodon, as I think it'd help make the
wider fediverse more intuitive and user-friendly. But if there's hesitancy
because this isn't a perfect solution, that's okay -- we can at least keep
building for now, and always adapt when/if Mastodon adds support.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/8565#issuecomment-480616442,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV87uskNco_fdFTYIMvtBAJBMB0Ydks5vejcQgaJpZM4WWh2i
.

[trwnh]

eh, you can't prevent replies as long as posts are accessible through a known url/uri. at a basic level you could link to a post outside of the platform entirely. you can only reject replies as invalid, either due to some crypto assurance such as a failed signature/proof check (as in ocap) or due to the authority of the receiving server (as in mandating accept/reject and being responsible for forwarding replies you receive)

really the only thing preventing assurance right now is that replies can be distributed by their authoring actor's server, instead of having to pass through the receiver's server for distribution (thus preventing a pure authority scheme from being effective). i personally think this is the simpler, more reasonable, and more ideal way to handle things (analogous to commenting in almost every prior existing system -- blogs, youtube, diaspora, facebook, basically everything except twitter), but, well, that's for the AP issue tracker i think. ocap is certainly the more decentralized of the two options.

[thebaer]

@nightpool Sure, just respecting the property would do the trick today and fix current UX issues. And, again, we can always adapt to whatever solution everyone decides on later.

As for AP-related issues like this in the future, where should implementers go to discuss, get guidance on new experiments, etc.? The w3c/activitypub repo?

[nightpool]

it's not as unsolvable as it appears. you can't link to a post if it's only
accessible through unique URLs that encode the context of the link. (i.e.
you request and then use a unique inReplyTo url from the origin server)

On Sun, Apr 7, 2019, 3:14 PM trwnh [e-mail] wrote:

eh, you can't prevent replies as long as posts are accessible through a
known url/uri. at a basic level you could link to a post outside of the
platform entirely. you can only reject replies as invalid, either due to
some crypto assurance such as a failed signature/proof check (as in ocap)
or due to the authority of the receiving server (as in mandating
accept/reject and being responsible for forwarding replies you receive)

really the only thing preventing assurance right now is that replies can
be distributed by their authoring actor's server, instead of having to pass
through the receiver's server for distribution (thus preventing a pure
authority scheme from being effective). i personally think this is the
simpler, more reasonable, and more ideal way to handle things (analogous to
commenting in almost every prior existing system -- blogs, youtube,
diaspora, facebook, basically everything except twitter), but, well, that's
for the AP issue tracker i think.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/8565#issuecomment-480620648,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV9zMEV5ZUtP7ul6YgaG7F2YuNl8Qks5vekOpgaJpZM4WWh2i
.

[nightpool]

we use w3c/activitypub for things specific to activitypub,
w3c/activitystreams for stuff specific to as2 (like an informational
property), and swicg/general for more broad discussions that aren't tied to
one technology or another.

here's the specific issue where we discussed this earlier this year:
https://github.com/w3c/activitypub/issues/319

On Sun, Apr 7, 2019, 3:20 PM Matt Baer [e-mail] wrote:

@nightpool https://github.com/nightpool Sure, just respecting the
property would do the trick today and fix current UX issues. And, again, we
can always adapt to whatever solution everyone decides on later.

As for AP-related issues like this in the future, where should
implementers go to discuss, get guidance on new experiments, etc.? The
w3c/activitypub repo?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/8565#issuecomment-480621087,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV3vnwOT2gx49U85C6rOdpJv8Jgfkks5vekTwgaJpZM4WWh2i
.

[trwnh]

i mean that ignorant/outdated/etc implementations could simply continue to do what they currently do, which is to use the 'id' property as the value of the 'inReplyTo', and nothing can really stop/change that except to stop validating such activities (by mandating either authority or proof). doing it with authority would hurt forwardability, doing it with proofs would be more complex. not unsolvable, sure, but mandating assurance is not going to be backwards-compatible with the no-assurance-required "legacy" fediverse. at least with accept/reject you can maybe signal to the replier that it won't be shown on the receiver's local instance... but that's about it.

tldr the current incarnation of the fediverse is only capable of "delisting" rather than "disabling", and maybe there'd be less confusion if we clarified it as such. it's less like "you can't do this" and more like "don't expect this to be shown to the user"

[kaniini]

just respecting the property would do the trick today and fix current UX issues

this is absolutely the wrong way of thinking about these problems. implementing bandaids instead of solving the underlying pain points will just result in a system that is trivially hacked around.

in this case, i suggest looking at the reasons why a disable replies feature is desired and find solutions to those concerns that are in an appropriate security context of an open-world federated network.

OCAP can provide some of the answers here, controls over what interactions are presented to users can solve other pain points, but, ultimately bandaids provide none of the answers.

advisory-based UX is ultimately the fediverse's equivalent of DRM.

[Laurelai]

Saying tha disabling replies is the same as DRM is a bit of a nuclear take there.

[saper]

Why? DRM history began with ideas like the https://en.wikipedia.org/wiki/Broadcast_flag - an attempt to let the sender control what can be done with a message (video stream in that case). Since it is known that advisory flag would not work, one moved into encrypting things.

[Laurelai]

Because were talking about anti harassment not copyright enforcment.

[trwnh]

in this case, i suggest looking at the reasons why a disable replies feature is desired and find solutions to those concerns that are in an appropriate security context of an open-world federated network.

OCAP can provide some of the answers here, controls over what interactions are presented to users can solve other pain points, but, ultimately bandaids provide none of the answers.

yeah, this is important to keep in mind, because there are actually two different issues being discussed here:

1) letting users/platforms prevent replies from being passed around unless validated by the originating actor (backwards-incompatible, solved by either requiring ocap proofs or requiring replies to be delivered to the author instead of the followers)

2) letting users/platforms signal that replies will be manually accepted or rejected, and may not be seen at all (coupled with locally delisting those replies for the originating actor)

it seems pixelfed and writefreely are mainly interested in 2) right now, while pleroma and mastodon are raising concerns about 1) instead. in that sense, the "ux issue" raised by @thebaer is the one where a user will reply to someone, perhaps multiple times, then be confused when the other person says they haven't seen any of their replies. in pixelfed's case, this is because comments will be locally hidden from posts and notifications. in writefreely's case, this is because replies are not supported at all, and all incoming interactions are discarded completely (which is ultimately what we want to signal here).

---

consider the related issue of locked accounts and 'manuallyApprovesFollowers' as currently implemented. this is ultimately also a signal (albeit a verbose one). there is no technical guarantee that a software implementation might send a Follow, and then the receiving user does not Accept or Reject it, leaving the Follow in an indeterminate "follow requested" state. However, any implementation may go ahead and start filling the timeline with that user's (public) posts, until a Reject is received.

imagine if, in the above scenario, 'manuallyApprovesFollowers' did not exist or was ignored, because it was "advisory security". there would be no clear signal that your Follow was received, or that it did anything, or that any side effects should be processed. it would be entirely up to each implementation's logic and heuristics to determine what should happen if a Follow is not Accepted or Rejected. this is the case today with any non-Follow (or Offer) activity.

[thebaer]

Exactly. We're trying to send a signal because we have a signalling problem. It doesn't need a more complex solution. It's possible to solve this limited-scope problem today with the flag we've suggested, while still leaving room for iteration and addressing _prevention_ (issue no. 1).

[trwnh]

per the OP of this issue:

remove the reply icon (and possible other related UI) to the toot once it is posted. It won’t prevent the person to be contacted about the toot, but will not make it a one-click affair any more

would be the use case being addressed here. it's also how pixelfed is currently handling it. a simple tooltip like "the author has indicated they are not receiving replies to this post" is enough to be clear about what is going on, similar to the current workaround of saying "i'm going to mute this conversation immediately" and then clicking "mute conversation" immediately after posting. in mastodon's terms, it'd probably be best conceived as an extension of the "mute conversation" feature which simply hides notifications about children of that post and takes no measures to prevent them at all.

[nightpool]

that's an interesting take. we currently don't federate "has muted
conversation" at all and I'm not sure we should, but there are compelling
ux reasons that it would be a good idea, and you can definitely see people
"polyfilling" it on twitter by saying they've muted conversations in top
level reply (something mastodon doesn't afford very well because of the way
thread ordering works).

I'm more concerned by the idea that write freely doesn't accept incoming
activities at all. that seems like an entirely different problem? Does
write freely just not have any support for comments or do they only allow
centralized comments?

On Mon, Apr 8, 2019, 7:20 AM trwnh [e-mail] wrote:

per the OP of this issue:

remove the reply icon (and possible other related UI) to the toot once it
is posted. It won’t prevent the person to be contacted about the toot, but
will not make it a one-click affair any more

would be the use case being addressed here. it's also how pixelfed is
currently handling it. a simple tooltip like "the author has indicated they
are not receiving replies to this post" is enough to be clear about what is
going on, similar to the current workaround of saying "i'm going to mute
this conversation immediately" and then clicking "mute conversation"
immediately after posting. in mastodon's terms, it'd probably be best
conceived as an extension of the "mute conversation" feature which simply
hides notifications about children of that post and takes no measures to
prevent them at all.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/8565#issuecomment-480791123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV2mkvajroslWJQKKWWJU8brbY65Kks5veyYXgaJpZM4WWh2i
.

[trwnh]

@nightpool writefreely is an anti-social, distraction-free blogging environment, so they don't have comments at all -- activitypub is used purely for syndication. however, i think they're working on opt-in comments in the future?

i also don't think "has muted conversation" is necessarily something that should be federated from mastodon's case, but commentsEnabled: false as currently used implies a sort of more-explicit version of that, where "muting" is intended for recipient-side filtering, and "disabling" is intended for sender-side signaling. the former can be toggled at any time in a client, the latter is defined at post time (and changed with Update).

[thebaer]

Right, we're planning on supporting AP-based comments / replies in the future, but they'll remain off by default. Having a way to communicate this option before then will ensure a nice experience when we do add support.

We also ignore Like activities because of our distraction-free mandate, so in Mastodon they just become bookmarks on blog posts. It'd be nice to support reflect that in the UI as well, but that's another topic :)

[kaniini]

Saying tha disabling replies is the same as DRM is a bit of a nuclear take there.

Because were talking about anti harassment not copyright enforcment.

And I am talking about anti-harassment too. This isn't about disabling replies, it's about how to build a system that actually provides some reasonable protections and de-incentivizes harassment. In an open world system like the fediverse, some thought must actually be put into the security model.

The comparison to DRM is appropriate: it is an artificial limitation that is, in almost all cases, trivially bypassed.

This is why I propose examining why people want to be able to disable replies (dogpiling, etc.) and look at solutions to actually solve those problems. The problem here isn't whether replies can be disabled or not (advisory data is required in any case for that, even with OCAP), but that people working in this space have a tendency to tick the box and call it done and say "haha! we have solved harrassment in our product!" when they haven't done so at all.

Bluntly, I don't think anyone who is proposing that we slap commentsEnabled on activities has ever had to deal with harassment or stalking. I want to work on real solutions, not halfassed features that will be primarily used for marketing since nobody can actually depend on them doing anything useful.

[trwnh]

Bluntly, I don't think anyone who is proposing that we slap commentsEnabled on activities has ever had to deal with harassment or stalking.

this is an unfair characterization as stated. i would agree if the claim was "anyone who is proposing this will solve anti-harassment [...] has never had to deal with it", but that's not what's being claimed. commentsEnabled: false is not at all related to harassment, and by itself would be insufficient for a true "disable replies" feature aimed at curbing harassment -- that would require fundamental changes to the sharing model of activitypub re: how replies are distributed.

but at the same time, the mere fact that replies are possible is no reason to be forced to display those replies on your own posts. that's why i'm more in favor of framing this in terms of "delisting" or "hiding" rather than "disabling", and that's why i'm making the comparison as an extension of "mute conversation". if someone is querying my server for replies to a post, the server is not required to respond with every single reply. it's not required to respond at all, in fact.

you can address a Note.inReplyTo as to:followers+mentioned, cc:public or whatever, in the same way you can email someone a link to an article/post/etc. you can publish html pages with that content if you wish. but that doesn't mean i have to include your response in my own html pages. it's fundamentally not about preventing harassment, but about preventing linkbacks. it doesn't even have to be harassing content, it could just be something i don't want below my posts. or perhaps i don't want anything below my posts at all. you're still free to discuss my posts on your own platform. at least, this is how pixelfed/writefreely are treating it, as part of the publishing aspect and not the networking aspect. i understand this is de-emphasized in mastodon/pleroma, even if they are technically "microblogs"; no one really thinks of them as blogs because the focus is on the interactions and not the original content.

if we were purely talking about preventative measures then we could also argue that there's no reason to implement a mute function, since that doesn't prevent harassers from replying. or we could say that we're not implementing blocks because they're an artificial limitation that can be trivially bypassed. but these would be disingenuous arguments because they're still better than nothing. you can apply whatever digital restrictions you wish on top of interactions, whether they be social, authoritative, or cryptographic.

tldr: this can be likened to "approved comments" on a centralized blog.

[kaniini]

I understand that it's about signaling, and as I have stated multiple times, the signalling is important for the UX side of it. that's not what my scepticism is about.

my scepticism is about the fact that many people in this space, building software have never had to deal with abuse or harassment. i have no reason to believe that we will not wind up in a situation where work on anti-harassment issues will take a back seat because the signal exists (it's a "solved" problem after all!). thusly, i'm not in favour of having a signal alone.

[Laurelai]

Kaniini , people want to be able to disable replies for a number of reasons. One of which is as an anti-harassment tool. The reason there are harasssers in the first place is because society is terrible in some ways. Mastodon cannot fix society. But it can disable replies.

I get wanting to fix the root issue and i sure would love to live in a better society but i think its beyond the scope of mastodon or any fedverse software. All we can do is mitigate the harm shitty people can do.

[kaniini]

but that's my point, this does not disable replies. it does not do anything.

[kaniini]

i think i should explain why a binary option for whether replies are accepted is not an effective solution, as it is really only obvious to people who have an understanding of how activitypub itself works underneath.

it is important to know that, at present, when you reply to a post in activitypub, your instance sends that reply to your followers collection and, typically, as:Public. the underlying object (usually a Note) has inReplyTo set on it, which designates that it is a reply.

what does this mean? without a way of proving that the reply is an authorized reply or not, fediverse instances will accept the reply object.

this means that defeating this feature requires deleting a couple of lines of code, or simply not upgrading to newer software.

thusly, from the typical use case of disabling replies (attempting to stop discourse about content) this does not actually disable replies.

yes, a signal is needed (but it musn't be binary, we could look at Zot for inspiration here), but also we need a way of verifying whether a reply is authorized or not. that means we need proof objects, which means we need to shift the AP security model to an OCAP-based model.

[kaniini]

at any rate, if we look at w3c/activitypub#319 for inspiration, then we could have something more similar to this:

{
   "capabilities": {
      "reply": {"@id": "https://www.w3.org/ns/activitystreams#Public", "expires": "2019-09-15T15:53:00"}
   }
}

which means that replies are accepted from the public until 2019-09-15.

this also segways nicely into implementing OCAP model, because the capability @id could be an authorization endpoint, where a proof object could be returned. this could be represented in the UX as replies being conditionally accepted somehow.

this way could also express that replies are only accepted from direct followers:

{
    "capabilities": {"reply": "https://pleroma.site/users/kaniini/followers"}}
}

i talked with @dansup about this in IRC and he seems to like this better since it's more expressive, and puts us on the path to retrofitting a proper security model in an incremental way. would this be okay for peertube and writefreely?

i wrote about this scheme (as an extension of what we discussed on w3c/activitypub#319) a while back on my blog: https://blog.dereferenced.org/what-would-activitypub-look-like-with-capability-based-security-anyway

if we go this way, it puts us on the path of moving to a security model that is similar to Zot. i consider that a significant upgrade.

[Vertux]

I'd be curious to hear from the thumbs-down people why they feel this is a bad idea!

I did no "thumbs down", but I have an idea why they have done it. Isn't Fediverse about communication ? I think anyone who comment on a topic, normally wants feedback, otherwise he would not had written comment at all. If someone only wants positive feedback and cannot deal with opposite opinions, then I have to say, that's not the way communication works e.g. you can not blame other people and then hide yourself in a rabbit hole. It is simillar to the so called "communication bubble" we are often talk abot regarding e.g. facebook. Well, I can see the good sides of such a feature, but you should think twice about it, if you are going in the right direction.
To get to the point, if you don't want comments, write a blog and turn off the comment function.

[Laurelai]

Vertux you dont have a right to other peoples attention. I dont know why your parents didnt teach you this, but its the truth. People have a right to not be harassed.

[unbye]

Harassment prevention is a bit similar with spam prevention. Any added level of protection and any extra action harassers need to do in order to harass reduces the amount of harassment or makes it cost more time (which is even more effective as an anti-harassment).

Introducing replyAccepted: false should lead to the following (in Mastodon context): if there is a toot with this flag, clients must not display the reply button and must not display the replies if there are such.

This could already reduce the effect of any potential harassment, as anyone using the clients supporting this wouldn't see any harmful replies that there could be. And one of the main targets of harassers is often to get attention — both of the target and their friends (and this is why auto-muting, or a twitter-like blocking are bad — harassing comments should be removed for everyone).

Of course, with a simple flag, there would be a way for harassers to workaround this: they could still have at least a way to _post_ comments, but as they won't be _seen_ by anyone (or, at least, by the targets and their friends), the effect of those would be minimal.

---

The replyAccepted flag I like, as it could be always progressively improved in the future: false value would always be interpreted correctly, and any additions (like allowing only mutuals to reply etc.) would work for the newer clients exactly because of the reasons above: it would be enough to filter the replies on the side of those who want to filter them, already making the feature viable.

[kaniini]

@unbye what do you think about presenting this as a set of object capabilities instead of a flag? it allows for progressive upgrade to a better security model in the future. see my example a few comments up.

[trwnh]

if we're changing the vocabulary then @kaniini's proposal is better. i'm glad that the conversation is actually moving forward to concrete proposals on how to do this now. i also agree that a binary signal is useless, and, speaking for pixelfed at least, we'd be happy to adopt something better -- to reiterate, the activitypub side of this signal was adopted purely because that's how peertube already did it, and not because it was the best option; the disabling logic happens locally for now.

one thing i'd like to ask about more specifically, though: while a 'capabilities' field can express who is allowed to reply, as currently formulated it lacks a way to express how the reply will be handled. there should be a way to describe the policy as well -- whether the reply will be automatically from the defined audience, or if it must manually be approved first. my earlier proposal for values of "all", "auto" or "none" was based on this use-case of allowing users to delist certain comments without necessarily restricting who can actually leave a comment. so it would be nice to see a property definition that can take accept/reject semantics into account as well. the only other thing would be to actually specify that implementations should be aware that a Reject can be sent even after a valid reply is made. maybe even an Undo Accept to indicate temporary delisting instead of outright rejection, which would allow semantics for an "unapproved comments" feature.

[thebaer]

@kaniini I'm all for using the capabilities format in WriteFreely as well. I was hoping for something along those lines, since we also handle interactions like Likes in non-standard ways.

So what can I do to keep this moving forward on our end? Is there anything we can implement today to start experimenting with this? Should we move this discussion to w3c/activitypub#319?

[Vertux]

@Laurelai

Vertux you dont have a right to other peoples attention. I dont know why your parents didnt teach you this, but its the truth.

It seems you did not fully understand my comment. If someone makes his opinion public, you have to be able to deal with the response of other people. It is the same if you directly talking with other people. Communication is never a one way streeet otherwise it makes no sense. Of course there has to be an opportunity to handle offensive or abusive comments - thats not what I am talking about. You have to understand that no one forces you to make your opinion public

People have a right to not be harassed.

The best solution for this issue is to block/mute/ignore those offensive people - Mastodon already offers this option.

I see the danger, that this new feature could lead into personal cleaned up threads, which means everyone can arbitrarily delete/block any uncomfortable question or comment - and I am explecitly not talking about harassment and insults here.
This feature has it's obvious benefits, but you should also be beware of the great potential for abuse, in the form of personal censorship.
I think it is important to pause for a moment and think through and weigh all aspects again.

If you implement this feature, you should make sure that it is transparent for all readers. Deleted comments should be replaced by an explanatory note e.g. comment from user "idiot" has been deleted, reason: insult

[Serkan-devel]

I dont know why your parents didnt teach you this, but its the truth

Interesting that they already go for ad-hominem attacks, then state

People have a right to not be harassed.

[Laurelai]

Oh i understood your comment, you are just wrong.

[Serkan-devel]

Any reason why Vertux's comment is wrong?

[Vertux]

@Laurelai
I am open for critic, but you have to convince me with solid arguments - to just say "you are wrong" , is by far not enough and not a basis for a discussion.

[ccoenen]

Can this stay on topic and not derail this into namecalling? At this point I do not care who was right, I would love if some member of this team could fold up these comments (including this one from me, which, sadly, also does not add to the issue at hand).

[joenepraat]

Please @Gargron (or anyone else) code this! I have a case.

I have a harasser who tries to insert his bizarre opinion (conspiracy) as a reply into a post of me. When he is blocked or silenced he just opens another account, continuing his harassment. So disabling further comments will at least stop that.

Thank you in advance.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ccoenen]

gives stalebot a stern look

[ccoenen]

ah, that's better

[bgcarlisle]

I am very much in favour of a feature like this

Even if it won't be respected by other servers and replies are visible there

Just having an option where my own instance trashes incoming replies and I never see them would be an improvement

[Cassolotl]

Twitter now functionally has this feature only better:

This feature request is still the most 👍 'ed open issue, which means it has been for almost two years now.

[nclm]

Haha I logged-in to Github just now precisely to post the exact same screenshot here :) Yes that’s a nice implementation they did there! Hopefully we can have something similar on Mastodon.

[garbados]

Hello. I think this feature is in high demand, and that incremental implementations can provide users with some peace-of-mind while an appropriate enhancement makes its way into ActivityPub.

As an example of an incremental approach: a user that makes a no-replies post should not see replies to that post, whether or not those replies exist. Compliant servers can indicate to the user that this post does not accept replies, and though non-compliant servers may send them they will still never reach the original poster.

[Gargron]

Ignoring replies at the origin server is easy, making the UI/API prevent replies on compliant servers is also easy, what's hard is preventing replies from non-compliant servers from showing up on 3rd party servers that see the conversation (also backwards-compatibility, since the majority of the fediverse would still send replies to no-reply posts, you'd have a situation where everyone can see replies to a post except the original author which may be a worse situation than now).

In my understanding the no-reply feature only becomes possible if the task of reply distribution is delegated to the origin of a thread, because then that origin can choose to not-distribute the reply. That's a bit of a different model than the one we have where every reply is a stand-alone post that the author distributes to all of their followers on their own, and more like the facebook/diaspora model with first-class "posts" and second-class "comments".

I've been working on something that touches on this... (#14666) With posts to a "circle" (a secret subset of one's followers), the intended audience is only ever known to the origin of the thread, so anyone replying does not know who is supposed to receive the reply, so instead of doing the distribution, the replier delegates that responsibility to the origin of the thread. So that's almost what we're looking for, I think, except that it wouldn't work for public posts: If a reply is available publicly, then how do you prevent someone coming across it from processing it as a reply to what it claims to be a reply to? Indeed it almost seems like you'd need some kinda of ocap that you need to query when processing any replies you come across to confirm that it can be attached to your internal model of that thread.

[Gargron]

Anyway, my point is, this feature is a lot easier to make in a closed system like Twitter, but I think we're moving towards being able to do it.

[Cassolotl]

Is it the kind of feature that would work better across the fediverse if it was added to ActivityPub rather than just Mastodon? Like, making "replies not possible" a thing across all softwares that use ActivityPub?

Edit: Went looking, found the issue on the ActivityPub issue list, and then found that it has already been linked from this issue!

[Gargron]

That's essentially what we have to do to add it to Mastodon, yes.

[Cassolotl]

I just wanted to mention, for anyone subscribed to this feature request, that @emceeaich's new feature request Enable Twitter-style Reply Controls on a Per-Toot Basis #14762 is pretty good and worth adding your 👍 to.

[emceeaich]

Is it the kind of feature that would work better across the fediverse if it was added to ActivityPub rather than just Mastodon? Like, making "replies not possible" a thing across all softwares that use ActivityPub?

Edit: Went looking, found the issue on the ActivityPub issue list, and then found that it has already been linked from this issue!

Ah, I'll update my issue appropriately.