ActivityPub Plugin

[David_Ghost]

same here. I cant change the owner of a thread. Even though the category is NOT federated.

[angus (Angus McLeod)]

@Mte90

I see in the log tons of those errors.

Those are warnings, not errors. They don’t necessarily mean anything is wrong, they’re there to give you more information about what’s going on. There could be a number of reasons why content from the Fediverse is not processed, many of which are to do with the person sending the content. If you don’t want them showing up in your logs turn off verbose logging for the ActivityPub plugin (activity pub verbose logging)

@Mte90

At same time I can’t change the owner of a thread and online seems that the reason is this plugin.

Is the topic in an ActivityPub category or does it have an ActivityPub tag?

@David_Ghost

I cant change the owner of a thread. Even though the category is NOT federated.

Was the topic created in an ActivityPub category or with an ActivityPub tag?

Please note that changing the owner of a topics is intentionally disabled for ActivityPub topics. As to why this is the case, please see above:

ActivityPub Plugin

Like with the category change I think it really depends on the scenario. Consider for example Post 1 created in Category 1 by User 1 (Actor 1) Post 1 author changed by User 3 (an admin) to User 2 (Actor 2) 2 minutes later 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. Within 2 minutes of Post 1 being created there are 2 Notes with identical content and different Actors P…

[Mte90 (Daniele Scasciafratte)]

It is a category with Activitypub, but we are talking about the owner of the thread that it isn’t involved with the activitypub as it is a different account.

I think that there should be an option to allow to change the owner anyway otherwise doesn’t make sense that Discourse has the modal to change the owner.
Also to change it without send any updates to activitypub it is perfect for us.

[angus (Angus McLeod)]

@Mte90

I think that there should be an option to allow to change the owner anyway otherwise doesn’t make sense that Discourse has the modal to change the owner.
Also to change it without send any updates to activitypub it is perfect for us.

I understand that folks want the ability to change post ownership. The issue to address in this respect is the one I outlined above, specifically this:

@angus

Changing post owners is a powerful administrative function, specific to Discourse, and implicitly tied to the “social contract” of a single instance.

The content appearing on your Discourse is from a service on which you are not an Administrator and which, but for ActivityPub, you would have no control over whatsoever. Simply extending the ability to change the author of that content without due consideration of that fact would not be prudent.

As for content authored by users from your Discourse in a topic that is published via ActivityPub, consider what should happen if any updates are made to the content once you’ve changed the post author. Do we:

1. stop publishing ActivityPub updates; or
2. publish them by the “old” Actor (user); or
3. publish them by the “new” Actor (user).

Publishing Update activities for an existing Object with a new Actor (i.e. 3) will work with Discourse (as I attempted to give affordance for this question), but it won’t work with other ActivityPub services. Indeed I have already pushed on this point, for this reason, in the ActivityPub ecosystem. See here:

Different activity and object "actors"

And I have an outstanding PR to Mastodon to make 3 possible

Allow status updates from other actors via ActivityPub

To give one example of just one of the problems here, consider the case in which you are publishing ActivityPub content with your account (and your name and picture) attached to it. One of your “competitors” follows your content. On their server they then change the ownership of all of the posts with your content to be posts by them (with their name and their picture) instead of posts by you. That may, somewhat understandably rub you the wrong way. Yes, of course this is possible with custom code anyway, but the question is whether you want to build that into the default affordances of the plugin.

Thinking about this overnight, one approach that might ameliorate this somewhat is if we added the publishing Actor to the ActivityPub status display:

I’m open to other ideas along those lines.

@Mte90

doesn’t make sense that Discourse has the modal to change the owner.

True, I think I’ll just remove the modal entirely on ActivityPub topics until we resolve the underlying question here.

[Mte90 (Daniele Scasciafratte)]

I understand the issue, in our case we use Activitypub with an account for every category and post that update.
So who is the owner of the thread doesn’t care so much for us on Activitypub for the various cases, for this reason I say that we should be able to do it anyway.

[angus (Angus McLeod)]

ActivityPub is not just about how you use your forum, it’s about how your forum interacts with the rest of the fediverse. Moreover, to build something into the plugin we have to take into account other use cases too.

