Sure, we have entire PieFed at our disposal...Another option would be to add some common funtionality within a separate plugin interface. I guess we have to poke a bit at it and see where this is going to lead.

Eventually we should give this more structure, yes. I think I'm kind of fine if this isn't beginner friendly yet, my code-quality here isn't exactly what's supposed to be in PieFed and it prevents people from copy-pasting it without reading. I'll do better once it's more than just explorative.

I picked kind of an unfortunate/messy example here. add_post / Post.new are kind of duplicate code, but for specific cases. And then everything is nested and does stuff in several places and we got all the additional complexity with what goes into a celery task and what's called directly... And then flairs got added to one function but not to another one... I guess this attempt wouldn't be as messy if handling posts were few, instead more general functions and we'd abstract the Celery stuff away...

This is great work. I didn't realize that you also had automatic replies built into this.

I was just wondering how to do db queries from a plugin the other day, so this is really helpful. I guess we have to wrap the whole thing in a with like for a celery task.

I am guessing that for production/distribution, it would be best to have something like a config/ini file that is read in instead of the magic numbers/strings.

Also, I am wondering if it might be easier to make the posts and the like through network requests to the api. It would be easier to handle failures and build in retries, but I guess you already have everything you need to just call edit_post directly.

Good catch. I tried, but Blueprints can't be used here. As far as I understand, Flask sets up the routing early on when the application gets loaded. It's fixed and can't be changed at the point the plugins get loaded.

There is a way to achieve that, and that's how the CMS pages do it. We'd need to intercept the 404 error handler and build our own routing system on top. I suppose it's a bit tricky due to how Python executes code when loading it and the way decorators work, plus we might want to offer compatibility with the authentication, rate-limiter etc. And I haven't looked in to this yet, but I guess it'll boil down to another lookup-table with callbacks in the plugin system and an additional decorator to wrap this.

I see that Blueprint is imported at the top, but then isn't used. Are you able to register new routes in a plugin and render a template? If so, that could be a way to change plugin settings in the web ui rather than editing a text file in the plugin directory.

This is a use case that hadn't even crossed my mind. Thanks for the POC.

Live example: https://palaver.p3x.de/statistics

(mind this is my single-user instance's very subjective perspective on the Fediverse)

It will take some time to figure out some useful plugin examples. Until then, there's some example boilerplate code in: https://codeberg.org/rimu/pyfedi/src/branch/main/app/plugins/example_plugin