So, the git repo hosting software (gitea) for !postActiv has developed a crashing problem which appears to be as a result of a bug that has been open and unfixed in gitea for a significant amount of time now, so I am probably going to end up having to set up gitlab again.
Note to self: when I do make a !postActiv theme thing, make sure that it works without Javascript to an at least minimum degree. Its annoying as piss browsing all these other instance where you cant even see shit but a blank page without it enabled.
Deleted ~1000 spam accounts from the !postActiv gitea instance, if yours was accidentally caught up in it, sorry. No one with a repo or commits was removed.
Providing information like MediaWiki's block list as to when, how long, and why someone was sandboxed or silenced, is something that would probably be quite helpful for !postActiv - even if an abusive admin will just not use it, or misuse it. It also provides a canary in the coal mine for those kinds of instances (you can see they're not really taking care with that) And for a properly-governed instance, it helps establish the fairness of these blocks.
Pushing a change to nightly !postActiv that adds a configuration variable to enable nodeinfo - it's disabled by default (making it opt-in, not opt-out)
Set config['nodeinfo'] = 'enabled' to opt into nodeinfo
I really do want to wrangle in proper templating for !postActiv but ots such a large project to disentangle all the hardcoded HTML from statusnet/GNU social
Going to try to put to rest the myriad niggling little problems and add a few convinence features to !postActiv before I get heavy into doing Disapora federation For Reals.
I think I have that federation down in a test environment save for a few strange edge cases that I can't reliably replicate, but those have me thinking it might fall apart spectacularly when I go to actually try it in production. We'll see I guess!
Is there a recommended way to block access to things like https://social.heckin.tech/INSTALL? I don't want to just delete them and it's all tracked in Git anyway so they will show back up when I pull. Think .htaccess is the best way?
Part of the problem, especially with ActivityPub, is that you have so many ways to display the same information that it becomes impossible to support everyone's different use cases and you have so many edge cases they tesselate together to become a nice little circle Bob Ross would be happy with.
I will probably dictate a specific format with specific endpoints for different things in !postActiv 's new API when I get there, but I'll have to think on what I think would be the most efficient thing in that regard.
I will also hasten to note the old API isn't going anywheres (but the new one is probably what will get development in the future)
I think what I'll do in !postActiv with regard to content warnings is have a default list of ones that are displayed below the fold (ie you need to expand them) that you can override at the instance level, (something like config.spoiler-words = "list of content warnings here") and then each individual user can further tailor it to their own wishes.