If instances are unmaintained, losing them is probably a good thing.

Lemmy should do something like make captcha and email verification the default in the next version, and reject federation from anyone with a lower version. If we accept federation from any instance where this was never turned on, banning accounts one by one is worse than Sisyphean. They’ll just keep finding more vulnerable instances that are already trusted and abuse them to spam the rest of the fediverse.

If admins want to manually turn it off, then they should be prepared to manage that.

It doesn’t need to exist at all. But being online and continuous obviously speeds communication.

All fields need an information sharing platform. Historically, it was in person at conferences or conventions and such. Now it’s online and continuous.

True, but that’s why I mentioned a cache or cooldown. Once every two minutes is plenty, unless Lemmy really blows up and we have hundreds of instances trying to fetch a very popular post.

You have a point about new sort, but you could approximate it by sorting what’s known to an instance. It’s not ideal, but it’s at least something. Maybe it would make sense to push just that feed, or to fetch a subset periodically.

I read that comment tree, but it doesn’t answer my question. If someone on Mastodon likes a post on feddit.dk, I don’t see any reason feddit.dk can’t communicate that to lemm.ee when I go look at it.

Pulling the data when a user requests a post/comment (with a cooldown/cache for popular posts) isn’t any more or less scalable than feddit.de pushing the same data whether it’s been requested or not. If anything, I’d think pushing data when it’s not necessarily needed would be less scalable.

But if it has to be a push model, why doesn’t feddit.dk push the votes it knows about along with the rest of the data?

Sorry, I mean when I view the comment via my instance. I don’t understand why my instance needs to receive the votes/likes directly, instead of my instance fetching them from feddit.dk when I request the comment.

Yes, I’m definitely not understanding something. You said that Mastodon only sends upvotes to the instance of the user receiving the like, in this case feddit.dk, right? Then why, if I view the post on feddit.dk, does it not show me those likes/votes? What is dependent on my instance?

I don’t understand why feddit.dk doesn’t display upvotes received from Mastodon users. Why is this dependent on my instance?

Deduplicate by IP/user-agent and you’ll get a pretty accurate count. Some people might be moving between wifi and data, but for the most part you can account for that. Same process as fingerprinting a browser.

Not really. They’re making requests, probably at least once a day. That makes it very easy to count active users. With subscribers, you can have a big number, but they’re not necessarily all active, and unless they’re on your instance, you can’t see how often they’re reading.

You missed the beans thing, then.

Wordpress is all of those except lightweight, though I wouldn’t really say it’s a bear to manage either. I believe they have initial activitypub support as well.

You can check the selfhosted list for alternatives, but I don’t think I’ve seen one that would be a better fit.

Depends on what exactly you want to host. If you want commercially-hosted stuff, I’d stick with wordpress or whatever your host offers, but if you’re selfhosting I’d look in !selfhosted@lemmy.world or https://github.com/awesome-selfhosted/awesome-selfhosted?tab=readme-ov-file#blogging-platforms.

It’s an Egyptian cat.

I disagree. Communities suffer when noise outweighs signal.

You know how people will repost screenshots of tweets or whatever? The other day I saw a screenshot of a Mastodon post on Instagram.

What is this, reddit? No thank you.

If you want it that badly, implement it and send a pull request, or maintain a fork.

Yes, a fake instance can spam votes over federation. But usually it’s pretty obvious and easy to block.

Look mom, I’m famous!