I don’t want to give the impression that allowing change of post owner is not an issue being actively considered, or that won’t be allowed in a future update. I’m interested any ideas people have to resolve the underlying issues here, some of which I’ve laid out above

ActivityPub Plugin

I understand that folks want the ability to change post ownership. The issue to address in this respect is the one I outlined above, specifically this: The content appearing on your Discourse is from a service on which you are not an Administrator and which, but for ActivityPub, you would have no control over whatsoever. Simply extending the ability to change the author of that content without due consideration of that fact would not be prudent. As for content authored by users from your Dis…

[mcdanlj]

@angus

To give one example of just one of the problems here, consider the case in which you are publishing ActivityPub content with your account (and your name and picture) attached to it. One of your “competitors” follows your content. On their server they then change the ownership of all of the posts with your content to be posts by them (with their name and their picture) instead of posts by you.

Addressing this example, it would be reasonable to forbid changing the ownership of posts which have been federated in, while allowing admins to change the ownership of posts authored within that Discourse instance, regardless of whether they are federated.

An admin can impersonate a user. Therefore an admin is able, within the platform with its existing affordances, to author content masquerading as any user on the platform. I hope that admins do not abuse this power; I don’t. However, that power is similar in impact to the ability to change ownership of a post, federated or not. In general, “an admin can do something nefarious” is already true in myriad ways.

I agree (at least inasmuch as I understand ) that changing the ownership of a post that was made by federation (therefore, not a topic post?) does not make much sense. Unlike changing ownership of posts made on site, I don’t recall seeing a use case articulated.

@angus

added the publishing Actor to the ActivityPub status display:

I like this not just from the standpoint of robustness against this kind of attack, but for making federation more visible, making it easier for a site visitor to find actors to follow. What would this look like for a case where there is a category actor (and, maybe someday, a site actor?) and a person actor? Would you have a list?

• Published by [@category@site](link)
• Published by [@person@site)(link)

[angus (Angus McLeod)]

Thanks for your helpful analysis.

@mcdanlj

Addressing this example, it would be reasonable to forbid changing the ownership of posts which have been federated in

Agreed.

@mcdanlj

An admin can impersonate a user. Therefore an admin is able, within the platform with its existing affordances, to author content masquerading as any user on the platform. I hope that admins do not abuse this power; I don’t. However, that power is similar in impact to the ability to change ownership of a post, federated or not. In general, “an admin can do something nefarious” is already true in myriad ways.

This analysis is only holds for non-federated posts. The question is not whether changing a post owner makes sense for Discourse itself. The question is what effects the change of ownership has on federated content. If you change the ownership of a local post that has been federated you have to deal with this question:

@angus

what should happen if any updates are made to the content once you’ve changed the post author. Do we:

1. stop publishing ActivityPub updates, just for that post; or
2. publish them by the “old” Actor (user); or
3. publish them by the “new” Actor (user).

I would start by noting that both 1 and 2 have some substantial issues, which I can elaborate on if need be. The answer may be the one the plugin already, supports, namely “3”, however if we go down that path this will happen (assuming my current PR to mastodon is not merged):

1. Topic is federated.
2. Posts from topic appear on Mastodon.
3. Site admin changes post owner.
4. New post owner makes various edits to post.
5. Edits do not make it to Mastodon (or any other ActivityPub platform for that matter)

And following from that:

6. Someone will come here and say “my edits aren’t being federated”. The reason for which will not be immediately obvious because as far as Discourse is concerned, they are being federated.

The key point here is that if we took this approach we’d be the first platform in the fediverse (that I’m aware of) to do it. Being the only node in an interconnected system of nodes to do something is not an obviously desirable thing to do. We may prompt change in that respect, but we’d have to be conscious that is what we’d be attempting.

That said, I’ve already implemented 3, and I suspect that will be the eventual answer which will allow me to remove this restriction. I’m still holding out some hope that someone might be able to come up with a slightly more nuanced approach, or something I haven’t thought of yet.

@mcdanlj

What would this look like for a case where there is a category actor (and, maybe someday, a site actor?) and a person actor? Would you have a list?

Only the attributedTo Actor of the object would be listed, so there’d only be one.

[mcdanlj]

@angus

