@[email protected] 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.

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…

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.

Sounds like Rakuten actually…

> If it’s some automated feature, I don’t think it should be in the source property of the federated JSON in the first place.

Thanks, it’s this.

Edit: oh interesting, I looked into it. We serve the absolute URL in HTML but not in markdown. I had no idea threadiverse apps read the markdown. Neat!

@[email protected] said in [Fediverse wide cross-instance / cross-platform link substitution [UX improvement thoughts]](/post/https%3A%2F%2Fpiefed.social%2Fc%2Ffediverse%2Fp%2F1568622%2Ffediverse-wide-cross-instance-cross-platform-link-substitution-ux-improvement-thoughts): > This issue is unresolved in Lemmy, but the Lemmy brand is permanently tainted among users who are looking for alternatives to American oligarchic technology services. The low moral standards of the Lemmy devs’ (support for the brutal North Korean regime, promotion of russian propaganda narratives that they know are false) is a massive turn off for the exact target market of the Fediverse. It’s a fact that many Europeans looking for alternatives instinctively recognize the demagoguery of the Lemmy devs and their fans.

I don’t think this is true at all.

The average user doesn’t know what Lemmy is, let alone the political views of their core development team.

But don’t worry, it’s like that joke about vegans:

How do you know the Lemmy devs are politically dubious? Don’t worry, someone on the threadiverse will tell you.

NodeBB supports ActivityPub out of the box (no plugins) as of v4 🙂

Indeed, this is where the majority of improvements to the Fediverse are shared for archival.

The very way Lemmy Piefed Mbin and NodeBB can communicate and synchronize communities is detailed in those FEPs. Check out FEP 1b12.

Well that is weird, why did the link get confuzzled…

Response from Dan

https://mastodon.social/[dansup](https://activitypub.space/user/dansup)/115678527443322224

If you’re talking protocols, then why is WordPress there?

If you include Wordpress there are about 100 other softwares that should also show up, but then you also need more paper 😁