Follow

Disabled comments on pixelfed are now represented by a custom ActivityPub extension on the Note objects.

I look forward to working with other developers to get this supported in other projects.

cc @mxb @BaptisteGelez @yabirgb @matt @kaniini

@dansup Interesting, what does this custom extension look like?

@dansup Yess awesome! We'll definitely support this in #WriteFreely, etc.

I just had a look at what #PeerTube does, as @tom79 mentioned, and it looks like they use the inverse, commentsEnabled 🙂

If we can all agree on the property name, I'll get this into WF. (My 2¢: I'm a fan of `enabled`, since it's already in use, and the off-by-default assumption sets a good standard for new types in the future, e.g. downvotesEnabled, paymentsEnabled, widgetEnabled)

@mxb @BaptisteGelez @yabirgb @kaniini

@kaniini I think it's pretty crucial for that. With this information, platforms with reply functionality can accurately show whether or not the poster will see comments, can prevent replies, etc.

@BaptisteGelez @dansup @tom79 @yabirgb @mxb

@matt @mxb @yabirgb @tom79 @dansup @BaptisteGelez

sure. my main concern is that we wind up I'm an enforcement regime that is trivially cheated by simply not implementing the feature. in other words, "advisory security"
@succfemboi @kaniini @matt @BaptisteGelez@baptiste.gelez.xyz @dansup @mxb @tom79 @yabirgb no, it is stated in the op post. The "custom ap extension" is just a new property called commentsDisabled on the object

@kaniini Right, this is a usability feature more than a security one.

@BaptisteGelez @dansup @yabirgb @mxb

@kaniini
Insisting on cryptographic assurance for all privacy features leads to vaporware. The fedi knows how to enforce implied social contracts. Using featureEnabled rather than featureDisabled presents the material limitations more semantically as well as avoiding negative flags.
@BaptisteGelez @dansup @tom79 @yabirgb @mxb @matt

@kaniini
I was thinking of SecuShare.

"Unilateral" would be better here. There's only one way to assert a behavior on servers you federate worth, and (judging from comments on PeerTube issues) people would go there to support this one. Even without defederating, enough servers honoring the tag would make hash of comment threads.

@BaptisteGelez @dansup @tom79 @yabirgb @mxb @matt

@yaaps @matt @mxb @yabirgb @tom79 @dansup @BaptisteGelez

I'm admittedly not up to date on what lynX has been up to, but the various proposals for integrating OCAP aren't a unilateral thing. proof objects could be accepted from third parties if desired.

@kaniini
I was going by Kol. Panic, they were just beginning to write Psyc 2.0, and lynX still believed in federation when I was involved last.

I would understand being concerned about implementing this if effective social conventions would impede a secure implementation. I just see mitigation and a useful precedent while waiting on OCap.
@BaptisteGelez @dansup @tom79 @yabirgb @mxb @matt

@yaaps @matt @mxb @yabirgb @tom79 @dansup @BaptisteGelez

to be absolutely clear, Pleroma does not implement trust and safety features that don't actually work
@yaaps @matt @mxb @yabirgb @tom79 @dansup @BaptisteGelez

yeah, meanwhile we will work on actual trust and safety features that actually work. asking software to voluntarily turn off the reply button is not a real solution.

@kaniini Oh really? So why did pleroma add BBS support before 2FA or an audit log?

Talk is cheap.

@dansup

I understand that you're mad but coordination of trust and safety features is something that needs to be handled carefully.

there are many variables that need to be thoughtfully considered, especially involving commenting policy.

hope you understand.

@kaniini I've been trying to discuss this with you on IRC in several channels over the past few days.

I'm not mad, this solution is better than nothing.

@dansup

I'm sorry that I haven't been active on IRC lately. will try to catch up with you soon.

if you see what I wrote on the litepub proposal, I do see value in having it as an advisory feature as long as this fits into implementing something real like OCAP.

my concern is that people will check the box and call this done and then real trust/safety work is set aside.
@dansup @kaniini 2FA is basically done we have a ton of big pieces in progress and people have not had free time to finish code reviews. I've also discussed audit logs with @lain which shouldn't be hard to do at all.

@feld @kaniini @lain That is great to hear.

I know kaniini cares a lot about safety and trust features (they invented MRF after all) but sometimes we disagree on stuff and I shouldn't have brought pleroma into this.

