![](https://lemmy.blahaj.zone/pictrs/image/PG5vaKqMsg.webp)
![](https://lemmy.world/pictrs/image/eb9cfeb5-4eb5-4b1b-a75c-8d9e04c3f856.png)
small correction: the post that displays the instance you’re on (https://void.rehab/notes/9umvfd1lgoulvm0j) won’t work with “'regular” iceshrimp. it depends on an extra patch added to the version on void.rehab to function.
small correction: the post that displays the instance you’re on (https://void.rehab/notes/9umvfd1lgoulvm0j) won’t work with “'regular” iceshrimp. it depends on an extra patch added to the version on void.rehab to function.
After seeing a team of fedi software developers drop their Matrix bridge to their Discord after the total lack of moderation tooling resulted in an extremely transphobic spam wave, I for one am not surprised.
Another team I’m aware of also dropped Matrix for other reasons, but went for Zulip instead, which is also open, but more collaboration oriented a la Slack rather than community oriented like Discord, which probably would not fit what the group in the OP is looking for.
Lemmy’s cross posts are separate posts that just happen to link to the same thing. so only replies to the original post would be sent with the current design.
that said, i severely doubt Lemmy will gain anything from this. publishers will not be sending out their posts to any communities, and i highly doubt they will expose any fep-1b12 group actors you can subscribe as a community.
kbin/mbin with it’s ability to follow users may work better, assuming people test their federation with software other than mastodon, and accept any of the interoperability bugs as actual bugs instead of ignoring them. (lemmy itself is no stranger to this: the fact that users and communities can share the same username break quite a bit)
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
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?
tbf Lemmy’s behavior is documented and standardized (https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md) it’s just that their fallback code for instances that don’t federate the Lemmy way also boosts the target posts for each update as opposed to just once on creation like you’d expect
how many times did you edit that post per chance? Lemmy seems to boost edited posts for some odd reason
see https://brain.d.on-t.work/notes/9md8phwlkzlj0xe9 and https://brain.d.on-t.work/notes/9m1y542jlg8002bj for it happening on my misskey instance hacked together to support Lemmy federation
FYI misskey does not implement the masto api. some software like pleroma/akkoma, gotosocial and yes, a few misskey forks do (in various states of brokenness, with iceshrimp being the most compliant one) but misskey itself does not.
I think fedibird is a hard fork, so I guess it makes sense to count it separately compared to a soft fork like glitch or chuckya
I’m more surprised why there aren’t any misskey instances on the list. if fedibird is on there misskey should certainly be there
ah, gotcha. this instance is still on 0.18 so that’s why my tests didn’t work out. I’ll edit that part out
you can disable the webpage and unauthorized API if you so choose. mastodon and pleroma/akkoma provide these settings. gotosocial hides all posts with an unlisted visibility from public pages.
authorized fetch only provides protection for activitypub, it’s just a single component of a layered stack of protection you can enable depending on your exact threat model.
the privacy threat model of Lemmy is significantly different from a microblog, which is the current target of threads.
(also have none of you heard of consent?)
cc @FaceDeer@kbin.social this reply also applies to your reply
no, not really.
i have attempted to build my own federated stuff (none of them actually federated “in real life” though) so i did read the specs but quite a lot of these are from my memory and if there’s anything i know is that my memory fuckin sucks lol
Which could still be millions?
sharedInbox handles this.
mastodon.social sends a single federation activity to www.threads.net’s sharedInbox. threads’s internal systems handle all the visibility and routing to followed users and whatnot. the same thing happens in the opposite direction for threads->mastodon (or whoever).
now in theory this is an optional part of the specification and you can in fact send one activity per person if you really want to, but considering how widespread it is (and how relatively easy it is to implement) you’d have to be intentionally and explicitly malicious to not use a sharedInbox if the remote server indicates it supports it.
just want to clarify something:
However, the way that activitypub works, the outgoing data is publicly available. Defederating with Meta doesn’t prevent that,
there is a technical solution to this in the form of authorized fetch: https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/
mastodon implements it, pleroma/akkoma probably implements it, pixelfed implements it, firefish and iceshrimp implement it (sharkey has a PR implementing it opened just today), gotosocial not only implements it but enforces it, with no ability to turn it off
notably, none of the threadiverse software implement it, and no software other than the aforementioned gotosocial enable it by default.
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…