New Communities
A place to post new communities all over Lemmy for discovery and promotion.
Rules
The rules for behavior are a straight carry over of Mastodon.World's rules. You can click the link but we've reposted them here in brief, as a guideline. We will continue to use the Mastodon.World rules as the master list. Over all, be nice to each other and remember this isn't a community built around debate. For the rules about formatting your posts, scroll down to number 2.
1. Follow the rules of Mastodon.world, which can be found here.
A. Provide an inclusive and supportive environment. This means if it isn't rulebreaking and we can't be supportive to them then we probably shouldn't engage.
B. No illegal content.
C. Use content warnings where appropriate. This means mark your submissions NSFW if need be.
D. No uncivil behavior. This includes, but is not limited to: Name Calling; Bullying; Trolling; Disruptive Commenting; or Personal Criticisms.
E. No Harrassment. As an example in relation to Transgender people this includes, deadnaming, misgendering, and promotion of conversion therapy. Similarly Misogyny, Misandry, and Racism are also banned here.
2. Include a community title and description in your post title. - A following example of this would be New Communities - A place to post new communities all over Lemmy for discovery and promotion.
3. Follow the formatting. - The formatting as included below is important for people getting universal links across Lemmy as easily as possible.
Formatting
Please include this following format in your post:
[link text](/c/community@instance.com)
This provides a link that should work across instances, but in some cases it won't
You should also include either:
or instance.com/c/community
FAQ:
Q: Why do I get a 404?
A: At least one user in an instance needs to search for a community before it gets fetched. Searching for the community will bring it into the instance and it will fetch a few of the most recent posts without comments. If a user is subscribed to a community, then all of the future posts and interactions are now in-sync.
Q: When I try to create a post, the circle just spins forever. Why is that?
A: This is a current known issue with large communities. Sometimes it does get posted, but just continues spinning, but sometimes it doesn't get posted and continues spinning. If it doesn't actually get posted, the best thing to do is try later. However, only some people seem to be having this problem at the moment.
Image Attribution:
Fahmi, CC BY 4.0 https://creativecommons.org/licenses/by/4.0, via Wikimedia Commons>>
view the rest of the comments
looks
So, I don't know what the beef between the !world@lemmy.world mods and you was, but...
That's a lot of activity for a new community. On Lemmy.today, I see 82 upvotes for the first article, which was apparently a week ago...and I assume that this is the first announcement.
https://lemmy.today/post/17163696?scrollToComments=true
lemmy.world shows the same thing for it.
Normally, Lemmy doesn't show users who have upvoted a post. Only admins can see that.
But Kbin and Mbin do, including on federated servers.
So, I can look at the upvotes for that post; mbin shows them on the "favorites" tab.
Fedia.io is an mbin instance.
When I go to the most recent !world@quokk.au post on Fedia.io, however, all of those votes that your community is reporting disappear. It shows virtually no upvote activity.
https://fedia.io/m/world@quokk.au
In fact, no post in that community has more than four upvotes. Most of them, you've upvoted. But I don't see a lot of other users there. One or two.
Now, that might just be some kind of mbin bug. But the posts on !world@lemmy.world look pretty much the same on lemmy.today and fedia.io. It shows real users generating those upvotes.
Now, okay. Maybe it's just me being cynical and skeptical. But this is your home instance, yeah? You wouldn't have anything to do with that instance possibly reporting incorrect vote totals on posts on your new community, right?
And keep in mind, I'm not saying that more competition for communities is a bad thing. More options, let users choose what they want. But I'd also think that having an instance report accurate numbers to help them make that choice is important. And if they aren't accurate, that ain't a great start for the community, in my book.
EDIT: Looking further, it looks like it's just a very high upvote count for a new community relative to age and comments, but I was able to look at the users doing the voting on another instance, and the users doing so don't appear to be bots; that's coupled with some oddity of vote propagation; I detailed this in a follow-up comment. Sorry, Deceptichum! I don't believe that there's any funny business going on.
Yeah, the ratio of upvotes to comments looks a little unusual IMO
I suppose that there's also a broader technical issue here. Like, Deceptichum's a real user, a regular on various communities I use. He comments, contributes. I don't much agree with him on, say, Palestine, but on the other hand, we both happily post images to !imageai@sh.itjust.works. I figure that he probably got in a spat with the !world@lemmy.world mods, was pissed, wanted to help get a little more suction to draw users. That's relatively harmless as the Threadiverse goes. This is some community drama.
But you gotta figure that if it's possible to have an instance reporting bogus vote totals, that it's possible for someone to have bogus vote totals at greater scale. So you start adding instances to the mix. Maybe generating users. Like, there are probably a lot of ways to manipulate the view of the thing.
And that's an attack that will probably come, if the Threadiverse continues to grow. Like, think of all the stuff that happens on Reddit. People selling and buying accounts to buy reputability, whole websites dedicated to that, stuff like that. There's money in eyeball time. There are a lot more routes to attack on the Threadiverse.
I don't know if that's a fundamental vulnerability in ActivityPub. Maybe it could be addressed with cryptographically-signed votes and some kind of web of trust or...I don't know. Reddit dealt with it by (a) not being a federated system and (b) mechanisms to try to detect bot accounts. But those aren't options for the Threadiverse. It's gotta be distributed, and it's gonna be hard to detect bots. So, I figure this is just the start. Maybe there has to be some sort of "reputability" metric associated with users that is an input to how their voting is reported to other users, though that's got its own set of issues.
That is how it works, I believe. Each vote has to be signed by the actor of the user that voted.
There have been people who did transparent vote-stuffing by creating fake accounts en masse and get detected, because they were using random strings of letters for the usernames. Probably it's happened more subtly than that and not been detected sometimes, too, but it's not quite as simple as just reporting a high number.
I believe that the basic metric of trust is instance-level. That is, it's the TLS certificates and whether-or-not an instance is federated that is the basis of trust. I don't think that users have individual keys -- I mean, it'd be meaningless to generate one rather than just trusting a home instance without client-side storage, and that definitely doesn't exist.
Having client-side keys would potentially, with other work, buy some neat things, like account portability across instances.
But the problem is that, as you point out, any solution on vote trust can't just be user-level keys, unless every admin is gonna police who they federate with and maintain only a network of instances that they consider legit. Once I federate with an instance, I grant it the right to create as many accounts as it wants and vote how it wants. And keep in mind that ownership of an instance could change. Like, an admin retires, a new one shows up, stuff like that.
Your actor (
https://lemmy.today/u/tal)'s public key is:All ActivityPub users have their own private keys. I'm not completely sure, and I just took a quick look through the code and protocols and couldn't find the place where vote activity signatures are validated. But I swear I thought that all ActivityPub activities including votes were signed with the key of the actor that did them.
Regardless, I know that when votes federate, they do get identified according to the person who did the vote.
In practice, you are completely correct that the trust is per-instance, since the instance DB keeps all the actor private keys anyway, so it's six of one vs. half dozen of the other whether you have 100 fake votes from bad.instance signed with that instance's TLS key, or 100 fake votes signed with individual private keys that bad.instance made up. I'm just nitpicking about how it works at a protocol level.
Ah, thank you for that, then; that makes sense. And yeah, if there is a per-user key, then I'd expect it to be signing votes.