ActivityPub Plugin

[angus (Angus McLeod)]

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).

Only call activity_pub_after_publish on local activity objects

@mcdanlj The first issue you reported is a little stranger how frequently are you seeing it? Could you possibly share more details?

@mcdanlj

So if you would consider an “also federate sub-categories” option, that might inform my plans

Thanks for the feedback on that, will definitely consider it in phase 2 of the work

@mcdanlj

I think that it might be interesting to also add a site-wide setting for an ActivityPub actor that federates all public posts on a site

I think that’s probably not going to happen in phase 2, but noted

@mcdanlj

For others here, what it really means is that if you federate, editing is currently disabled on all posts as soon as they are federated (except for posts with a literal [note]...[/note] section); this message shows up only when you try to save your edit

Editing is only disabled on the content of the post that makes up the Note. If you don’t use the Note tags, that’s the first 500 characters, or whatever you set activity pub note excerpt maxlength to. One of the things I’m definitely considering for phase 2 is to require [note][/note] tags for a Note as I can see confusion arising out of this.

@mcdanlj

I can’t turn this on without the ability to disable this control (or the control being removed because edits are federated). By way of a general example applicable beyond such trusting sites, any category with wiki-mode posts will be broken by setting up federation for that category.

You can address this by using [note][/note] tags to separate the Note from the other content.

@mcdanlj

I tried to delete a federated post that I had made a wiki, and got this:

Noted! We haven’t explicitly tested this with wiki posts. I haven’t been able to reproduce your issue with deleting wiki posts so far. Can you reliably reproduce it? I’ve added some specs in this PR which are all passing for that scenario, but keen to get to the bottom of that one.

Add wiki-specific delete specs

@hellekin

Partly working: the note was shortened a bit too much (71 characters) from the original:

The excerpt parsing is currently handled by the same system used by the topic excerpt parsing in Discourse (for the purposes of the topic list) which is probably why it cut out a fair chunk of that (topic list excerpts would have as well). I think we might need to use a separate parser as I can forsee this creating a few issues. Sit tight on this one; it’ll definitely be addressed in phase 2.

@sunjam

Remember that these accounts will be listed forever within the fediverse of social networks and can create confusion if you realize the account/category name should be changed after the fact.

Keep in mind that you can change the display name as much as you like and that the limitation on changing the username is not unique to this plugin. So while what you say is true, this is true for a fair chunk of the fediverse.

Changeable usernames?

Moreover, I haven’t included the username in the Actor’s id, partly to allow for the possibility of adding the ability to change the username in the future.

@mcdanlj

it would be possible to additionally implement account movement to rename the actor for a category

The plugin’s ActivityPub data is abstracted from Discourse’s data. There’s no inherent limitation in changing the Discourse model (i.e. what category) an actor is associated with. You could even possibly associate the actor with a different type of Discourse model in the future, i.e. associate an Actor you created for a category with a user instead (the relationship between Actors and Discourse models is polymorphic). Not saying these will be explicitly added as features, but more to say that there aren’t hard limitations in this respect.

In general, yes it’s worth considering what categories you want as actors, but overall this implementation has a relatively high degree of flexibility so your degree of concern should be relative to that context. I’ve explained a little more about the nature of the data flow in the plugin, which further elucidates this point, here

Adding federation support to Discourse

Thanks again everyone! It’s great to have engaged users.