Skip to content
  • 0 Votes
    6 Posts
    76 Views
    julian@community.nodebb.orgJ
    @BeAware@social.beaware.live The other part of it is... unlike Mastodon, we're not looking for NodeBB to become the app to use to interact with the fediverse. It's certainly something I want out of my use of NodeBB, but what forums are great for are cultivating niche communities based on shared interest. If I'm able to preserve that aspect all while allowing remote content to also interact with the forum, then it's win-win.
  • 0 Votes
    2 Posts
    43 Views
    julian@community.nodebb.orgJ
    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.