# ActivityPub Plugin
**URL:** https://meta.discourse.org/t/activitypub-plugin/266794
**Category:** Plugin
**Tags:** experimental, activitypub
**Created:** [May 31, 2023, 5:21pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794 "2023-05-31T17:21:52Z")
**Posts on this page:** 20
**Page:** 5
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [August 23, 2023, 2:05am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/85 "2023-08-23T02:05:29Z")
> [@angus](#):
>
> Hm not sure I agree. The end result of this will be two identical Notes in the Fediverse authored by different Actors, both of which will be still visible on multiple platforms. For a new person coming to that content for the first time they’ll see the same content authored by different people.
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.
Not perfect, but perhaps a “least bad” option?
I suppose, as an alternative, you could federate out an edit that annotates the post as superseded by a transfer of ownership, kind of like adding the “discuss this on our forum” link?
> [@](#):
>
> Conversely, when you change an author in Discourse you essentially re-write history, for a new person coming to the content for the first time you just see the new author. There’s a difference there don’t you think?
Sure, I’m not arguing it’s not a difference, only saying that it seems like an acceptable difference, compared to blocking a useful and utilized Discourse feature.
Deleting the original will orphan threads _in the context of other platforms to which you are federating,_ since you can’t change the actor associated with an activity in an edit (as I understand it).
An alternative might be to stop federating edits _at all_ if the post in Discourse has a different author from when it was first federated. Maybe with a warning? “Changing owner will disable federation for this post, do you really want to proceed?”
> [@angus](#):
>
> I’m not sure I entirely understand. Are you saying that all edits to the wiki post, by any user, should be just treated as standard Update activities attributed to the original Actor (i.e. the person who posted it)?
Yes. That is what it looks like in Discourse to a normal user, who might not know that they can click the pencil icon and go through changes to review, or doesn’t have permissions. 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
From my perspective, this is as close to equivalent as you get, given the differences in underlying model.
As I see it, “click to see post on original site” already shows different content between implementations that are fediverse-first, even ignoring this plugin. Different set of comments visible, different markup, different handling of articles. So some differences being visible through this plugin does not surprise me; I think it’s inevitable.
(Thank you again for your thoughtful consideration of these ideas. I recognize that these are hard boundary cases, I’m grateful for the work, I do not assume that my ideas are best, and I don’t mean to create any sense of obligation for this phase or any phase of work on this, or even to respond to anything in particular that I’m writing.)
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [August 23, 2023, 7:17am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/86 "2023-08-23T07:17:24Z")
> [@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.
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [September 7, 2023, 7:02pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794/87 "2023-09-07T19:02:59Z")
> [@angus](#):
>
> Support Like Activity
>
> - See [Activity Vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-like)
>
> Support Discourse users verifying their identity on Mastodon so Discourse posts created from their Toots are associated with their Discourse user account.
>
> - Allow a user to perform the [Mastodon OAuth Authorization](https://docs.joinmastodon.org/spec/oauth/) flow with the Mastodon server where their account is stored. This is initiated from the user’s Discourse account settings.
> - Using the Discourse user’s Mastodon access token, obtain and store the AP ID of their Mastodon account and store it with their Discourse account.
> - Associate all Discourse activities associated with AP Activities from an Actor bearing a Discourse user’s AP ID with that Discourse user, whether they were performed before or after the user verified their identity.
These two items are now done as well, I just merged @angus’s [PR for identity verification via OAuth](https://github.com/discourse/discourse-activity-pub/pull/24). Barring bug fixes and performance improvements, this completes the current phase of features added to the plugin.
As it stands, the plugin is quite feature-rich. To recap the main features quickly, the plugin supports:
- Followers Only post publication in ActivityPub (default is Public)
- First Post or Full Topic publication (default is First Post)
- two-way sync when using Full Topic publication, i.e. all Discourse-created posts in a topic will be published in ActivityPub, and vice versa, replies in ActivityPub will be posted to Discourse
- option to publish posts as Notes (for shorter content services like Mastodon) or Article (more appropriate for long content services)
- identity verification
Next up we will work on fine-tuning the current features, improving usability. Feedback is still welcome, of course. I am particularly interested in ways to explain how all this works to regular users, it’s not an easy feat.
> [@mcdanlj](#):
>
> Is the end goal, **broadly speaking,** to restrict Discourse to only what canonical ActivityPub supports, or is it to federate from an unrestricted native Discourse experience to the fediverse on a best-effort basis?
> [@angus](#):
>
> Personally, I don’t think about it either way. [Discourse.org](http://Discourse.org) will set the overall agenda here, but broadly speaking decisions are made on the basis of how it works, and what’s practical. If there’s a sensible and sustainable way of allowing authorship changes on all posts, regardless of provenance, then great.
I’m very much on the same page as @angus, our goal is to do what’s practical and achievable with a reasonable amount of effort. To that effect, we’re willing to accept some reduced functionality in Discourse at this time. That’s our best bet to find out if specific limitations are important to address or not (for example, will the plugin users often run into wiki-ActivityPub limitations?).
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [September 7, 2023, 9:45pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794/88 "2023-09-07T21:45:40Z")
> [@pmusaraj](#):
>
> To that effect, we’re willing to accept some reduced functionality in Discourse at this time.
Do I understand correctly, then, that we’re at the point where it makes sense to articulate the restrictions?
---
### Author:  [@Matthias\_Schuster](https://meta.discourse.org/u/Matthias_Schuster)
#### Post date: [September 9, 2023, 9:44am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/89 "2023-09-09T09:44:59Z")
Hi there 🙂
First, thanks for developing all this.
Then, I am really interested in connecting different ActivityPub services together, and as far as I read, is this mostly about sending messages from Discourse to Mastodon back and forth.
I am aware, that the protocol is service-agnostic, but is there any kind of documentation, to, let’s say, connect different Discourse instances, or integration of Nextcloud, or Peer Tube, etc.?
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 9, 2023, 11:35am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/90 "2023-09-09T11:35:17Z")
> [@mcdanlj](#):
>
> we’re at the point where it makes sense to articulate the restrictions?
We have disabled post author changes and wikis in ActivityPub topics for now for the reasons I’ve already mentioned (their assumptions don’t work with ActivityPub out-of-the-box). Those are the only two features that have been temporarily disabled in ActivityPub topics in this fashion. Any other reduced functionality should be reported as an issue.
> [@Matthias\_Schuster](#):
>
> Then, I am really interested in connecting different ActivityPub services together, and as far as I read, is this mostly about sending messages from Discourse to Mastodon back and forth.
>
> I am aware, that the protocol is service-agnostic, but is there any kind of documentation, to, let’s say, connect different Discourse instances, or integration of Nextcloud, or Peer Tube, etc.?
This is an ActivityPub plugin that closely follows the ActivityPub specification, so it is designed to work with any service that follows that specification, which includes all of those you’ve mentioned (and others). Mastodon is the first ActivityPub platform we’ve focused on integrating with because, practically speaking, you have to ensure compatibility with one service at a time and it’s the largest ActivityPub platform.
---
### Author:  [@roke\_julian\_lockhart](https://meta.discourse.org/u/roke_julian_lockhart)
#### Post date: [September 24, 2023, 12:30pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794/91 "2023-09-24T12:30:39Z")
Tried twice at [https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub](https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub)
- [https://meta.discourse.org/ap/auth/oauth/redirect?code=N7bmMhl5YsaASW-D7U-wHxeQzNVtV4O2a-5siMp\_Ax8](https://meta.discourse.org/ap/auth/oauth/redirect?code=N7bmMhl5YsaASW-D7U-wHxeQzNVtV4O2a-5siMp_Ax8)
- [https://meta.discourse.org/ap/auth/oauth/redirect?code=InxG0OIEqB1WH7tuNWtaiF9UpC8NAPJ8uBuvZ7fgqZ4](https://meta.discourse.org/ap/auth/oauth/redirect?code=InxG0OIEqB1WH7tuNWtaiF9UpC8NAPJ8uBuvZ7fgqZ4)
> ```json
> {
> "errors": ["You are not permitted to view the requested resource."],
> "error_type": "invalid_access"
> }
>
> ```
What do I do?
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 25, 2023, 3:43am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/92 "2023-09-25T03:43:27Z")
Hey @roke_julian_lockhart, thanks for the feedback. How are you performing the authorization flow? Are you clicking “Authorize” in the above screenshot in a browser (also which browser?) Or are you copy / pasting the urls in some fashion? I ask because you’ve got them there in your post. Here’s a video of the standard flow working for me on [meta.discourse.org](http://meta.discourse.org)
https://www.loom.com/embed/247f2817d6ae41378794e1e7699872aa?sid=fd684e22-204a-449a-9fc9-5134509909a5
Are you doing anything different from that?
---
### Author:  [@roke\_julian\_lockhart](https://meta.discourse.org/u/roke_julian_lockhart)
#### Post date: [September 25, 2023, 11:37am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/93 "2023-09-25T11:37:57Z")
> [@angus](#):
>
> Are you doing anything different from that?
@angus,
1.
2.
3.
4. [Log in - Mastodon](https://mastodon.social/oauth/authorize?client_id=Y1GuLE1eoX28c2qqaw1qCe8n_KHF256IPFnpiZYuW5g&response_type=code&redirect_uri=https%3A%2F%2Fmeta.discourse.org%2Fap%2Fauth%2Foauth%2Fredirect&scope=read%3Aaccounts&force_login=true)
5. Then the previous
6. [https://meta.discourse.org/ap/auth/oauth/redirect?code=s2H3Og\_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE](https://meta.discourse.org/ap/auth/oauth/redirect?code=s2H3Og_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE)
---
### Author:  [@aboutDavid](https://meta.discourse.org/u/aboutDavid)
#### Post date: [September 25, 2023, 5:24pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794/94 "2023-09-25T17:24:04Z")
Hello, after the latest update, it seems to break user profiles (/u/user). The username and profile picture would show up (plus the list of user offensives at the top)
We went through our plugins list and disabled each one one by one until the problem went away. It also worked with [safe mode](https://meta.discourse.org/t/53504?silent=true) enabled. Here are some of the client errors we would get:
```plaintext
Cannot read properties of null (reading 'getBoundingClientRect')
at Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
at e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
at p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
at p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
at h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
at $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
at $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
at $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)
```
Here is what it looks like with the plugin enabled (for your own account)
For another user (in this case, 9pfs)
Here’s another funny bug caused by the plugin:
We’re currently running 3.2.0.beta2-dev from [this commit](https://github.com/discourse/discourse/commits/af305366909fd712362d727d0fa92f380d71d4cd) and we are running version 0.1.0 of the plugin from [this commit](https://github.com/discourse/discourse-activity-pub/commit/6f29542d603627016757f8cd9bb4a145e8f50866).
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 26, 2023, 12:42am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/95 "2023-09-26T00:42:33Z")
@roke_julian_lockhart Do you have cookies disabled or some kind of privacy extension running? The authorization flow currently relies on a secure session cookie to work.
@aboutDavid Thanks for the report. While it’s possible, it seems unlikely that what you’re sharing is being caused by an issue in this plugin. Could you share a link to your site? Also do you have any themes or theme components enabled?
---
### Author:  [@Firepup650](https://meta.discourse.org/u/Firepup650)
#### Post date: [September 26, 2023, 12:51am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/96 "2023-09-26T00:51:58Z")
> [@angus](#):
>
> it seems unlikely that what you’re sharing is being caused by an issue in this plugin. Could you share a link to your site? Also do you have any themes or theme components enabled?
From [safe mode](https://meta.discourse.org/t/53504?silent=true) troubleshooting, we know the following for certain:
1. It’s an unofficial plugin
2. It is not a theme or theme component.
As far as I’m aware, we have two unofficial plugins:
1. Animate avatars (Manually confirmed not to be the culprit)
2. ActivityPub
As for a site link:
[https://amcforum.wiki](https://amcforum.wiki)
---
### Author:  [@hello-smile6](https://meta.discourse.org/u/hello-smile6)
#### Post date: [September 26, 2023, 1:06am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/97 "2023-09-26T01:06:03Z")
> [@Firepup650](#):
>
> As far as I’m aware, we have two unofficial plugins
The upgrade UI shows a checkmark next to all plugins other than those two (indicating that they are official plugins).
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 26, 2023, 1:40am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/98 "2023-09-26T01:40:30Z")
The issue on your site is likely being caused by something using the user-profile-avatar-flair plugin outlet. This plugin doesn’t use that outlet. The animated avatars plugin does however.
> [@Firepup650](#):
>
> Manually confirmed not to be the culprit
How did you confirm this?
---
### Author:  [@hello-smile6](https://meta.discourse.org/u/hello-smile6)
#### Post date: [September 26, 2023, 1:44am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/99 "2023-09-26T01:44:27Z")
> [@angus](#):
>
> How did you confirm this?
@aboutDavid checked and made sure that the plugin had no client-side JS. Is the issue partly server-side?
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 26, 2023, 1:45am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/100 "2023-09-26T01:45:57Z")
No client-side js doesn’t necessarily mean no client-side issues. In this case the issue seems to be arising from the way a plugin outlet is being used, possibly in a template. Could you try removing the animated avatars plugin and let me know the result?
(As an aside, the Animated Avatars Plugin does have client-side js. [See for example](https://github.com/discourse/discourse-animated-avatars/blob/main/assets/javascripts/initializers/animated-avatars.js)).
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 26, 2023, 9:29am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/101 "2023-09-26T09:29:12Z")
I just went to edit a category here on Meta (to change some group access permissions). I didn’t change any activitypub-related settings, but we ended up with these three entries in the staff log:
I guess they technically went from `nil` to their default value, so there is no actual change in behaviour? Still, it would be good to avoid this remove logging to avoid confusion.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 26, 2023, 10:47am UTC](https://meta.discourse.org/t/activitypub-plugin/266794/102 "2023-09-26T10:47:15Z")
Thanks for the report David, I’ll take a look soon.
---
### Author:  [@aboutDavid](https://meta.discourse.org/u/aboutDavid)
#### Post date: [September 26, 2023, 3:10pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794/103 "2023-09-26T15:10:48Z")
whoopsy, i’m a little dumb today, apologies
edit: yeah it’s most likely animated avatars, sorry for wasting your time lol
---
### Author:  [@roke\_julian\_lockhart](https://meta.discourse.org/u/roke_julian_lockhart)
#### Post date: [September 27, 2023, 3:50pm UTC](https://meta.discourse.org/t/activitypub-plugin/266794/104 "2023-09-27T15:50:17Z")
> [@angus](#):
>
> @roke_julian_lockhart Do you have cookies disabled or some kind of privacy extension running? The authorization flow currently relies on a secure session cookie to work.
@angus, not that I know of.
> 
and I ensured that I disabled uBlock Origin, not that I use the privacy lists anyway.
* * *
However, I’ve encountered a different issue testing this today.
**[Log in - Mastodon](https://mastodon.social/oauth/authorize?client_id=Y1GuLE1eoX28c2qqaw1qCe8n_KHF256IPFnpiZYuW5g&response_type=code&redirect_uri=https%3A%2F%2Fmeta.discourse.org%2Fap%2Fauth%2Foauth%2Fredirect&scope=read%3Aaccounts&force_login=true)**
> Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method.
> 
> **[Google Search](https://www.google.com/search?q=Client+authentication+failed+due+to+unknown+client%2C+no+client+authentication+included%2C+or+unsupported+authentication+method.+)**
[Previous page](https://meta.discourse.org/t/activitypub-plugin/266794.md?page=4)
[Next page](https://meta.discourse.org/t/activitypub-plugin/266794.md?page=6)