NodeBB-ActivityPub Bridge Test Instance

Test mention to @devnull@crag.social mhmm

@Kichae Ideally, people should be notified that they are posting to a forum and not replying to a post on an individual channel, that way we can set some expectations in advance.I am not sure how ActivityPub handles it, but Hubzilla somehow communicates with other Hubzilla instances that a particular channel is a forum. It's probably communicated in webfinger, or something like that. Just having an icon, tag, or Bootstrap-style badge next to a channel saying "forum" would be helpful.

@devnull-crag-social oh right, sorry I have to respond to you directly for that to happen heh

Here's a good answer

Test post please don't boost

Here's another reply with hackernews linked, but also another link on its own line: https://slashdot.org/

A local reply goes here

Some italicised text

test......

Here's a reply, does it federate through?

"Suggested Topics" can i know this plugin or widget?

@omega Right now in pages where there is a list of topics (e.g. /recent, /popular, etc.) there's a filter for "Uncategorized", which would essentially exclude everything else. It's not as clear cut as excluding or only showing local topics, but that sort of achieves what you want. If you only want to see categorized topics, then you needn't select anything at all. By default, uncategorized topics are not shown. What I think you're advocating for is a button to filter out ActivityPub topics even if they're categorized. That's where I think I might draw the line, because if a topic is categorized, then it is by that action it is considered (at least by the topic mover) to be related to the overall forum topic.

@julian Here's a response from Mastodon

Here is a freshly hatched

https://x.com/historyinmemes/status/1814077691353579903

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.