Thats how FEP-1b12 works, its necessary if you want to federate activities such as voting, deletions or mod actions and not only post creations. But Lemmy doesnt support arbitrarily wrapped activities, only specific hardcoded ones like Announce/Create/Note, Announce/Like or Announce/Delete.

This user story deals with expected behaviour when encountering a topic/context/first-order collection.

Perhaps it is discovered when declared as the context for an Object. The collection can then be used as the canonical source for content for that context, and it's members queued for asynchronous processing.

A scaling issue exists here in that a collection could be massive and cause an undue delay in processing a new Note if every other member of the collection needs to be processed first. Implementors should take care to not require the full context during processing of an Object.

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] 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!

Yeah, I agree with you on both points. It’s similarly inexpensive to make 20 requests in Discourse (it’s in a background process on a seperate thread). On reflection I think part of my conservatism here is that I don’t like that Mastodon doesn’t forward activities properly and I don’t like starting from a position that I need to import 20 notes that Mastodon failed to forward to me It causes similar metadata issues in Discourse.

There's are other reasons to have two separate NodeBB installs:

you may want to run different sets of plugins uploaded files are stored within the NodeBB directory, best to keep those separate plugins like emoji and customize store files specific to a certain forum, and all plugin files are within the NodeBB folder

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

@clover try changing your hook function to edit postData in place and return it directly, rather than creating a new object.

@julian said in Blog comments on external blog website:

@crazycells ah sorry, I didn't respond because I wasn't sure...

But I think it should be fine. Technically according to browser security policy, nodebb.org and community.nodebb.org are essentially different sites.

So if you used a different domain the same restrictions apply, but the plugin should still work.

Thank you very much, we will try it and report the outcome then...

So is this something that's possible and should I be looking at developing a plugin?

@phenomlab that doesn't sound like out of the box behaviour... can you reset all plugins and see if it reproduces?

Yes, thanks both. I was confused!

Thanks a lot I will try this and see how it goes.

Thanks for the feedback will definitely try the SES method instead.

My mailbox definitely has no sent mails from NodeBB. So I may have set it up incorrectly or SendMail really is problematic.

@Nuran-Akimbek You are chasing solutions without knowing the reason for the problem.

Listen to what @baris asked of you here: https://community.nodebb.org/post/99346

Fix what is causing your server restarts, and you will fix your problem. You don't have to do something like migrate to Postgres.

Hi all,
Well this is my first time writing a plugin which involves using client side hooks...
For a start, i would want my plugin to listen to a hook which activates when the topic page is completely loaded and topic tools are loaded too.

For which I wrote this function:

'use strict'; /* globals document, $ */ $(document).ready(function () { function alertType(type, message) { require(['alerts'], function (alerts) { alerts[type](message); }); } console.log('nodebb-plugin-quickstart: loaded'); $(window).on('action:topic.loaded', notifyBox); function notifyBox() { console.log("in notify box"); alertType('success', "done") } });

but this is not working... I can only see "nodebb-plugin-quickstart: loaded" on the console.

Where am i going wrong here??

Hey,
I use nodebb-plugin-session-sharing to automatically login users from my WebApp.
This works great on desktop!

But when I add the cookie to WebView of my React Native app i get:

Encountered an error loading page code: -1007 description: "too many HTTP redirects" didFailProvisionalNavigation: true domain: "NSURLErrorDomain"

I inject the cookie by calling

<WebView source={{ uri: domain, headers: { Cookie: `${tokenName}=${token};Domain=${tokenDomain};HttpOnly;`}, } } />

When I remove the cookie from the header and reload the app on Simulator, I'm logged in, so the cookie and the plugin mechanism is basically working.

React Native WebView reference
nodebb-plugin-session-sharing on Github

Anyone an idea about this?

Kind regards
Niklas

Hey @[email protected], how can I add events to the SWICG calendar? I notice there's a little button to include "Task Forces" in the listing, so I think listing our meetings would be helpful, now that we've settled on a more consistent time/day-of-week.

cc @[email protected] (unrelatedly, do you get notified if I mention your SocialHub handle?)