For now, I can easily set a custom route, but its, well, "annoying" 🙂

Yes, thanks both. I was confused!

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.

@crazycells Thanks for the reminder. I'll take a look.

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.

I'm sorry, that's right, that's a period, not a comma... thanks for the answer Mr.@julian

@julian said in Blog comments on external blog website:

@crazycells yes, we currently use that plug-in for the blog comments in our blog

yes, but, it is on the same domain here... used as subdomain...
community.nodebb.org and nodebb.org/blog

can we use it on a completely different domain than our forum? such as blog.com and forum.com ?

@eeeee Sure. When NodeBB tries to load the values in config.json, it checks nconf value config first. You can send in config as an environment variable to point to the path of a different config file.

e.g. config=configA.json ./nodebb start

So you can have multiple configs in the same folder, and launch separate processes off of the same file structure.

If I run config=what.json ./nodebb dev on my local machine, it will launch the web installer, since what.json does not exist.

@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, sorry I'm new to NodeBB... can I buy this plugin (where?) and use it with the latest version of NodeBB?
Thanks 🙂

@[email protected] NodeBB now supplies context with every as:Note object, and is resolvable as an OrderedCollection.

One thing that is not currently done is what we talked about here, inheriting the authoritative context and serving that instead. I will need to think that through a bit more.

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 🙂

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

@루루

I use this one mongodb70-7.0.4 , no issue all perfect

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.

Cheers @[email protected] thanks for making it official.

@[email protected] hopefully you can subscribe to the recurring event now 🙂