ActivityPub Plugin

This is really exciting to see — a really high level of federation and interactivity. :tada:

Are you planning to do any intermediate releases, or will this be one big release in ~3.5 months?

There may be some intermediate releases, but I can’t promise anything on that front yet. I’ll keep you in the loop as we go.

2 Likes

110% agree - this includes a lot of great aspects. :tada:

Any chance there can at least be an intermediate release on this front?

To be honest, adding a “public posts as the default” intermediate release would be immediately welcome.

2 Likes

Note that public posting would depend on federating edit actions (the first listed bullet), I believe.

1 Like

I can’t make any promises at this stage but there may well be intermediate updates for both Update federation and Audience Targeting (public posting).

4 Likes

:eyes:

1 Like

That’s a known limitation. Until federating edits is supported, the plugin blocks edits to federated content, and there is no configuration to disable this.

2 Likes

To be clear, I was trying to edit a post here on meta and got this error.

3 Likes

Oh, I’m sorry to have misunderstood. @feature@meta.discourse.org and @announcements@meta.discourse.org at least are being federated from here, and this choice is the number one reason I haven’t enabled this for Maker Forums…

2 Likes

Yes, this is the first item in Phase 2 that I’ve worked on. In fact, there’s already a PR for it, so you’ll get some relief on that front soonish.

2 Likes

I just deployed your add_update_support_to_first_post_only branch on my test site and successfully walked through the functionality end to end; creating, editing, and deleting, with the mix of plugins I happen to have installed. Thank you! :tada:

Is community testing like this at all valuable?

2 Likes

Nice!

I wouldn’t necessarily advise it as a regular practice on all un-merged PRs as it does contain some risk and I can’t provide support for issues that crop up on umerged PRs (the PR review process plays an important role), but if you did find an issue that would be useful, so I’m not going to tell you to stop if you’re ok with that risk, e.g. you’re deploying them on a development or staging site. I wouldn’t advise you deploy them in production.

1 Like

Oh absolutely, if it breaks I get to keep all the pieces. Also known as reloading my test site’s database from a recent backup of the main site. :grin: Also, I understand that PRs get force-push updates, etc.

If my testing ever becomes distracting noise, don’t hesitate to tell me, I won’t take it the wrong way. My goal is to support the effort, not to get in the way of development.

3 Likes

Maybe you can add check boxes on that post so we can follow progress?

The roadmap looks great, I’m so happy this is ongoing. Kudos to you and the Pavilion team [edited:] for building it and the Discourse @team for commissioning and making it official!

6 Likes

Done. Checked means the feature is merged. Next on the list is

I just want to emphasise that this is a Discourse.org plugin and kudos should go to them for specifying, commissioning, publishing and supporting it. This is not a Pavilion plugin. We’re just building it.

9 Likes

Re-reading this, I’d like to look at the sub-category question I mentioned earlier. @mattdm, are you thinking of enabling this for Fedora Discussion? I’d think that it could be a bad user experience to have to follow each of the sub-categories on Fedora Discussion separately?

For my site, I have 8 top-level categories to federate, with an additional 21 public subcategories.

I’d like people to be able to subscribe to the top-level categories and get the public subcategory content, but not federate the view-limited subcategories (e.g. the Staff category is a private subcategory of a public parent category on my site).

I can see two ways about this:

  1. A configuration that says “also federate subcategories” (applying visibility restrictions)
  2. The ability to re-use Actors in category configuration, so that I can just apply the same Actor to the parent category and the public sub-categories

The second looks like a better choice; more flexible, more explicit, and if I understand right probably a better match with the data model.

I guess an alternative would be to build a bot (or bots) to automatically boost all posts by sets of Actors on my Discourse. That would let me also implement an @all@... as well.

:thinking:

4 Likes

Thanks for raising that again. I’ll take a look, discuss internally and let you know.

3 Likes

The more I’ve thought about this, the more I like the idea of keeping the Actors 1:1 with categories, so that users can follow exactly only the categories they want, and also making a bot that automatically boosts posts by a set of Actors (say, a category and all its public subcategories, or even all the public subcategories. Maximum flexibility, no additional work for you.

As I thought about this, I remembered that @Stark9837@techhub.social wrote a bot @3dprinting@techhub.social which automatically boosts all the posts it finds that contain the #3dprinting tag to create a kind of group. I asked about the bot and got this response:

So when it’s released it might just do exactly what I’m looking for.

1 Like
  • Tag actors would be nice, and
  • when page-publishing is active, following newly published pages would be useful.
1 Like

@mcdanlj The way for posts grouped in topics (i.e. forum content) to be federated on a taxonomic basis is what Felix outlines in FEP-1b12. I did my own review of the specifications, architecture and current usage (particularly Mastodon) from first principles and came to the same conclusion he does there (and did with Lemmy). Basically, category Actors will be Announcing (boost in Mastodon) the Activities in their categories to their Followers. That will be how the “Full Topic” mode in this plugin works. I’m currently working on this item.

These won’t be part of Phase 2, but are possible additions further down the line.

6 Likes