That said, I’ve already implemented 3, and I suspect that will be the eventual answer which will allow me to remove this restriction. I’m still holding out some hope that someone might be able to come up with a slightly more nuanced approach, or something I haven’t thought of yet.

I do see the ugliness. The thought process that got me there is something like this…

I could naively imagine something like #3 with just a tiny bit of #2 — To also federate a generated update from the old user that adds to the last version they published some system-generated text at the top or bottom something vaguely like "for future updates, follow @newuser@site "

Then it would (again naively) make sense to allocate a new ID for the updated post under the new attributedTo and which is used for the new owner’s updates.

An obvious-to-me edge case would be changing ownership back to the original owner — does it revert to the old post ID or allocate yet another ID? I’d think revert, in which case the federated post ID would actually have to be a key to a (user, discourse post) tuple. I’d expect this to take a migration to support with backward compatibility.

All that as a thought experiment does make me appreciate more clearly why you wouldn’t be eager to rush ahead of your proposed change to mastodon being considered!

Exclusive of your Mastodon PR being accepted, I could imagine being able to mark individual posts as unfederated, which would federate as a deletion if they were previously federated, and/or could be done with the plugin installed but before federation was enabled, and then allow ownership change for only unfederated posts. All posts where I want to be able to change ownership are posts that aren’t valuable to federate, as far as I can tell.

I could imagine that being valuable even if your Mastodon PR is accepted, and changing ownership is supported. I’m not sure that it makes any sense to federate the category topic posts, for example. At least, I think I would exclude all of them from federating on my site even if changing ownership were supported, if I had the option to exclude them.

[angus (Angus McLeod)]

@mcdanlj

I could naively imagine something like #3 with just a tiny bit of #2 — To also federate a generated update from the old user that adds to the last version they published some system-generated text at the top or bottom something vaguely like "for future updates, follow @newuser@site "

Then it would (again naively) make sense to allocate a new ID for the updated post under the new attributedTo and which is used for the new owner’s updates.

An obvious-to-me edge case would be changing ownership back to the original owner — does it revert to the old post ID or allocate yet another ID? I’d think revert, in which case the federated post ID would actually have to be a key to a (user, discourse post) tuple. I’d expect this to take a migration to support with backward compatibility.

All that as a thought experiment does make me appreciate more clearly why you wouldn’t be eager to rush ahead of your proposed change to mastodon being considered!

An interesting thought experiment, however this would not work for a few reasons.

• You don’t follow individual users in discourse activitypub.
• You can’t change the ID of an existing activitypub object (you’d have to create a new object).
• As you say, if the ownership changed again, or multiple times, you’d end up with multiple objects for one post, which would be unmanageable.

@mcdanlj

Exclusive of your Mastodon PR being accepted, I could imagine being able to mark individual posts as unfederated, which would federate as a deletion if they were previously federated, and/or could be done with the plugin installed but before federation was enabled, and then allow ownership change for only unfederated posts. All posts where I want to be able to change ownership are posts that aren’t valuable to federate, as far as I can tell.

I could imagine that being valuable even if your Mastodon PR is accepted, and changing ownership is supported. I’m not sure that it makes any sense to federate the category topic posts, for example. At least, I think I would exclude all of them from federating on my site even if changing ownership were supported, if I had the option to exclude them.

One thing I can do now in this vein is to change the restriction to whether the first post in a local topic is published. That will help with some topics as you say.

Allow changes of post owner on unpublished local topics

[mcdanlj]

@angus

You don’t follow individual users in discourse activitypub

My misunderstanding; I thought you had also created the ability to do that, as well as category actors. (Not a feature request, just a misunderstanding.)

@angus

You can’t change the ID of an existing activitypub object (you’d have to create a new object).

That was what I was trying to describe, and clearly failed. It was intended as something like a reductio ad absurdam in any case.

@angus

One thing I can do now in this vein is to change the restriction to whether the first post in a local topic is published.

That would be wonderful!

[David_Ghost]

Hi, there’s a limitation for Lemmy?

I cant follow: @batepapo@lemmy.eco.br by exemple

In fact, I can follow. The “unfollow” button even appears under the profile, but when I refresh the page, everything disappears.

[Tony_B (Tony)]

Great job! I have a question regarding activity pub delivery delay minutes. Is there a way to disable the feature so the post would be visible right away?

