Add ActivityPub support

[pauloxnet]

Is your proposal related to a problem?

I want the readers of my Wagtail based website will be able to follow my news on Mastodon and other federated platforms that support ActivityPub.

Describe the solution you'd like

Add support for ActivityPub in Wagtail so that it works out-of-the-box.

I'm no expert on the ActivityPub protocol, but I imagine that the functionality you could add in Wagtail with an integration with ActivityPub (in addition to an RSS bot) could basically be the ability to receive and track reactions (e.g. reply, boost, fav, bookmark) and maybe show threaded comments.

Describe alternatives you've considered

• Wordpress already have a plugin to add ActivityPub support to already published website.

• Drupal has ActivityPub support too.

Additional context

There are already some Django-based implementation of ActivityPub protocol for standalone servers (es: takahe or bookwyrm) but it would be very useful to add ActivtyPub support to an already published Wagtail based website.

[andrewgodwin]

So, as an alleged expert in this now, here's what I think the basic coverage of ActivityPub (i.e. sending posts to followers with only a single "account" you follow for the whole server) would entail:

• A Follower model that tracks which ActivityPub Actors are following the server
• A FanOut model that tracks which Actors have been delivered which posts
• A background worker, like Takahē's Stator, that delivers Accept (for Follow) and Create.Note (for posts) messages to other Actors and which can handle retrying them
• An Inbox view that accepts Follow messages from other users, and accepts and drops all the Create.Note messages that other servers are going to start sending you because they think you're more capable than you are.

Needless to say, this means you also need a working JSON-LD and signature implementation, but those could be lifted from another project directly or placed into a reuseable library.

[lb-]

I personally think that something like this would be better suited to be an external package. Maybe even starting as a blog post or two from anyone in the community.

While I agree that this capability would be awesome and I'm all for ActivityPub - this is not something that all sites would use and might not be suitable for Wagtail core.

It might be worth discussing what parts are missing that may be suitable for Wagtail. For example there is an existing RFC to add background workers to Wagtail - wagtail/rfcs#72

I'll let other core team members add their thoughts and maybe experience with implementing something similar.

[pauloxnet]

Thanks for your feedback.
I'm not a Wagtail or ActivityPub expert but I thought that integrating ActivitPub in Wagtail can be a great features that can attract more users and developers.
I opened this issue to start a discussion about this feature but I don't know if it can be implemented as an external package or not, I hope others can share their thoughts.

[lb-]

Thanks @pauloxnet - I 100% think this is a good discussion to have and agree that the more Wagtail can do for developers the better it is. However, some things are often best suited as an external package even if it may end up in core in the future.

Let's give others a week or so to give feedback and thoughts - we may end up moving this to a discussion not an issue from there.

[pauloxnet]

I agree with you. Maybe this would be a starting point for an external package, if feasible.

[zerolab]

Hey @pauloxnet.
Thank you again for raising this. It is a great idea. We discussed it in the core team meeting and the consensus is that is much better suited as an external package:

1. This would be opt-in. Aside from the models @andrewgodwin describes in Add ActivityPub support #9732, we'd want a mechanism for opting for some of the functionality on particular page types (e.g. only blog posts or news).
2. Should allow making it work with Django apps
3. Allow for much faster iteration

Converted the issue to a discussion so we can continue bouncing ideas etc. Will share the link to this in the Wagtail Slack as I am sure there must be others interested in this.

[pauloxnet]

Hi @zerolab,
I'm glad I helped bring this up.
I hope that soon someone will soon be able to take advantage of Andrew's guide to try writing an external package that activates the support for ActivityPub when needed.

[lb-]

Interesting article on Python / Mastodon - https://dev.to/andypiper/a-opportunity-for-developers-1ee4

[pauloxnet]

Interesting. Thanks for sharing. I think also the latest @andrewgodwin article is interesting to better understand ActivityPub
https://aeracode.org/2022/12/05/understanding-a-protocol/

[lb-]

WordPress just announced a plugin for Mastadon / Activity Pub support.

https://techcrunch.com/2023/10/11/wordpress-com-blogs-can-now-be-followed-on-mastodon-and-other-federated-platforms/

