Speaking of being needlessly destructive with stupid bots, these duplicates of other user's posts don't even register as cross-posts anymore (due to image proxying).
It's straight-forward enough to do in back-end code, to just reject a query if parameters are missing, but I don't think there's a way to define a schema that then gets used to auto-generate the documentation and validate the requests. If the request isn't validated, then the back-end never sees it.
required is a simple boolean for each individual field - you can say every field is required, or no fields are required, but I haven't come across a way to say that at least one field is required.
PieFed has a similar API endpoint. It used to be scoped, but was changed at the request of app developers. It's how people browse sites by 'New Comments', and - for a GET request - it's not really possible to document and validate that an endpoint needs to have at least one of something (i.e. that none of 'post_id' or 'user_id' or 'community_id' or 'user_id' are individually required, but there needs to be one of them).
It's unlikely that these crawlers will discover PieFed's API, but I guess it's no surprise that they've moved on from basic HTML crawling to probing APIs. In the meantime, I've added some basic protection to the back-end for anonymous, unscoped requests to PieFed's endpoint.
This is the kind of thing that apps handle well - I viewed your post from Voyager, and just had to click the sopuli.xyz link to get is resolved to my instance.
For the web browser experience: that link used to be a bit more visible (you can currently also get it from community sidebars, but it used to also be in post sidebars too). Someone complained though, and it was removed from post sidebars, so I assume they'd have the same complaint if it was re-surfaced again. You could just bookmark it, of course.
The page itself shouldn't be slow to load (it's a very lightweight page that's not doing anything until you click 'Retrieve'). It doesn't immediately redirect you to the post because the assumption was that you might want to retrieve more than one post at a time.
That said, if you're already viewing a page on the 'wrong' instance, then being able to change 'https' to 'web+pf' and have it work sounds cool (although it looks like Chrome makes highlighting 'https' into a 2-click experience).
No, I was suggesting that peertube.wtf should have asked piefed.zip for the details of the comment. That would be the most authoritative place to ask, and that's what PieFed, MBIN, and Friendica do.
For the comment that you made, piefed.zip would've signed it with your private key, and sent out 2 copies - one to technics.de and one to tilvids.com. After receiving it, technics.de is no longer involved, but tilvids.com would've sent to comment out to all the subscribers of 'The Linux Experiment'. We can tell they did in fact do that, because the comment you made on piefed.zip is visible on piefed.social.
It doesn't have your private key though, and it additionally doesn't sign it with the channel's private key, so the question is then not 'was the data sent out?', but rather 'how do remote instances know to trust that this comment was actually made by this person?'. If the author was also on tilvids.com, then it has access to the private key, so it can be signed when it's sent out. If the author was from Mastodon, their comments include a cryptographic hash inside the JSON, so that can be used. For all other authors, the best thing to do - I would think - is grab it from the source.
I don't actually know what other PeerTube instances do in this circumstance though. Comparing the amount of comments on the host instance, vs. other PeerTube instances, vs. PieFed, reveals no discernible pattern. For 'The Linux Experiment', piefed.social has comments from misskey, from piefed, and from mbin that are absent from remote PeerTube instances. Hopefully, someone who's familiar with their code can shed more light on their internal federation - if there's something we can do to guarantee comment visibility on remote PeerTube instances, then we'll do it if it's feasible.
EDIT: just been digging through my server logs for requests of comments I made from PeerTube instances, and discovered tube.alphonso.fr - they have your comment: https://tube.alphonso.fr/w/eSYuduJSbZ9s7K4pFT3Ncd - so how fully PeerTube instances federate comments might be a policy decision that admins set, or it might just be buggy behaviour.
PeerTube's federation model is different from Lemmy's - they don't sign remote comments when they federate them out again, so it's often up to other instances to fetch them from the source. It might be that PieFed has to do something to help the likes of peertube.wtf successfully retrieve a comment when it's a reply to another reply.
Also, from what I can tell, they haven't been moved using PieFed's community migration facility (which squishes the old remote community into a new local one and retains the history (e.g. like what happened with like !casualconversation@piefed.social ). These are just brand new communities, starting from scratch.
I'll just remove the 'freamon' one when the auto-generated one is up to date.
The manually-generated one had 5 missing routes, which I've since added.
The auto-generated one at crust has about 48 missing routes. It's the right approach, and I'll help out with it when I can, but - for now at least - it makes no sense to redirect people to it (either automatically or via a comment).
/site/instance_chooser probably doesn't need to be a route. It's just the data format returned by /site/instance_chooser_search. As a route, it's returning the instance info for the site you're querying, so if you want to keep it as a route, it should probably be called /site/instance_info or something.
In the query for /site/instance_chooser_search, nsfw and newbie are both booleans. With the rest of the API, these are sent as 'true' or 'false', but they are 'yes' and 'no' for this route.
The newbie query should probably be newbie_friendly
In the response, monthsmonitored should probably be months_monitored
There's no way to exclude communities for the response to /topic/list and /feed/list: If you don't put 'include_communities' in the query, it's defaults to True, but if you put 'include_communities=false' in the query it ends up being True also (because the word 'include_communities' is in the data).
But the fact that both me and you are using PieFed instances and are participating in a comment chain started by a hexbear user demonstrates that there isn't much 'hard-coding' against other sites.
The commit that @davel@lemmy.ml referenced is for initial database setup. It's not an unreasonable default list to populate the 'banned_instances' table, and is trivial for admins to change after setup is complete.
I watched Jurassic World: Rebirth the other day (it's alright). It's such an odd franchise - one that seems to have lost faith in its own premise. There's this meta assumption that audiences are bored with dinosaurs (I'm not), and that the solution to this imagined problem is to mutate them (it really isn't, it's invariably just silly).
I also don't care that dinos couldn't really survive in the modern climate - that's what the whole 'suspension of disbelief' thing is for.
afaik Andrew approves new registrations but mostly does coding?
You originally added me so I could debug stuff based on the status incoming activities, which isn't really relevant anymore.
That isn't my primary account atm, so I don't really do any other admin stuff. That said, it might be an idea to keep some permissions in place for that account, so I can help out in case there's a spam wave when it's night time in NZ or something.
Am trying the app now. Nice to see that the crosspost opens the local version of it (instead of taking you away to the remote version like the web site does).
Speaking of being needlessly destructive with stupid bots, these duplicates of other user's posts don't even register as cross-posts anymore (due to image proxying).