It's in everyones best interest to get along and work together on solving tough issues like this.

@dansup “2FA” “actual trust and safety features that actually work” - pick one

@yaaps @BaptisteGelez @dansup @matt @mxb @tom79 @yabirgb

to be clear, I have quite a few reasons why I feel the proposal is flawed.

- implementations can just send messages with `inReplyTo` set anyway

- while replies being accepted or not is useful to declare, different implementations may have different policies on how and when a reply may be accepted (time limits, scope limits, disallowing replies involving people the original author blocked, etc.)

@deutrino
@debugninja is the genius behind this instance. I just use it because I like it.

@debugninja I used trillian for years with a friend and the emoji became embedded so deep in our house language that some got backported to become actual spoken words and we still use the codes for others in incompatible messengers. Cool to see one in the wild, haha
@yaaps

@kaniini @yaaps @BaptisteGelez @dansup @matt @mxb @tom79 @yabirgb even if replies were blocked someone can still link the post (which may get displayed as embedded media) and discuss it.
I do think it would be interesting to have an option where the poster doesn't get notified of any replies and the original post shows no replies, but replies can be seen/viewed on the general timeline, generating only direct-link threads so it's equivalent to a user essentially just linking/embedding the post in the first place. (As long as it's not advised as a "privacy/security" feature but a "convenience" feature)
Although the whole 'thread splitting' thing would be unenforceable, so it'd probably have to be an opt-in
@yaaps @matt @mxb @yabirgb @tom79 @dansup @BaptisteGelez

it impedes real security because people will just check the box and move on to the next thing.

trust & safety is important and there are already ways to bring this into AP. Zot 6 for example is a good source of inspiration on how it could be done.

@matt @dansup @tom79 @mxb @BaptisteGelez @yabirgb @kaniini I have no preference, so choose the one that suits you best and I'll update PeerTube :)

@dansup Great, we'll officially have this in the next version of #WriteFreely! (writefreely.org/pull/89)

So how can we move support forward on Pleroma and Mastodon? Seems like the next step would be to at least respect this property in the UI by e.g. disabling the "reply" button.

@Chocobozzz @mxb @BaptisteGelez @yabirgb @kaniini

@matt @dansup @Chocobozzz @mxb @BaptisteGelez @yabirgb @kaniini

Here is the corresponding issue for Mastodon: github.com/tootsuite/mastodon/

Though it may be separated into two: respecting it when it is used on posts from other platforms (i.e. removing the button), and adding the feature to Mastodon itself (i.e. adding all the interface to author toots with replies disabled and sending the right AP thing).

@dansup Nice! Thanks for getting this all moving today -- hopefully it'll help other platforms get on board with it too.

@Chocobozzz @mxb @BaptisteGelez @yabirgb

@dansup @Chocobozzz @matt @tom79 @mxb @BaptisteGelez @yabirgb @kaniini throwing another wrench into the works: `commentsEnabled` is not enough to describe cases where comments are manually approved. i think that such a signalling property should actually be something more like `commentPolicy` with values `all`, `approved`, `none` maybe? i'm not sure what the best vocab is for this.

@trwnh I think the scope of this property, as it's implemented today, is limited to describing whether or not the authoring platform does anything with replies, since ActivityPub doesn't provide another mechanism to communicate this.

I'd personally imagine a more granular policy might be added on top of this, or eventually supersede it. But it seems people are thinking about these other controls (e.g. github.com/w3c/activitypub/iss).

@dansup @Chocobozzz @tom79 @mxb @BaptisteGelez @yabirgb @kaniini

@matt @trwnh @dansup @Chocobozzz @tom79 @mxb @BaptisteGelez @yabirgb
For "commentsEnabled", you can treat any value other than false as true until there's more detailed agreement.

For future xEnabled properties, nil and false will usually be treated as false and all other values as true.

This convention will ease transition into future editions of any extension of this type.

@yaaps @matt @dansup @Chocobozzz @tom79 @mxb @BaptisteGelez @yabirgb xEnabled implies that the default is disabled, since unknown properties should be ignored.

a more generic xPolicy makes no assumptions about default state. consider the already-existing `manuallyApprovesFollowers` as prior art, which implies that an Accept(Follow) will not be automatically sent back. but i'm not sure if `manuallyApprovesReplies` is the best way forward

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!