this post was submitted on 11 Aug 2023
32 points (72.2% liked)
Fediverse
28220 readers
1153 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Not in the Lemmy UI or the standard API, no. The data is collected but not exposed to the web API or to clients.
Not all votes get federated, so you can only trust the posts on your home server.
You can see who up/downvoted this post in the database:
However, my database only contains the posts that I received/am subscribed to. These are the only posts my server thinks you upvoted:
Comments are counted separately, but I assume most of the stuff you upvoted isn't on there. The lemmy.world admin can see all of your votes of course, but external users can't query the votes (see https://lemmy.world/api/v3/post?id=3027601 for all the data available through the API).
So there are things you can do with this, but they're I don't think the people behind Lemmy care to make them available through the API. You should consider your votes to be public, but they're not indexed by search engines.
I've considered writing the pettiest script on Lemmy (ban+purge everyone who downvotes you from the server) for shit and giggles, but I'd be afraid to publish it because I can see people actually use that non-ironically.
That's true, but I don't think any search engines care about the Fediverse for the moment. There's not a lot of money to be made on all of these ad-free websites. With the relatively small communities it's also not a great source for stealing AI training data from.
Plus, the fact the content is mirrored all over the place probably triggers clone/bot detection, with clickable links to other Fediverse instances triggering the anti-bot measures.
A huge network of pages mostly linking to each other, all replicating each other's contents, sounds like a textbook example of SEO abuse.
It would also open the door for rogue instances to send out massive downvote counts without any data to back that up. That's not to say you couldn't already do that with fake users, but it's much easier to identify a mass of fake users than it is to identify a mass of fake downvotes as a number.
No it wouldn't, if the instances were creative with the data manipulation. I can think of at least 3 ways to do it right now
Also without identifying the user it becomes hard to know what's a unique like and what is a duplicate. I suppose a workaround would be for the user's instance to keep a record of who liked what, and then just issue just the unique like IDs (which can be traced back to the user only on their home instance).
It would need to be a bit smart. Say the same user toggles their upvote on and off. The upvote for a given topic I think would need to be a hash of the topic/comment ID + user ID so that the same ID would be re-issued to prevent the upvotes/cancels falling out of sync.
It's a lot of effort really for keeping something such as a like private.
What if the post is edited at a later time? Then all those votes become invalid. It's not practical with the way ActivityPub is designed. Honestly, it's designed the way it is for a reason... if you aren't willing to own your participation on a public forum, you shouldn't be on a public forum.
Why would editing do that? I was talking about using the ids which wouldn't change on an edit.
In any case, I don't have a problem with this info being federated. Some people do, so it's worth talking about ways it could be done.
Because using a hash based on elements in the post would change on an edit is why I said that
I was suggesting (I actually clearly said it in both comments) hashing the post/comment ID + userid NOT the content. Just enough info to get a unique ID. We don't need it not to be non-reversible. Just a unique ID for the like.