

Very nice!
Ask me anything.
I also develop Tesseract UI
Very nice!
Unfortunately, there’s many many reasons that could be the case. I’m just putting this out there since it’s easy to check for and mitigate against.
No, that’s just /api/v3/user
which returns both posts and comments.
Good idea with the f2b integration.
I thought about that before just blocking unscoped requests to that endpoint in Nginx.
That was my thought, but also wasn’t sure since there might be a use-case I’m unfamiliar with. I vaguely recall seeing a feature request for Photon a while back to be able to just browse comments, so I assume that would be how it worked.
But yeah as it is now, it can be abused.
That’s my normal go-to, but more than once I’ve accidentally blocked locations that Let’s Encrypt uses for secondary validation, so I’ve had to be more precise with my firewall blocks
Lemmy. I added a comment above since LW wouldn’t let me edit the post.
Mine’s only extended with some WAF rules and I’ve got a massive laundry list of bot user agents that it blocks, but otherwise it’s pretty bog standard.
If instances have Anubis setup correctly (i.e. not in front of /api/...
) then that might not help them since this is calling the API endpoint.
Can’t edit the post (Thanks Cloudflare! /s) but additional info:
but I send you a PM
Oh, sorry. One of the new features in this dev branch is the ability to disable PMs and mentions. I’ve been running with those turned off. Seems like that feature is working lol.
I turned DMs back on and found the message - will try to join here when I’m back on desktop. Dunno how active I can be right now, but I am eventually going to start on Piefed so would be nice to have a sounding board.
Some of the devs are already working on shared logic/libraries between apps.
Nice!
Oh, I meant just if the instance isn’t know, I thought resolving would make it “aware” of that instance. I could be wrong. But yeah, the instance would have to federate with the other one for it to be able to resolve, though. e.g. it won’t resolve an object from an instance that is on the current instance’s “block” list.
I believe you can, yeah, and I also think that “bootstraps” that instance to yours if it doesn’t already know about it. But in that case, the way I have the search written, it’ll “fall back” to regular search which also does resolveObject
. That just takes longer.
The ap_id check is just to short-circuit that behavior to avoid the lengthy, often unnecessary, search and quickly redirect you to your instance’s local copy.
Have had that working for about a week now, and it’s pretty nice. Please do steal this feature lol.
At startup, it calls /api/v3/federated_instances
and stores the result to a lookup variable. Then I’ve got a couple of helper functions that accept either an instance ID or a domain name which looks them up from the lookup variable.
I think you would be better served by checking for the Link header
Can’t really do that, client-side, in a browser application. CORS is a perpetual cockblock (though I understand why it is), and I’d rather not make an internal API endpoint to do the lookup.
The application polls Lemmy’s getFederatedInstances
API endpoint at startup, so it has a list of every activity pub server your instance knows about. That’s the first and primary check for the URL that’s being searched.
The second check is just to rule out non activity pub URLs that point to a federated instance (e…g. https://lemmy.world/modlog, https://lemm.world/pictrs/image/blah.webp, etc).
Goal isn’t to “catch 'em all” but to catch the most used ones. If there’s one I don’t account for, either by omission or because the federated platform didn’t exist when I made the patterns, then it will just fall back to a regular search which also includes trying to resolve it as a federated URL (which is the current behavior in all prior versions).
The goal is just to simply short-circuit the search behavior if the query is a known ap_id URL in order to avoid a lengthy search process and quickly redirect you to your instance’s local copy.
I’m making an “omnisearch” box.
Paste in an AP_ID into the search field, and it auto-resolves it and redirects you to your instance’s local copy (which is very fast) instead of going through the whole search process (which is slow). To prevent false positives, I’m matching the various ap_id formats and only doing the resolution on those; anything else gets passed to search.
Anything else that falls through the cracks just gets passed to search as usual (which also does a resolveObject lookup).
It’s to make life easier.
We’ve had this discussion :)
This application is written against the Lemmy API. It only speaks API. Eventually it’ll speak Piefed API as well, but right now, only Lemmy API.
Lemmy and Piefed only do server-to-server Activity Pub and not client-to-server AP. Clients have to use the API to interact with them. This is a Lemmy (and eventually Piefed) client.
Cool, thanks. I was close with /user
guessing from memory.
I think the /users/.../post_id
will be sufficient. It just needs to know that the given URL is an AP_ID before passing it off to the API call to resolveObject
. Since it already knows instance.domain.tld
is a federated instance, it just needs to see if the path is an AP_ID or the HTML (or something else). Thus, I don’t have to parse the whole thing, just check that enough of it matches.
Thanks!
Thanks. I’ve largely been active here for development/testing purposes lately, but agreed. That’s also why I’ve put so much effort into expanding and making a very powerful/granular filtering system in this release. Right now, I can filter entire instances, entire platforms (e.g. Mastodon), people/instances/platforms in specific communities, filter users/communities by regex pattern, etc. Makes it nice to filter people out of specific communities without blocking them entirely.
Eh, I know I made a big stink about it (which I stand by lol), but technically Dubvee’s still online since I need it for developing/testing the admin and mod capabilities. It’s mothballed but still able to be brought back if I ever choose to and get some more admins on board.
You’re welcome! I actually support that guy on Patreon. He’s got almost the exact same taste in music as I do and covers them all in Spanish. It’s like hearing the music I grew up with for the first time all over again.
Seems like it. I was planning only on maintenance, but with the huge amount of work I’ve put into the current dev branch, I can’t really call it maintenance anymore.
Instance blocking is just blocking all communities on that instance, unfortunately.
Like Blaze said, you can try Piefed (LW also operates a Piefed instance) or you can use an alternate UI for Lemmy that does hide users from blocked instances. Not sure which do except Tesseract (https://t.lemmy.world/) since I wanted to be able to do the same thing.
The setting for that is under Settings -> Filtering -> Hide Users From Blocked Instances