Based on an acquired plugin earlier this year. https://techcrunch.com/2023/03/13/wordpress-com-owner-automattic-acquires-an-activitypub-plugin-so-blogs-can-join-the-fediverse/

See https://wordpress.org/plugins/activitypub/

[pauloxnet]

It would have been nice if Wagtail had introduced ActivityPub support before WordPress. However, the fact that they did so confirms that it is a feature worth investing in. Probably with this move by WordPress the user base will grow further.

[thibaudcolas]

Thank you for keeping the conversation going @lb- and @pauloxnet :) Personally I think this would definitely be a great fit for Wagtail/Django, both on functionality and also alignment of value. But I’d agree in the immediate term this is a clear case where we’d recommend creating a package. We simply currently don’t have enough expertise with ActivityPub within our current "core" maintainer group to help make this happen in wagtail/wagtail.

It could however still be an "official" Wagtail project if there’s enough interest. We have a lot of code that’s opt-in functionality in a package and nonetheless well supported. If it helps, here are the kinds of things that I think are possible, based on similar initiatives we’ve supported in the past:

1. Have the package under @wagtail or @wagtail-nest in GitHub, our official organizations for work of this nature when there’s a need to coordinate effort.
2. Have the idea featured on our roadmap so there’s visibility, with the goal to attract either funding or contributors (or both).
3. Write a blog post (or re-publish a ready-made post) on the Wagtail blog to have more eyes on this / share any call to action.
4. Showcase this idea / a more established proposal at one of our What’s new in Wagtail events.
5. Run / promote a crowdfunding campaign, help with grant applications to established programs, or coordinate with our existing and upcoming feature sponsors to secure funding. Not all Wagtail users out there will be interested in this, but there are a few specific Wagtail users that work in the open source space and we could at least ask (Mozilla, IETF, Freedom of the Press foundation, Software Freedom Conservancy, etc).
6. Organize this work as a Google Summer of Code or Outreachy internship (3 months full time – 300-400 hours from a junior Django developer w/ support from 2-3 mentors).

---

In the short term, if anyone wants to push for this, I’d recommend to:

1. Bring this to our core team meeting’s agenda / team discussions on Slack again, and on our Slack, and other teams’ meetings / Slack channels to find other people interested in this.
2. Write a more fleshed-out proposal. See for example the kind of length / details we use for our GSoC project ideas.

And from my perspective with little understanding of the work needed here, I’d appreciate:

1. A rough sense of how much work this would take for say a solo senior Django dev with pre-existing ActivityPub expertise. Even in that kind of scenario, I’m not sure whether we’re talking about "one week" of work or "10 weeks".
2. An understanding of why this should be a "Wagtail" thing rather than a "Django" one with a Wagtail integration. There are plenty of people who publish content with vanilla Django, or say Fein CMS / django CMS. Might as well make it work for them too unless a generic implementation wasn’t desirable. It could still be a Wagtail project (see for example queryish, but might as well make it work elsewhere if it’s possible.
3. Thoughts on how well this aligns with already-planned work. For example I see a mention of background workers – we have a background worker RFC. On the CMS UI, we’ve been hard at work on making our "Wagtail-specific" content features usable for arbitrary Django models. We’ve also been working on "inbox" concepts as part of Wagtail dashboard enhancements.

[thibaudcolas]

hi everyone (happy new year! ), this weekend I got the chance to meet people working at Mastodon and run this idea past them. They said it was a good idea :)

They also said minimal ActivityPub support should only be a few hundred lines of code (I assume they meant very minimal), and provided a recent "minimal ActivityPub server" tutorial (Russian). For comparison I see that wordpress-activitypub is on the order of 11k lines of code.

---

So – this feels doable? Do you all think this idea is still relevant or not so much? Feels to me like a quite neat Wagtail package for sure. For context, RFC 72: background workers which has been identified as a likely requirement – is provisionally on the roadmap for Wagtail 6.1* (May 2024 release, see RFC 91).

I’ve also asked what people think on Mastodon, if you want to check what the wisdom of the crowd is on the Fediverse.