There’s no real reason to. Your own instance (in this case, lemmy.world) has the real view of the thread by the virtue of being the instance starting the thread. lemmy.ml only has it’s own copy of this thread that’s likely reasonably accurate (compared to any other random instance out there, considering it hosts the community), but it’s not the original version, which is what the fediverse link points to.
The Pleroma family of ActivityPub servers are on Elixir and their bottleneck seems to be their awful database schema where everything is JSONB, and even then they’re known to be quite lightweight, so I assume with a proper DB schema it’d work quite well…
while i don’t have any specific opinions about this that other people haven’t addressed, i just want to flag up something;
How this could be enforced? No voting from the All and/or Local feed. Seems easy and straight forward.
this seems unenforcable. as in, you can’t really tell where someone discovered a post from. yeah you can just remove the buttons from those views clientside and it’ll probably work for the majority of cases, but alternate clients or modifications to lemmy-ui can simply put the buttons back in (or in cases of unmaintained or differently opinionated clients, just not remove the buttons at all). the backend can’t really differentiate which view a vote comes from. federation especially can’t differentiate which view a vote comes from.
I would absolutely boost this to the microblog-verse if Lemmy federation with Misskey wasn’t broken
epic megapost 
nah, there are plenty of truth wannabes (freeze peach bigotry safe havens) that actively federate. just look at literally any competent server’s blocked instances list and you’ll see a few examples. there’s a reason why nobody* runs completely open federation
*: aside from people who’re friendly with that crowd ofc
What I’m more worried about are posts relating to news mainly. Where even if the immediate first level comments are fine, there are threads that get out of hand really quickly.
I agree that while posts inherently designed to be controversial may not benefit from Active considering the influences voting has (though me being on an instance that has downvotes disabled may be influencing my view here!), Active may make it significantly easier for an otherwise innocent post to devolve into a flame war.
The main excuse for this kind of algorithm seems to be around “promoting discussion”, but in my experience tech that’s intended to promote discussion does inherently promote flame wars too, as they’re extremely difficult if not impossible to distinguish without a human in the loop. I’ve attempted to write something about this on the microblogging side of the fedi, directly influenced by this post
I’m just throwing this out there but having the default sort incentivize comments seems like it’d highlight posts meant to cause flame wars… Is that what we want out of this platform?
(talking about microblog fedi here, Lemmy/threadiverse is it’s own thing)
don’t do hashtags. hashtags (especially common ones like #memes) are overrun by repost bots and low quality garbage.
the trick is to be on a small-to-medium instance you vibe with (1k active users seems to be the sweet spot. anything larger than 2k I’d avoid. do NOT join any flagship instances like mastodon.social), follow fun people from your local timeline, and see who they boost. and follow up the boost chain until your timeline is sufficiently fun.
I wish I was in the us lol
sure let me just walk to a better country
hey wait why are there people with guns around me
the little eye in the top right corner can be used to toggle all of them in one go. this is such a massive qol improvement it’s genuinely baffling how mastodon and the 2 misskey forks I implemented it in are the only fedi software that have that button
I’m not entirely sure if such an instance exists, but just letting you know that in case you can’t find any, a reasonable compromise would be to join an instance that’s enforcing authorized fetch (and is blocking threads)
this will make it harder for facebook to read your data through federation alone (i.e. even if a post of yours get boosted by someone with followers from threads, it won’t “leak” there)
there are ways to bypass this of course but if facebook is found to do something of that sort they would out themselves as actively malicious which would definitely get a reaction even from the “wait and see” crew
so, are you paying for it?
git commit -m $(date)
I’m mildly worried I know (as in, am aware of their existence, thankfully not having interacted with them) who you’re talking about
over the years of using matrix i’ve become convinced that the people behind it simply have different priorities than people who actually want to use it. they’re mainly interested in the tech parts as opposed to making communication tools.
if you look at the “hype” behind matrix, it’s all about “the protocol”. federation, p2p “host a homeserver on each client”, encryption, bridging, complex state resolution algorithms, peppered with some vague marketing crap about owning your own data. nerd shit or, in the best case scenario, pipe dreams of a magic future that could come with all this flexible tech we’re building
notice how there’s nothing about actual communities. little to any discussion on moderation tooling, or ease of use. it’s all tech. they only care about the tech. the communities? uh well they’ll happen somehow
“matrix chat” is just a tech demo of the matrix protocol the same way https://github.com/matrix-org/thirdroom or that fucked up twitter clone they were building at one point is.
this turned into a bit of a rant but the people working on matrix need to have a deep inner look and explicitly work out if they want to work on “cool tech” or work on tools for building communities. also stop working on so many useless side projects and focus on making one thing that works.
i’m pretty excited for fedify since i’m unsure if there has been any other activitypub abstraction that feels as comprehensive as it seems right now (from a brief skim, anyway).
one thing i had in mind ever since i first skimmed the docs some time ago is this:
i would really recommend you to NOT tell people to use handles here. i assume this is just naming and the framework doesn’t actually require a handle there, but documentation matters and if you follow on the footsteps of mastodon, pleroma, lemmy, and friends everyone who follows your docs will lose the ability to change usernames down the line without more pain than it’s worth (and yes, there are software out there that allow it right now! please do not build fedi software assuming usernames are immutable jsut because mastodon doesn’t let people do it)
just like how you wouldn’t use a natural key in a database, you should tell people to use a surrogate key like an autoincrement id or a uuid on the actor IDs, as they’re effectively permanent. while it may be probably fine for a quickstart thing like this to omit that, a lot of permanent codebases do start up by following these kinds of guides, and nudging people to do the correct thing when it’s not that hard is always a good idea IMO