I recently discovered an interesting (and somewhat disappointing, as we’ll find later) fact. It may surprise you to hear that the two most upvoted comments on any Lemmy instance (that I could find at least) are both on Feddit.dk and are quite significantly higher than the next top comments.
The comments in question are:
- This one from @[email protected] with a whopping 3661 upvotes.
- This one from @[email protected] with 1481 upvotes.
These upvote counts seems strange when you view them in relation to the post - both of the comments appear in posts that do not even have 300 upvotes.
Furthermore, if you go on any instance other than Feddit.dk and sort for the highest upvoted comments of all time, you will not find these comments (you’ll likely instead find this one from @[email protected]).
Indeed, if you view the comments from another instance (here and here), you will see a much more “normal” upvote count: A modest 132 upvotes and a mere 17 upvotes, respectively.
What’s going on?
Well, the answer is Mastodon. Both of these comments somehow did very well in the Mastodon microblogging sphere. I checked my database and indeed, the first one has 3467 upvotes from Mastodon instances and the second one has 1442 upvotes from Mastodon instances.
Notice how both comments, despite being comments on another post, sound quite okay as posts in their own right. A Mastodon user stumbling upon one of these comments could easily assume that it is just another fully independent “toot” (Mastodon’s equivalent of tweet).
Someone from Mastodon must have “boosted” (retweeted) the comments and from there the ball started rolling - more and more people boosted, sharing the comments with their followers and more and more people favorited it. The favorites are Mastodon’s upvote equivalent and this is understood by Lemmy, so the upvote count on Lemmy also goes up.
Okay, so these comments got hugely popular on Mastodon (actually I don’t know if 3.4k upvotes is unusual on Mastodon with their scale but whatever), but why is there this discrepancy between the Lemmy instances then? Why is it only on Feddit.dk that the extra upvotes appear and they don’t appear on other instances?
The reason is the way that Mastodon federates Like objects (upvotes). Like objects are unfortunately only federated to the instance of the user receiving the Like, and that’s where the discrepancy comes from. All the Mastodon instances that upvoted the comments only sent those upvotes directly to Feddit.dk, so no other instances are aware of those upvotes.
This feels disappointing, as it highlights how Lemmy and Mastodon still don’t really function that well together. The idea of a Lemmy post getting big on Mastodon and therefore bigger on Lemmy and thus spreading all over the Fediverse, is unfortunately mostly a fantasy right now. It simply can’t really happen due to the technical way Mastodon and Lemmy function. I’m not sure if there is a way to address this on either side (or if the developers would be willing to do so even if there was).
I personally find Mastodon’s Like sharing mechanism weird - only sharing with the receiving instance means that big instances like mastodon.social have an advantage in “gathering Likes”. When sorting toots based on favorites, bigger instances are able to provide a much better feed for users than smaller instances ever could, simply because they see more of the Likes being given. This feels like something that encourages centralization, which is quite unfortunate I think.
TL;DR: The comments got hugely popular on Mastodon. Mastodon only federates upvotes to the receiving instance so only Feddit.dk has seen the Mastodon upvotes, and other instances are completely unaware.
No, but how could it? Let’s say Feddit.dk receives a Like from mastodon.social. Then Feddit.dk would have to tell the other instances that mastodon.social sent that Like. But how can Feddit.dk prove that the Like actually did come from mastodon.social, i.e. it is not just a fabricated Like that Feddit.dk made up and hid by pretending it came from mastodon.social. That’s not easy.
The like is an activity. Any activity has an actor. Every actor has a public key. If the activity is sent with a cryptographic signature (like LD signatures, which Mastodon does implement) then any one can verify that the activity is legit.
Mastodon explicitly discourages support of LD signatures. It seems it has kind of landed in what I would call “specification hell”.
Discouraged, but still supported. There is also another FEP (forgot the code now) being worked on and implemented by Mitra.
The point is that it is possible for an instance to federate an activity which is not originated by them.
I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see https://endlesstalk.org/c/[email protected], which re-wrote posts from people (which is only possible if the posts weren’t validated, or at least re-fetched from their origins)).
There is a way to re-share and validate remote activities, either through LD signatures (ew, JSON-LD processing :vomit:) (which only Mastodon and Misskey implement) or the newfangled FEP-8b32 Object Integrity Proofs (which nobody relevant on the microblogging space implements).
The reason this is possible is because of the way Lemmy federates activities.
When you on instance A post, comment or upvote something in a community on instance B, your instance sends the activity to instance B, regardless of the instance of who you’re replying to or upvoting. It is sent to the community, and the community then shares it out to all other instances. AFAIK, lemmy does nothing to verify that received content from a community actually comes from the original instance. See here for one of the main Lemmy devs commenting on this..
Is this secure or reasonable? I’m honestly not sure but it doesn’t feel great. Signatures on objects could fix this I think.
Instead of sending the entire object embedded in the activity the secure way would be to only the URI instead. This is permitted by JSON-LD.
In the receiving side, if the object is untrusted (i.e. if it isn’t signed or if it’s from a separate authority from the parent object containing it) it should be thrown away and the id should be fetched from the remote instance directly (same as it would happen if it was a URI instead of an inline object). This is completely an oversight on Lemmy’s implementation and not a protocol problem.
That would be a way to do it, but it seems needlessly wasteful as it requires an additional HTTP request. But yea, that could be a way.
Yeah, that is a shortcoming of the protocol. But it’s necessary in order to be secure until things improve (and given this is AP, that’s gonna be a while. People seem to love bikeshedding in circles instead of doing actual work)
Out of curiosity, what do you mean by this? Any examples? I’ve not followed the development of AP very much at all honestly so I don’t know the history.
this issue is a blocker for mastodon not supporting filtering remote posts by words (which would’ve helped with many spam attacks, which the pleroma family supported just fine for a WHILE via MRF, and more recently misskey has added support for)
if you go to socialhub you’ll find MANY threads of reasonable ideas that are in json-ld representation bikeshed hell as people unnecessarily debate over which exact json-ld representation of the same exact data is the most correctest. the most infuriating recent ones i have seen is the emoji reaction fep discussion and FEP-fb2a: Actor metadata both of which does this bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY
I recently started looking at socialhub actually. I have even participated in that emoji reaction thread you linked, but I only joined the site recently.
Honestly, I’m a bit confused by the site. There’s kind of a lack of direction in a sense? Everyone is trying to extend the protocol in various different ways and it seems difficult to achieve alignment and agreement. I guess that is to be expected in a decentralized system but still.
What’s the alternative though? I mean nobody has the authority to put their foot down and decide. I agree that the debates go on for way too long, but how else do we find alignment? Then again, the long discussions definitely exhibits a kind of selection bias - only the people who are pedantic enough to keep discussing will do so. Everyone else naturally just get tired of the whole thing and leave.
It’s weird but it almost feels like the fediverse needs a benevolent dictator to kind of get an overview and set a clearer direction, when it comes to the standards.
But these features were totally non-standard extensions right? You can’t expect such things to continue being compatible as the actual standard evolves. It would also be a neat way to strong-arm the standard - just implement an extension in the way that you want it to work and now the standard has to keep your version compatible. That wouldn’t be good. Just because there exists a non-standard implementation does not mean it should be able to dictate how stuff should be done.
I mean it could be proven by having every account create a cryptographic key and adding a public key to the vote. Memory might be an issue though.
This is in fact how Feddit.dk knows that the Like came from mastodon.social at first. The problem is that the signature is a HTTP Signature which is only associated with the HTTP request that mastodon.social makes to Feddit.dk. It is not on the Like object itself. Thus that signature can’t be transferred to the Like object if Feddit.dk wanted to share it further.
So there’s no way for feddit.dk to translate into a Lemmy style upvote?
There’s not such a thing as a “Lemmy style” upvote. It’s all Like objects under the hood shared via the ActivityPub protocol. But ActivityPub has no mechanism for sharing an activity further than the original receiver (i.e. forwarding from A to B to C and so on). It’s really only made for direct sharing from A to B.
Ohh so the object doesn’t change at all through the process. I see the difficulties