Finally, you are now able to look up remote content and user profiles using the built-in NodeBB search tooling.
In the quick search bar and on the search page itself, you can paste in a URL to a post. If NodeBB can fetch it using the ActivityPub protocol, then it will be immediately parsed and returned as a search result:
If you change the search type to "In users", or use the search bar in the users page, then you can look up remote users using their URL or handle:
This change resolves the final hurdle stopping a brand new NodeBB from connecting to the fediverse. It wasn't possible to actually find anyone or anything in order to start those first follow relationships. Now it is possible.
Aside — I'm frankly surprised by how long it's taken for me to actually do this. It goes to show you just how much you'll put off doing something if it's not really critical.
2 Likes
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.