ActivityPub Plugin

[angus (Angus McLeod)]

@mcdanlj

Well, a mastodon user will see it in the context of a timeline, and timelines are generally limited. On mastodon, by default, a total timeline doesn’t exceed 400 posts. If you are looking at the original, you are looking in Discourse anyway. So while it’s true in theory I don’t see it causing actual confusion in practice. You have to already be a follower to see the content; following a link to the original takes you into Discourse where the confusion is resolved.

Like with the category change I think it really depends on the scenario. Consider for example

1. Post 1 created in Category 1 by User 1 (Actor 1)
2. Post 1 author changed by User 3 (an admin) to User 2 (Actor 2) 2 minutes later
3. Category 1 is followed by 400 Actors across 20 domains and 5 different software platforms, each with slightly different implementation of timelines and content discovery.
4. Within 2 minutes of Post 1 being created there are 2 Notes with identical content and different Actors POST’ed to those 400 Followers.

I think that’s likely to cause confusion for a decent subset of followers, not to mention the fact that User 2 may not even realise that their name is now attached with this duplicate content they didn’t write across 20 different domains. They may be okay with admins doing that on a single instance, it’s somewhat implicitly consented to in posting on that instance, however I think we should be very cautious about extending that implicit consent across the entire fediverse, especially in the imperfect circumstances of duplicating the content. Changing post owners is a powerful administrative function, specific to Discourse, and implicitly tied to the “social contract” of a single instance.

@mcdanlj

These are ingrained in normal Discourse use, as I see it:

• Making a post a wiki is saying that you accept others’ edits appearing in normal use under your own name
• Even if it’s not a wiki, sufficiently-privileged users can edit your post in Discourse, depending on site configuration

I think the case for wikis is stronger, however I would again observe what you’ve already alluded to. Wikis are a concept ingrained in normal Discourse. Associating the edits of anyone (not just staff) with the original author is a Discourse concept, without an analogue in ActivityPub. We should be cautious about extending that concept using the standard methods of ActivityPub across the entire fediverse. Those Update activities are going to be treated like any other Update activity across many different instances and software platforms, decontextualised from their original wiki context. Moreover, as you’ve also alluded too, there’s already a potential issue in this vein with the ability of staff and highly trusted users to edit the posts of others. I think that more limited question needs more consideration before we get to the question of wikis.

I’m not trying to set up a binary choice between Discourse and ActivityPub for these features. What I’m saying is that we shouldn’t just attempt to map sensitive Discourse functionality onto the Fediverse without cautiously thinking through the consequences. The default should be that these more sensitive features are disabled on ActivityPub posts until we have a bit more confidence that we’re not going to end up harming or surprising a decent subset of users or use cases.

Personally, I don’t feel we’re there yet with either, albeit my gut is that the wiki case has more potential at this stage, even if I don’t quite see a good solution yet.