Skip Navigation

Posts
65
Comments
607
Joined
3 yr. ago

  • Jump
  • 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.

  • Jump
  • 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.

  • Jump
  • 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.

  • Jump
  • 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.

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

  • Jump
  • Jump
  • 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.

  • Jump
  • 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.

  • Jump
  • 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.

  • Jump
  • 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.

  • Jump
  • 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.

  • Jump
  • 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.

  • Punycode is not solving the same problem. Punycode solves Unicode in domain names. Percent encoding is for Unicode in URL paths. Lemmy only needs to worry about the paths, Punycode should be "supported" out of the box without any special handling

  • At least use TOML if you like ini, there is no ini spec but TOML can look quite similar.

  • It is also just a convention to use ASCII for usernames in many platforms.

    That's only true for platforms that only caters to the English speaking world. The fediverse should be and is much broader than that.

    ASCII is also supported out of the box in major OSes while some unicode characters might not.

    What? There is no major OS that does not support Unicode out of the box.

    Percent encoding is perfectly fine and users won't even see it.

    Also please stop down voting twice with your alt accounts, that's not cool.

  • It's a major downside to my own users though. I wish I could disable uploads for everyone else :P

  • There is a standard way to encode Unicode into URLs, it definitely doesn't have to be ascii. Percent encoding is used all over the place.

    EDIT: I don't mind a down vote but double down voting me from your alt @Asudox@lemmy.world is not cool. That's sockpuppetry/vote manipulation.

  • Yes, storage costs matters. I think it's honestly crazy that Lemmy caches images as much as it does. It would be great to be able to just disable it completely, but alas you can't do that without disabling uploads for your own users either (at least I don't know how).

  • Yes, but honestly unless you're very big, federation queries are the bulk of the processing and stuff from your own instance doesn't matter that much. I mean think about it, do you think the 100 active users on your own instance is what costs or the 10000 users posting all over the fediverse is what matters? Obviously the latter. So again, local user count is not that impactful.