Darkscribes Community

[email protected] oh god do I have to handle this too

[email protected] Chinese is clever in many ways!

The Cantonese word for ketchup both sounds like ketchup, and literally translated means "tomato sauce".

Depends on the project, and I imagine a lot of the smaller ones are your standard FOSS BDFL leadership.

In my case I'll likely make a rough milestone list based off our NLNet memorandum and go from there.

[email protected] it should, yes! The immediate fix was to change the logic so a 200 is sent, but a 429 should work quite well as Lemmy will likely send it back into the delivery queue and (more importantly) not mark it as an error.

[email protected] and what exactly does "non-archival" mean anyway? How long is content stored for?

In my case I had a spam protection measure that limited the amount of upvotes per user in one day. Someone on a Lemmy server uploaded past that threshold and NodeBB started sending back 500s.

[email protected] simple! Respond to a Lemmy server with a 500, and once you hit 40 in one day the instance puts you on a timeout. Repeat as needed until your backlog is 4M activities

Less than 3M activities behind now!

Better and better every day... Hoping we can get some additional funding to really accelerate development!

[email protected] it's less that and more Lemmy's ridiculously effective synchronization mechanic that Mastodon doesn't utilise!

> Ubuntu 8.10 Intrepid Ibex also had its namesake animal on the default wallpaper, but more subtle than the last release.

That was an Ibex? All this time I thought it was a coffee stain.

With the Lemmy developers' help, we figured it out! It was NodeBB's spam protection mechanism. One of our configurable options is to limit the number of upvotes one can make per day.

1. Someone (or someones) on Lemmy communities was sending lots of upvotes and running into this limitation when those activities were propagated to NodeBB.
2. NodeBB dutifully noted this and sent back an HTTP 500.
3. Lemmy dutifully noted this and retried sending the activity using an exponential backoff algorithm
4. Eventually enough 500s were recorded that Lemmy decided that our server needed a time-out of sorts

I updated the code to handle this case better, and now the activities are coming in at full speed. It'll take awhile to get back up to sync though

Kichae I ended up opening up an issue on the Lemmy repo and they pointed out that there hasn't been a loss of federation with Lemmy, but that something (likely on the NodeBB end) is throwing errors and causing Lemmy to defer sending activities until after some timeout.

https://github.com/LemmyNet/lemmy/issues/5722

phenomlab ah good to hear, thanks, and sorry about that!

We're not quite sure what happened with the eslint update that caused existing installs to complain so loudly.

phenomlab can you delete your package-lock.json and try again?

Rp1 that's a use case I am unfamiliar with. Unfortunately at this time I don't think session sharing plugin is able to utilise that cookie.

It's an interesting idea though! It'd basically replace the need for the session sharing plugin!

Rp1 the SSO plugin does not save a cookie. A login (either via local username/password or via SSO) will generate a cookie, but this isn't the cookie used by session-sharing.

I go into more detail in the session-sharing readme: https://github.com/julianlam/nodebb-plugin-session-sharing/

The shared cookie can last as long as you want it to last, or as short as you want.