There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance

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:

  1. This one from @bstix with a whopping 3661 upvotes.
  2. This one from @TDCN 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 @Plume).

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.

iso ,
@iso@lemy.lol avatar

Does the receiver instance federate that like object to other instances? If not, it is shit for sure.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

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.

iso ,
@iso@lemy.lol avatar

You’re right, that’s worse.

finickydesert ,
@finickydesert@lemmy.ml avatar

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.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

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.

finickydesert ,
@finickydesert@lemmy.ml avatar

So there’s no way for feddit.dk to translate into a Lemmy style upvote?

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

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.

finickydesert ,
@finickydesert@lemmy.ml avatar

Ohh so the object doesn’t change at all through the process. I see the difficulties

skullgiver ,
@skullgiver@popplesburger.hilciferous.nl avatar

I’m not sure if that’s true. From the spec:

Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.

This requires implementing sharedInbox support, but I believe this should permit federating any content of choice to any server.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

That would still be directly from one server to another server. I.e. from A to B and from A to C. But forwarding is a different matter, i.e. A sends something to B which sends it further to C. There’s complications with signatures and verification in that case and it’s less clear how to handle that.

muntedcrocodile ,
@muntedcrocodile@lemm.ee avatar

So we need to convince the mastodon devs to change it so the signature is on the like object itself.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Unfortunately it is not that easy. It’s not Mastodon that places the signature like that, it is the ActivityPub protocol. Lemmy, Mastodon and all other ActivityPub instances do it this way. You’d need to extend or change the protocol to somehow fix this. That is not easy and not something that will be done overnight.

skullgiver ,
@skullgiver@popplesburger.hilciferous.nl avatar

But surely the receiving server could validate that signature by verifying the existence of the received activity (by asking the origin server for the object referenced and validating the signature).

If like objects are distributed in URL form, this is already how it works. The extra load wouldn’t be fun, for sure, but the lack of an embedded signature makes it very easy to falsify anything on the Fediverse.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Yes, fetching the URL directly would be a way to verify it. I don’t know if Lemmy currently does that. In any case, it seems very round-about.

skullgiver ,
@skullgiver@popplesburger.hilciferous.nl avatar

Lemmy doesn’t do it currently. It blindly trusts communities to not lie to people. I just found out about this myself.

In theory the JSON body could include all the necessary information to validate a signature and the signature itself. Then, a simple HEAD request could validate the contents without having to re-download everything, and users’ public keys could be cached to minimise HTTP requests necessary.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

If you have a signature you can also sign the contents, so you wouldn’t need to download the content. But AFAIK ActivityPub has no mechanism for including signatures in objects as it is right now. There’s only HTTP signatures, which aren’t on the object itself.

rglullis , (edited )
@rglullis@communick.news avatar

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.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Mastodon explicitly discourages support of LD signatures. It seems it has kind of landed in what I would call “specification hell”.

rglullis ,
@rglullis@communick.news avatar

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.

ShittyKopper ,

I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see 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).

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

There were communities using this blatant security issue for non-malicious purposes (see 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)).

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.

ShittyKopper ,

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.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

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.

BentiGorlich ,
@BentiGorlich@gehirneimer.de avatar

Its not really a "not playing well" with each other, it is just the mastodon works. That is the reason why most toots in my mastodon timeline have 0 favourites (upvotes) and only a few boosts... I don't know why they do it, because at the minimum the followers of that user should be notified about that like...

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

at the minimum the followers of that user should be notified about that like…

I agree - the problem is that the instance that sends the Like (on instance A) doesn’t know the followers of the user receiving the Like (on instance B), because followers are not (necessarily) public. So it doesn’t know which instances to send the Like to. And instance B can’t forward the Like to the followers itself, because the signatures in ActivityPub are not made for that, as I explained elsewhere in the thread.

BentiGorlich ,
@BentiGorlich@gehirneimer.de avatar

AP has a tool for that called inbox forwarding and mastodon uses it for sharing the comments under posts. It works like this: you send a reply to a user with their follower collection as the recipient. You of course cannot know who is following that user, however they than just forward this reply to the follower collection, because the server knows that it has authority over that collection. https://www.w3.org/TR/activitypub/#inbox-forwarding

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

however they than just forward this reply to the follower collection

How do the receivers of this indirect activity verify that the activity was indeed produced from the original instance?

catloaf ,

I don’t understand why feddit.dk doesn’t display upvotes received from Mastodon users. Why is this dependent on my instance?

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Feddit.dk and any other Lemmy instances do show Mastodon upvotes. It’s not Feddit.dk-specific, it just so happens that Feddit.dk has a couple of comments that went super popular on Mastodon. It’s just random. Maybe try reading the post again, it sounds like you misunderstood something.

catloaf ,

