Skip Navigation

Posts
65
Comments
607
Joined
3 yr. ago

  • Jump
  • Yep exactly, it also leads to Mastodon instances only seeing local likes for remote posts. You'll never see remote likes on remote posts as they wouldn't be sent to your instance. I honestly don't understand how this hasn't been a bigger problem for Mastodon, but I guess Mastodon is more about boosts and chronological timelines and less about sorting stuff based on likes.

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

  • Jump
  • Jump
  • Mastodon doesn't support groups so it's maybe not a "bug" per se, but it is at least a missing feature.

    Consider also that if Lemmy shared upvotes the same way, you would only see the upvotes on posts from your own instance, i.e. upvotes would only appear on the local feed. The all feed would be pointless and in general it would be pointless to try to sort posts across the whole fediverse, as you only receive upvotes for your local posts.

    Lemmy simply would not function if it shared votes like that. So in that sense, it's a bug kind of. And as mentioned above, I think it's a bad way of doing it, as it encourages centralization.

  • Jump
  • Once every two minutes is plenty,

    That won't work, because it would have to be once every two minute for every single comment and post forever.

    You have a point about new sort, but you could approximate it by sorting what’s known to an instance. It’s not ideal, but it’s at least something. Maybe it would make sense to push just that feed, or to fetch a subset periodically.

    I have no idea what you mean by this - you can't fetch a feed, that's not at all how the data is organised.

    If someone on Mastodon likes a post on feddit.dk, I don’t see any reason feddit.dk can’t communicate that to lemm.ee when I go look at it.

    The problem is this: How does lemm.ee know that the like that feddit.dk claims is from mastodon.social actually is from mastodon.social? What prevents feddit.dk from just fabricating a like from mastodon.social? Currently there is no nice mechanism for authenticating such a forwarded like. A malicious instance could send loads of likes claiming they come from other instances.

  • Jump
  • I don't understand why your instance seems to be rewriting the link somehow, but it shouldn't. This happens with lemmy-ui?

  • Jump
  • The way you describe this, it sounds like it would need to work on trust a lot more than it already does. What if there's a malicious instance actively circumventing bans, ignoring any pulbished banlist?

    As for sending the post, it’s not that hard to keep track of all servers that follow a group or person or hashtag

    I was talking about the scenario where you are instance A and you don't know the followers of a user of instance B. That is not easy to keep track of, since you obviously don't get any of the follow requests for a user on another instance.

  • Jump
  • Interesting. Seems like Photon attempts to do some kind of clever (and entirely non-standard) hack and tries to load the comment from your own instance? But obviously you need to see it from Feddit.dk to see the votes. This is a bug with Photon I would say.

  • Jump
  • Weird, what client are you using?

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

  • Jump
  • ActivityPub was designed for social networks, not for forums.

    If you ask me, forums are social media. I think it's very prescriptive to say that forums should somehow not be supported by a social protocol. I'm not really sure how ActivityPub was designed, but in some ways it feels like they tried to make the protocol too flexible and somehow they managed to make it not flexible enough in other areas, or at least somehow didn't think to support other use cases very well. It's unfortunate.

    The alternative, in my opinion, would be shared inboxes combined with adding the “public” audience to outbound messages.

    So with this model, when I post to, say !technology@lemmy.world, my own instance would send the post to all the instances that I know of? Or would it send to only those instances following that community (how does my instance know that?)? I think there's also the problem of how moderation is handled - I mean, how does the community in question enforce bans for example? With the current model, the community is kind of "in control" of everything happening, because it is the one sending out the activities. But if everyone sent them themselves, that seems less clear. What if the community defederates an instance but my instance doesn't defederate that one - will my instance send the post to the instance that is defederated by the community? It's all very complicated. I'm not sure what a good solution is.

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

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

  • Jump
  • But that’s how ActivityPub was designed?

    This design is incredibly badly suited for something like a forum or content aggregator, such as Lemmy. Only sending Likes to the direct receiver means that other instances are unable to sort content based on votes accurately. Mastodon unfortunately doesn't care much about this since they prefer chronological timelines, and then Like counts and such don't matter as much.

    It's really sad that ActivityPub, a supposedly very flexible protocol, seemingly is made mostly for microblogging and doesn't support other use cases very well at all.

    Are groups going to be implemented in Mastodon by replicating the crazy “pretend there’s an account boosting everything that’s happening on the server” behaviour?

    Call it crazy but what other options are there? And honestly it is entirely within the spec so it's not that crazy.

    The crazy thing, if you ask me, is that ActivityPub does such a poor job of modelling something like a subreddit. Modelling a subreddit as a Group of users who are subscribed to that subreddit seems unnatural. Most people would say a subreddit is more like a category for posts or a collection of posts.

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

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

  • Jump
  • 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 https://feddit.dk/post/7628338/10255563

  • Jump
  • the fact that mastodon and Lemmy use the same protocol is annoying

    Well I think this is still better than the alternative, which is no interaction between them at all 😅. The protocol is what binds different Lemmy instances together too.

  • Jump
  • There were communities using this blatant security issue for non-malicious purposes (see https://endlesstalk.org/c/tails@lemmon.website, 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.

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