TL;DR: Any of you who are more familiar with Fediverse platforms that aren’t Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I’ve rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I’m loving this as it makes things so much faster and easier.
To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that’s submitted to the search.
Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search.
For Lemmy and Piefed, those are:
/u/
for users/c/
for communities/post/
for posts/comment/
for comments.
For Mbin, I think it’s the same except it uses /m/
for communities (they call them “magazines” I believe).
I think mastoon uses /user
or maybe /username/
in the AP identifiers?
Any of you who are more familiar with Fediverse platforms that aren’t Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
Ahh that makes sense. I guess you couldn’t search anything your instance doesn’t federate with anyway.
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.
I believe it bootstraps the object, not the instance. You still won’t be able to find an object from an instance you don’t federate with.
This is based on an explanation from @MrKaplan@lemmy.world, unless I misunderstood MrKaplan?
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.
Sorry to bother you here, but I send you a PM. I would love to collaborate more. I have a group chat with the other Lemmy/PieFed devs. Some of the devs are already working on shared logic/libraries between apps. I also 100% understand if you’re spread too thin and don’t want more messages.
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.
Nice!
One of the libraries we talked about, though @aeharding@vger.social did all the work, is an abstraction built over lemmy-js-client that automatically adds PieFed support. I really think opening communication between everyone will unlock more opportunity for collaboration.
https://www.npmjs.com/package/threadiverse