ActivityPub

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.

As of today, the NodeBB-ActivityPub implementation now supplies both context and audience properties with every post.

N.B. When I say context and audience, these are also terms used by the ForumWG that refer to "topic" and "category", in NodeBB parlance.

Early indications from the last ForumWG meeting indicate movement towards the inclusion of context in a low-level as:Note object (a federated NodeBB post), resolvable as an as:Collection or as:OrderedCollection. The latter is what NodeBB will send, ordered by post time.

Discussions with @[email protected] also suggest that Discourse has the ability to parse an as:OrderedCollection context if provided, but currently does not if encountered as a property in a Note.

A minor change today also updates the audience property, which used to erroneously point to the context/topic, but now points to the audience/category. This change aligns usage of this property with FEP-1b12's expectations.

This change should allow other implementors to:

automatically group objects together given a the provided context, and more thoroughly backfill a given object's context, without relying on inReplyTo traversal

@[email protected] @[email protected], @oplik0 and I took a closer look today and found the one place where IDs were not sent with Announce activities.

Let me know if you find any other oddities 🙂

@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

@[email protected] 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.

@julian

For 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 profile

Wouldn'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 send you to a different platform to view the profile or channel.

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

@trwnh @julian @angus @nutomic groups can have subgroups

Ah it looks like this was covered by Angus' post over on SocialHub

@nhl.pl That's correct! That would be the GitHub repo for the new Social Web Incubator Community Group Forums and Threaded Discussions Task Force (what a mouthful!)

We're still figuring out governance and how to conduct discussions, but that's potential way.

AT Protocol by Bluesky offers Portable accounts (Change hosts without losing your content, your follows, or your identity) so it will end up in exporting profile at /user/yourusername/consent and using it elsewhere.

@trwnh context is a wonderful thing 😉

@crazycells I do not like repeated logic, as it adds maintenance burden. I will be removing it regardless 🙂

@[email protected] Yes, I think that's what @oplik0 and I ended up agreeing on. If we normalize all incoming requests so that any requests containing a full object on a different domain is just reduced down to its id, then you'd safeguard yourself from most edge cases. Applying FEP-8b32 would be handy to save yourself a few network calls but is optional.

The cost is you might have to make a couple extra calls, but it's probably worth it in order to keep the logic simple, predictable, and easily auditable.

A small quality-of-life update I just pushed to NodeBB will now allow you to view the content posted by non-local users.

When discovering new users and determining whether to follow them, their post history is rather important!

You can view post history for a remote user just as with a regular user: Profile > Posts

359b6584-606f-4afa-9964-b6f314814522-image.png

@eeeee

Updated, it eventually does show on Mastodon

Yes, as to when it shows up on the other site is dependent on a variety of factors, some sites are quite busy and they take awhile to process their queue/backlog of activities.

@[email protected] oof, sorry about that! I keep thinking "hey, nobody sends me DMs, so maybe I can just punt this down the line a bit", but then it seems I've already missed two, and those are the two that bothered to tell me...

So I guess that's going up in priority.

Happy to chat once we get more of the basic stuff locked down. Interfacing with something for T&S is pretty high on our list too.

Thanks @crazycells . I I'm pretty sure it will become important to do that sooner or later.
probably sooner

@julian digesting this. The potential is every bit as exciting as I thought it would be 6 months ago. I feel like my life has come full circle. I have always been a fan of forums, and always felt they were completely underdeveloped. It’s like everybody cloned the phpbb model and that was as far as it ever went. You’re reawakening a real beast potential.