Can you not call fetch() to do a HEAD call? Maybe I'm mistaken about it but it should be ok.

CORS is indeed a wrench that gets thrown in when you least expect it...

I maintain my own Lemmy client (Blorp), and this sounds like a cool idea. How do you get your known list of federated instances?

I currently have my own threadiverse crawler I wrote, but I disregard any Lemmy/PieFed instance with <20 monthly active users. That brings the list down to about 63 Lemmy instances and 7 PieFed. I wonder if that list is extensive enough to implement the resolve object mechanism you mentioned.

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.

It took me a minute to find, but it is detailed in evan@cosocial.ca's write up about HTTP Discovery of ActivityPub Objects.

This is probably exactly what you're looking for.

https://swicg.github.io/activitypub-html-discovery/

I think your current approach has merit but is limited. If you know the instance software by URL and can resolve it using path matching without the use of a pre-flight request, that's absolutely a better way forward. The downside is you have to know the URL patterns of every software. You'll never "catch 'em all"!

However, if that method fails, doing a pre-flight check to grab Link also works and is a viable way forward.

You can test against NodeBB users or posts.

admiralpatrick@lemmy.world I think you would be better served by checking for the Link header. NodeBB and WordPress do it, if that gives you some idea of implementation?

But then why do you worry about the ap_id patterns from other software?

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.