thisismissem@hachyderm.io oh god do I have to handle this too

stefan@stefanbohacek.online Chinese is clever in many ways!

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

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.

Rp1 session sharing does not share any commonalities with SSO. Consider them separate items completely.

If you want them to work together, your best bet is to ensure that when your users register via your SSO IdP, that the user info endpoint provides both an id (that should be required anyhow), and an email.

The email is how you will “find” the correct local account.

When you save the shared cookie (with hostname .example.com), save the id and email in the jwt, and session sharing will use it to try and match a user. First run it won’t find the id, but will match an email and store the id:uid reference for the next time.

malte@forum.fedi.dk sort of. Mastodon from a design standpoint doesn’t want to implement inline images, and I understand their point of view. The point of the Note preview is to provide an alternative format that Mastodon can better understand.

Rp1 couple things here…

If you want to enable SSO via your own IdP, use nodebb-plugin-sso-oauth2-multiple. That will allow you to configure a client without having to actually code… ideally.

If you want to have an auth cookie shared between subdomains, use nodebb-plugin-session-sharing.

malte@forum.fedi.dk one other thing.

There are some shifting specifications related to how long-form text is handled. Specifically, NodeBB is on-track to follow FEP b2b8: Long-form Text.

Part of that means that topic OPs are federated out as Articles without inline images convertd into attachments, because they are technically not attachments. This means right now Mastodon will not show the media at all.

Mastodon will implement this FEP eventually, which means it will properly handle the attached Note preview, which does contain the attachments.

NodeBB can better handle the images coming from other NodeBBs, though. That’s a bug.

Here’s the post here: https://community.nodebb.org/post/https%3A%2F%2Fforum.fedi.dk%2Fpost%2F1436

Seems the images don’t load due to cross browser security settings

ScrapBlox hi, sorry about the delay. Sometimes it’s hard to think of what to debug next.

Can you screen shot the settings on both sides? Feel free to blur out the client id and secret

arachnibot@nodebb.arachnibot.com did you update NodeBB 9 days ago?

Confirming that follow-unfollow-follow-unfollow logic is working as expected against ani.social which means the plumbing actually works.

Kichae I suppose it’s worth rolling back to 4.3 and figuring out what the change was…! I just wish testing federation wasn’t such a long process.

After more debugging today I am less convinced that this is a NodeBB issue.

I am finding Lemmy communities where federation continues without issue, and others where there is no activity at all.

The sequence of events is:

1. NodeBB sends out a Follow
2. Lemmy responds with a 200 or equivalent
3. Lemmy later sends me an Accept
4. Lemmy later sends content (posts, upvotes, etc.)

startrek.website and ani.social both do everything ok.

lemmy.world and mander.xyz fail at step 3, and existing connections (where step 3 completed in the past) do not execute step 4. I literally am not seeing anything besides Like activities coming from those servers.

Existing PieFed and NodeBB integrations continue to work without issue.