Comment on What are the activity_id formats for various platforms?

julian@activitypub.space ⁨5⁩ ⁨weeks⁩ ago

• julian@activitypub.space ⁨5⁩ ⁨weeks⁩ ago

  @admiralpatrick@lemmy.world 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/

  source

  • admiralpatrick@lemmy.world ⁨5⁩ ⁨weeks⁩ ago

    I think you would be better served by checking for the Link header

    Can’t really do that, client-side. 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. lemmy.world/modlog, 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.

    source

    • julian@activitypub.space ⁨5⁩ ⁨weeks⁩ ago

      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...

      source