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!
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.
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. 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.
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!
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.
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:
A configuration that says āalso federate subcategoriesā (applying visibility restrictions)
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.
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.
@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.
Thinking about it, yes. At first, I think weād only use it for announcements (in combination with the scheduled publishing feature in a hidden category for drafts). It might also be useful for our social media team to use to draft/coordinate/schedule mastodon posts.
I think itād be exciting to have something even wider, making it at least possible to follow everything ā and maybe even participate. But that would be much, much further down the road.
The default, and best supported, ActivityPub content is HTML (see further). We may add some form of markdown support to Notes and Articles in the future.
Thereās something else going on with your examples. This plugin sends HTML (currently, and also in this update). Your screenshots are showing uncooked markdown.
An Article is for when you donāt want to restrict the length of the content being federated (i.e. you want to federate entire posts). Note that Mastodon currently converts the content of Article types into a link, however platforms like Lemmy will show the full content. See further mastodon/mastodon#24079
Right, the plugin is not official because it is still in fairly early stages of development. Hosted customers can certainly reach out and inquire about using it.
CDCK builds a lot of plugins and not all are marked official, some of the plugins we build are experimental, niche, etc. I do think eventually we will mark this plugin as official