As @ptz@dubvee.org said, just disable it. There’s very little benefit and huge (financial) dowbside.

Yeah storage is cheap, but S3 cache costs are also like the #1 thing people hosting Mastodon complain about.

If you’re privacy conscious and worry about IP leakage… then install a camo proxy. Done. That also solves the CORS issues.

I think there’s definitely an underserved space for academics on the fediverse.

Feed-based mechanics are not good for archival or slower (read: not always online) readers, so NodeBB actually works really well to collect that stuff and present it in less of a firehose-y format.

For example, here’s a NodeBB forum that follows the #medicine tag: https://postcall.pub/

Here on ActivityPub.Space the discussion is all ActivityPub focused and it is really really good at keeping up to date with the latest topics.

I’d be happy to work with you to start a general science (or more topic-focused) board if you’re interested…

The PixelFed kickstarter was actual money delivered to a bank account. I don’t know how much more incentive one needs.

I will try hard not to speak ill of a fellow Canuck however.

Good on you Rimu. If NodeBB implements Activity Intents it’ll be because of you.

@ptz@dubvee.org another idea, use client side js to randomly select 5-10 p or span elements and inject a single RTL Override character in the text.

@hendrik@palaver.p3x.de fwiw NodeBB ended up being such a joy to author things in that we switched away from WordPress to NodeBB as our blog. We just blog on our forum.

Now, conflicts of interest are important… I wrote NodeBB, so I am obviously pretty biased :laughing: !

I’ll give some insight from NodeBB.

Adding in delays (x days until first post, y hours until upvote, etc.) do nothing to curb spam.

If your spam is manual, they will discover the waiting period, update their rulebook, and go to town when the waiting period is over.

If the spam is automated, it will work until the spammer admin discovers the waiting period, updates the script, and has the bots resume going to town when the waiting period is over.

At the same time it severly hampers usability at its most crucial (the first post).

The only thing that works to curb spam is a post queue with manual review… or locking the ability to post links behind reputation.

Web apps: modal opening on top of another modal

KDE: “Hold my beer”

Except it’s completely gated behind Discord corporate servers, unsearchable outside of Discord, and all ownership lies with… you guessed it, Discord.

But oooh aah Nitro…

Drop the “Fediverse” verbiage, or even “federated”.

You may be speaking to potential instance admins but only those familiar with AP know what federation means. Otherwise it’s a term with no meaning.

Ironically, even “Lemmyverse” means more than “Fediverse”, so “linked together through the Lemmyverse” actually works better.

Discord has both private and public channels. I won’t bother considering their threaded discussion offerings, because they’re absolutely horrendous.

ActivityPub is primarily public. You have scoped visibility that enables things like private messaging, but there is no implementation that allows for federated private group discussions.

There are proposals and a few implementations, but they all rely on everybody else to implement the same proposal, otherwise messages leak out, and that defeats the entire assumption of the private group.

It’s not an unsolvable problem, merely one that hasn’t been successfully solved yet.

As for whether AP is a good fit… It’ll work. At the end of the day you’re exchanging messages. Whether they’re long form or chat messages makes little difference.

Oh I see. Yes, AP first apps would be great, but getting older apps connected via AP is important too.

NodeBB predates ActivityPub (or came around the same time), and so we added it recently. It works quite well with our existing code. Not much of a compatibility layer.

What is this proprietary layer you speak of?

This is something I believe the ActivityPub API can tackle…

To my knowledge, one must be an “invited expert” in order to join these discussions.

However, the working group is only one aspect. The community group has been in existence for a number of years. I am part of that group (although I admit I don’t go to as many meetings as I ought to), and try to represent the threadiverse as best as I can.

Nope, it’s just a.single route, no filters or qualifiers I am aware of.

One could go through the returned accounts and see which are users and which are groups, although that’s expensive and time consuming to do.

By the time it (unique handles between users and categories) was needed, NodeBB had been around for 10 years and installed in countless places.

It needed to be done in one fell swoop so we coded an upgrade script that prioritized the user slug (as historically it had been around longer).

Hopefully the only thing you really have to federate out is an Update, but who knows what’ll happen.

Agreed… I didn’t respond right away since I wasn’t sure if I was right, but there are two constraints at play here:

• Lemmy wants to allow communities to be named the same as a user
• This is not allowed in webfinger (insomuch that multiple IDs reports should refer to the same entity)

You can fault Mastodon for not handling it, but I think the onus is on Lemmy to adjust their behaviour.

For reference, the same constraint happened with NodeBB. When we started, categories didn’t have handles and were not unique with users (so, a category could be named the same as a user). I needed to make the handle unique between both categories and users, for this exact reason.

lemmy.ml is different from voyager.lemmy.ml. The latter is just a testing instance.

Thanks for sharing, that’s quite exciting. I’m assuming BlueSky users can post to Lemmy instances (like other threadiverse) instances by mentioning the group actor?