Evan Prodromou
So, I'm a strong yes.
Every ActivityPub post has a `replies` collection that contains all the replies to the post. The definitive version lives on the original poster's server.
The OP should be able to either approve replies before they're added to this collection, or remove them from the collection if they're added automatically.
Evan Prodromou
The UI for ActivityPub apps should use this `replies` collection when showing the replies to a post. (Many of them currently just search for replies locally.)
Evan Prodromou
If someone replies to a post, and the reply isn't added to the `replies` collection, it's still visible in the replier's feeds, to their followers, etc. It just doesn't appear in the UI for the original post.
Evan Prodromou
I think this strikes a fair balance between freedom of speech and freedom of reach. Anyone has a right to reply to any post, but they don't have a right to a spot on that post's replies page.
Evan Prodromou
There was a lot of concern in the thread on this poll about the moral hazard here. People could post misinformation without being challenged directly in the thread. That's a problem, but it's one that moderators can deal with. And it works both ways; someone posting a lot of baloney doesn't have a right to a spot in my replies.
Evan Prodromou
Yes, the `replies` property is a standard property.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies
Jeremy Kahn
Federating the _list_ of replies from the poster's instance isn't currently done, is it?
Doing that would address (maybe?) one of the (least toxic) causes of the reply-guy phenomenon — that small instances often don't have a complete cache of all the replies to a post on another instance
Evan Prodromou
@js there's work going on in a FEP about the conversation tree. Long story short, the OP can manage the conversation tree that's rooted in their original post.
John Spurlock
@evan completely agree, only thing that gets tricky is how to deal with a _grandchild_ reply that you want to remove without removing that _child_ and the other grandchildren.
let's say B replies to A, and C replies to B (let's say all separate servers) - the only way for A to remove a C is to remove B, being the only replies collection it controls.
only solution I see is materializing the entire tree in A's replies collection (using AP's rich object model) which most implementations don't do
Evan Prodromou
@trochee what? Couldn't you figure that out yourself?
Jeremy Kahn
And (2) an ability to remove entries from the `replies` property, combined with (1), would approach what kissane was suggesting?
Evan Prodromou
@js no, not that one.
John Spurlock
@evan this one? https://codeberg.org/fediverse/fep/src/branch/main/fep/5624/fep-5624.md
Evan Prodromou
@wjmaggos I think that `Like`/`Dislike` counts are great, but ultimately OP should get to hide replies.
william.maggos
a better compromise imo would be to let people rank all replies ala lemmy/kbin. all replies on fedi should be treated this way, not boostable or able to be favorited. it would give us a version of X's Community Notes and much more. basically merge Mastodon and those projects etc. hashtags instead of communities/magazines.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.