Yes, I’m definitely not understanding something. You said that Mastodon only sends upvotes to the instance of the user receiving the like, in this case feddit.dk, right? Then why, if I view the post on feddit.dk, does it not show me those likes/votes? What is dependent on my instance?

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Then why, if I view the post on feddit.dk, does it not show me those likes/votes? What is dependent on my instance?

I don’t understand what you mean, how does it now show you the likes? If you see the two comments here and here as I linked above, you can see the high upvote count. Almost all the upvotes are from Mastodon instances.

The upvotes do not appear if you view the comments from another instance, like here and here, because those instances did not receive the Like.

catloaf ,

Sorry, I mean when I view the comment via my instance. I don’t understand why my instance needs to receive the votes/likes directly, instead of my instance fetching them from feddit.dk when I request the comment.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Your instance doesn’t pull the upvotes from other instances. That would not be scalable. How would it know when to pull again, to see new upvotes? When would it stop pulling periodically? Never? And you’d have to do this for every single post and comment everywhere.

No, instead ActivityPub uses a push mechanism here. So any new activity is pushed out to the ones that are deemed relevant to know about the activity. Any other instances are unaware.

catloaf ,

Pulling the data when a user requests a post/comment (with a cooldown/cache for popular posts) isn’t any more or less scalable than feddit.de pushing the same data whether it’s been requested or not. If anything, I’d think pushing data when it’s not necessarily needed would be less scalable.

But if it has to be a push model, why doesn’t feddit.dk push the votes it knows about along with the rest of the data?

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Pulling the data when a user requests a post/comment (with a cooldown/cache for popular posts) isn’t any more or less scalable

That would definitely be less scalable. That would entail pulling every single time a user views a post or comment. That’s simply not feasible. There are far, far more views of content than there are posts, comments and votes.

Also what about stuff that isn’t seen? What if nobody is logged in or nobody looks at the New sort? You need the votes before you even show the user anything, otherwise you can’t sort the votes.

But if it has to be a push model, why doesn’t feddit.dk push the votes it knows about along with the rest of the data?

This has been explained elsewhere in the thread, see feddit.dk/post/7628338/10255563

p03locke ,
@p03locke@lemmy.dbzer0.com avatar

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).

Wait, back up… Mastodon calls these “toots”? So, everybody is posting farts?

veeesix ,
@veeesix@lemmy.ca avatar

Tooting the way you’d toot a horn/trumpet, or in this case an elephant trunk.

FundMECFSResearch ,

great post, thanks

flamingos ,

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).

Mastodon needs to implement group support, you can follow the issue here (don’t get your hopes up though).

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

Group support would fix it for Lemmy, but it doesn’t fully fix the problem as I see it with this way of sharing the Like objects. For toots outside of any group (in Lemmy terms: comments/posts outside a community), presumably it would continue to function like this, i.e. only the receiving instance is aware of the Like. This still encourages centralization if you ask me.

flamingos ,

Yeah, I’m not going to defend Mastodon’s frankly bizarre Like system. It’s not even a privacy thing as favourites are fully public.

EleventhHour ,
@EleventhHour@lemmy.world avatar

Perhaps you should report this as a bug to the devs. Otherwise, this was an interesting read.

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

The Mastodon devs are aware of how their Like federation works and considers it a feature, not a bug.

EleventhHour ,
@EleventhHour@lemmy.world avatar

I was referring to the lemmy devs, but ok, I guess

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

I don’t think there is anything the Lemmy devs can do to fix this. The ball is in Mastodon’s court, so to speak.

benjhm ,

Interesting observation and analysis, and illustrates the potential of more lemmy-mastodon interaction.
Indeed mdon like-federation seems weird but I presume it was setup this way for efficiency, to reduce the number of small communications? Although Lemmy has a backend in rust - more efficient than mdon’s ruby - still I wonder whether the lemmy system of federating all upvotes would scale well if the number of users grows to that of mastodon and beyond ? Could there be some intermediate compromise solution (e.g. federate batches of 100 likes)?

SorteKanin OP ,
@SorteKanin@feddit.dk avatar

still I wonder whether the lemmy system of federating all upvotes would scale well if the number of users grows to that of mastodon and beyond ?

It’s a good question and really we just don’t know yet I think. It’s very hard to predict performance of complex systems. The only way to know, is basically by measuring, and the only way to do that is if we actually had that amount of users.

Could there be some intermediate compromise solution (e.g. federate batches of 100 likes)?

Unfortunately ActivityPub has no way to “batch” activities like this.

Linus_Torvalds ,

Thank you for putting in this amount of effort highlighting some shortcomings of the Fediverse

Fubarberry ,
@Fubarberry@sopuli.xyz avatar

That was a good investigation and explanation about a weird number of up votes. Thanks for explaining it.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines