ActivityPub

@locationforums That's correct. You would have to switch to the activitypub branch to take advantage of this functionality. While you can switch back to master or whatever v3.x code, the data store might have changed, and so going back to v3.x is untested.

Additional documentation regarding various Fediverse Enhancement Proposals (FEPs) has been added to the NodeBB documentation re: ActivityPub.

The following categories are now federating: NodeBB Blog (@blog) — I'm not sure why I only just federated this one now, it makes so much sense to! Technical Support (@support) Developer FAQ (@developer-faq)

@julian For FEP-ef61 you will likely need to refactor much more than ID generation. This can be done (@mikedev and I did it), and might even be worth the effort, because this FEP not only solves the problem you've described, but also takes ActivityPub to the whole new level.

For awhile I've been wondering what the slow-down was when I loaded /world, the curated timeline for a NodeBB user. Seemingly every time I figured out what it was, it would slow down again after some time. Today it was taking 3+ seconds to load just the data, whereas our other pages (category listing, topics, etc.) all finish in under 250ms, including html generation, user data, etc... Certainly something was amiss! As it turns out, asking your database to do an intersection of two data sets, one containing 23774 items, and the other containing 23606 items, is a little much. I guess this is what they mean when they talk about #webscale hah! (#fediscale?) Specifically, I was intersecting the set containing all fediverse topics, with the set containing everything in the user's inbox, in their entirety. While this gave me a very precise answer, there was a huge cost to that precision. After talking with @baris about this, we decided that sacrificing some level of precision would almost certainly go unnoticed. Instead of having the database intersect those two data sets, we would pull the most recent 500 entries from both and intersect them manually. So, /world is now limited to 500 topics. Don't worry, you won't notice. That simple fix brought the execution time down from ~1500ms to ~40ms, which is more in line with our expectations!

@[email protected] thanks for the kind words, appreciate it! I feel like we're almost in an exploratory phase of ActivityPub development, where we're still figuring out some best practices for some things. It'll only get better!

@julian Problem was not with underscore but with dot in threads username. Changing it to underscore solved the problem.

@julian @Fitik Still faster than a multi-billion dollar conglomerate. Congrats!

@julian said in Software version in nodeinfo: The other line of thinking is that relying on security by obscurity is fallacious, but since it's only one facet of a broader security posture (the rest of it being keeping up with updates, writing as secure code as you can, reporting/bounty systems, audits, etc.), I honestly don't see a problem with transmitting as little information as I can. The only thing in all of this that is relevant to the software operator (i.e. not nodebb developers but those using it as self-hosting) is tracking updates and applying them quickly, so I'm against exposing the version number in a way that would allow bots to easily identify which nodebb installations around the world are still vulnerable

Let's see if replies work.

@julian Yes, IDs should be unique:>All Objects in [ActivityStreams] should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient-- https://www.w3.org/TR/activitypub/#obj-id

@[email protected] said in Handling "410 Gone" when retrieving an actor: You could do what Reddit does and just leave the posts up but pointing to a tombstone user. If you've ever seen a post attributed to [deleted] then you know what I'm talking about. Yes, this makes sense. It's coming into clearer focus why account and content deletions are so noisy in ActivityPub, since each deletion of a user's content needs to be federated before the account can be deleted. In absence of anything more explicit (like your aforementioned DeleteAllCreatedObjects), that's all we have to explicitly signal full account and content deletion. I think we'll go ahead with that. NodeBB already does display something like [deleted] (we show "A Former User"), and we also save the old user id as a reference in case it needs to be cleaned up. That'll work, thank you for your input a!

@julian that's a good point. I feel it'd mostly be better for integration with Lemmy/Kbin type systems that mimic forums.

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

Of course you have a wiki page for this already! Why am I not surprised. Yes, that follow-accept has state synchronization responsibilities means that some additional specification would be nice, though as long as everybody tends to conform to the same behaviour I suppose thats less urgent. I still don't like that the current UX is "follow is in a pending state", but short of additional specification re: error handling, there's not much to do here. At any rate it seems I am now correctly following @[email protected] so I suppose maybe my server was slow at processing the accept.

[image: nathan-fillion-speechless.gif]

@[email protected] right. I think functionally I'll never encounter a Delete, check the origin, and find that the note hasn't actually been deleted, but stranger things have happened!

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.

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