NodeBB-ActivityPub Bridge Test Instance

Technical stuff ahead ... This is merely exposing the frontend UI to the already established backend logic. We have two methods internally that are used for this: Notes.assert, which when given a object url or id, parses it and attempts to resolve the parent chain all the way to the top-level post. It then creates a topic to house all of those posts. Actors.assert, which when given an object url, id, or handle, creates a local representation of the user. How come "query"/etc. didn't show up? For both user and post searching, if the passed-in url does not resolve or does not resolve to a processable object, then we do not proceed. It's important to realize that while in an ideal world, we'd all be passing immutable identifiers everywhere, the real world is just a bit messier. Search queries could be a post or user URL, or a webfinger handle, so additional logic was required to handle those use cases. Most ActivityPub-enabled software I've encountered handle these vanity URLs when queried via ActivityPub — it returns the appropriate representation for processing. Some do not, and so in those cases, those items will not show up in the search results.

@julian to clarify: this is mostly about "canonical" identifiers vs. aliases. there is generally one canonical identifier for the conversation collection, and this is what should be used as the value of `context`. this could get a bit complicated but there are potential ways to coordinate replication between equivalent conversation collections, probably involving mutual following/follower relationship, plus some indicator of aliases like `alsoKnownAs` or some other extension property.

@julian Ooo good point about adding the ? back on.If you're interested in a non-regex solution, here's what I have - https://codeberg.org/rimu/pyfedi/src/branch/main/app/utils.py#L247

@pfefferle@mastodon.social it was actually because of @ in actor IDs - the codepath for choosing a webfinger lookup over just accepting the URL as the ID only checked for its presence, and the code for webfinger lookups was only meant to run for the acct: protocol. So yeah, not WP fault at all, just a combination of a bug and missing feature Now both should be fixed.

@julianFor example, let's say I link out to Evan's profile here. If NodeBB knew that this link had an alternative AP endpoint, then we could redirect the user instead to the local representation of his profileWouldn't Evan's AP endpoint be the same as his HTML endpoint? Most platforms are going to send you to the authoritative profile, which is the one at the user's server.And if you wanted to redirect a link to a local profile instead of his official profile, you don't need an endpoint to do that. You could simply parse the post and swap out the URL, since you should have data about the user in your database anyway from when you first detected the user.Maybe I am misunderstanding the use case here, but I am not sure why a platform would not direct you to its own platform for content and profiles.