[eisammy (Dreadwhole)]

Setting 1 min its almost immediately but I wish to post both real time too.

[eisammy (Dreadwhole)]

@David_Ghost read this

ActivityPub Plugin

Thanks for the feedback guys @hellekin This will address the exceptions you were reporting. @mcdanlj It will also address the second exception you reported (same issue). @mcdanlj The first issue you reported is a little stranger how frequently are you seeing it? Could you possibly share more details? Thanks for the feedback on that, will definitely consider it in phase 2 of the work I think that’s probably not going to happen in phase 2, but noted Editing is on…

[icaria36]

@eisammy

the first one its about title and mastodon

This is the first thing I’ve noticed as well. What would be the drawback of adding the title of a new topic to the post distributed via ActivityPub?

[Discourse topic title]
[empty line]
[Discourse topic text, as published now]

[angus (Angus McLeod)]

@David_Ghost

Hi, there’s a limitation for Lemmy?

The Lemmy folks were working on adding Discourse compatibility. It’s on my agenda to check in on that.

@David_Ghost

In fact, I can follow. The “unfollow” button even appears under the profile, but when I refresh the page, everything disappears.

That means Discourse is sending a Follow but not getting back an Accept from Lemmy.

@Tony_B

Is there a way to disable the feature so the post would be visible right away?

Currently you can only do this using an environment variable (e.g. set in your app.yml file)

DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0

@icaria36

What would be the drawback of adding the title of a new topic to the post distributed via ActivityPub?

The title of a topic is already published. It is the name of the collection associated with the topic.

That is how Discourse to Discourse federation, or Discourse to NodeBB, or Discourse to any forum-like platform includes topic titles. Mastodon does not process titles. If we were to put the topic title in the content of the Note as you suggest this would pose problems, e.g. for when content is federated to platforms that support titles.

Fundamentally, the limitation you’re describing is that Mastodon is a micro-blogging platform. We have already added functionality to accomodate that, i.e. the [note][/note] markup to let you target the content you’re federating. If you want to have proper forum-like federation, I’d suggest federating with other Discourse instances.

Yes, there are many Mastodon instances. But there are also many Discourse instances. If a Discourse instance you want to federate with isn’t set up to do so yet, I’d be happy to help them get set up.

[mynoxin (Christian)]

Is it possible to delete Actors?
And would it be possible to set up multiple categories, so that he’s posting everything, that is new in discourse?
Otherwise someone has to follow xx handles on mastodon to get all the content from all categories.

[angus (Angus McLeod)]

@mynoxin

Is it possible to delete Actors?

You can disable an Actor, which disables everything related to that actor.

If you delete the category or tag the actor is associated with it will delete the Actor. Deleting an actor in isolation is not currently possible. I would recommend just disabling the Actor.

@mynoxin

And would it be possible to set up multiple categories, so that he’s posting everything, that is new in discourse?
Otherwise someone has to follow xx handles on mastodon to get all the content from all categories.

This may be possible in the future (medium to long term) if we add an “Application” actor for an entire Discourse. Federating everything on a Discourse through a single Actor will likely always be a niche use case.

[mynoxin (Christian)]

Hm okay. Maybe my understanding of the possibilities are different…

Yesterday I set it up and it worked fine. I deleted the Postings on Discourse, because i Just tested it, but the postings are still online in Mastodon. So I thought i could delete the account to delete the content from Mastodon as well.
When I just disable it, the content is still online on Mastodon.
And when I can’t delete it, I can not use this handle with other categories in the future. May I want to change some categories in the future but I can not use it with that handle which has xx followers. SO I need to create a new handle and everyone has to follow it again. I can’t see any advantages of only diasabling a handle I dont’t need anymore.

And: When I disable one handle, the other is disabled too. So I can only run multiple handles or nothing?

@angus

This may be possible in the future (medium to long term) if we add an “Application” actor for an entire Discourse. Federating everything on a Discourse through a single Actor will likely always be a niche use case.

But thats what I want, or am I understanding it wrong? I want to inform persons in a social network about the discussions on my whole discourse and not only for one tag or category. When i run a “News” section, I can understand it, but I want everyone to take part in the discussions so I have to post everything and not only one category.