Properly federate "like" objects #11339
Comments
ealgase
changed the title
like objects
ealgase
changed the title
like objects
|
Sorry, but this was a deliberate decision and I don't think people want their likes to be broadcasted to 3rd parties. |
|
Understandable, but I think most people would want this feature. At least, incoming |
|
I would like to see at least the amount of likes a certain post gets. It doesn't necessarily need to behave like boosts that bring the toot that has been interacted with to the timeline. |
|
IMO if a Like activity is posted to your outbox publicly, then it should be processed publicly, a la Facebook's "{user} liked a post by {otherUser}". Other implementations may want to publicly display Likes as a post kind of its own. But Mastodon does not have to author Likes to user outboxes. Additionally, if a Like is addressed directly to the author (and only to the author), it should behave as currently (generate a notification for them and add you to the list of users who liked a status) |
|
If likes are |
Likes are not currently addressed to |
Given the fact Mastodon displays everything chronologically and doesn't pick content that you think you will enjoy I can understand why Gargron might feel like this is not wanted. It might overcrowd timelines pretty quickly and give a sense of spam. However, instances could still record similar activities without having to show the toot in the home or federated timelines. The favourited toots would only show on their authors' profiles if they are not followed by anyone in the home instance, which would also mitigate empty profiles until #34 is implemented. If the author is already followed then the only change would be the increase to the favourite counter. |
|
@ichi-i i'm not saying that mastodon should show likes in the timeline. i'm saying that other services might do so as a feature. i think what this issue is requesting is to add a handler for incoming |
|
It's requesting two things:
|
|
the former could work, but the latter will likely never be added due to
overwhelming opposition to the idea. if it ever does get added, it'd have
to be opt-in. frankly it's not anyone's business what i choose to Like,
except for the person who owns the object.
…On Wed, Aug 14, 2019, 21:15 TemporaryUsername12481 ***@***.***> wrote:
It's requesting two things:
- Handle incoming Like objects targeting remote posts by attaching
them, not discarding them
- Send Like objects on public posts to all of a user's followers, as
well as to the people mentioned in the liked post (the same way that
replies and announces work)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11339>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACQ5OX2WDZYPIUJ6IGW5CTLQES34TANCNFSM4IETZIMQ>
.
|
Since I was mainly arguing for the former, should I make a new issue for it or is this one enough? |
Then why is it labelled |
|
@TemporaryUsername12481 can you give a live example of a |
|
Favorite a public post. That |
|
People on those instances being able to see it =/= being addressed to as:Public. Can you provide example JSON from Mastodon? |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I also think it would be nice to see the total favourites and Boost count of a post instead of only beeing able to see the local favourites and boost count(exept for the original instance where the toots was posted there you can see the total boost and favourites count I guess) |
|
I also looked around for an option to show favorited posts from people I follow in the home feed, but it is apparently not supported. I'll add an additional motivation that some content creators want to keep a "clean" profile so when people visit they won't mostly see other people's content (and thus make them feel less pressured into constantly churning out content themselves just to "balance" their profiles). |
|
Many users, when scrolling through their timeline, tend to try to judge the "importance" of a post by its Favorite and Boost count. If the problem is that federating the details (i.e., the user who liked/boosted) of the Favorites and Boosts, then simply having the original instance sending the counts of them to federated interested parties would improve the user experience a lot, I believe. |
this is a dark pattern. users should judge a post on its own merits. |
|
Ah … sorry, "importance" may have been the wrong word (please note my quotes), and you do have a good point there. Maybe "Range of coverage" or "Outreach" or simply "Popularity" would be the better term. Of course judging the content and message of a post can’t be done by how many people found it important enough to interact with it. On the other hand, isn’t the question "Is this something many people currently care about" of interest to a user? |
if you care about popularity, sure. but popular things aren't always good or interesting or correct. they're just popular. arguably, even popularity can be faked. consider for example your suggestion to have the original website send favourite/boost counts to interested servers. what happens if my server reports that my post has 10 billion favourites? how meaningful is that number? do you care to see it without any other context? does this have anything to do with the content of the post? |
|
You do have a good point about "rogue" servers there, and this might break up my thought-model. I still feel I haven’t gotten my original thought across yet, which is that to an informed reader of anything, more data is always a benefit. One such data-point could be the "measured popularity" across the community. This does neither mean the reader agree with the content, finds it high-quality or even valid. One other very similar data-point which is already federatedly available today is the followers-count for an account. Doesn’t the same "dark-pattern" argument hold true for this, if you view the entirety of an account as "its content"? However, I do see your point too, especially regarding the ease of faking it … So thanks for your patient explanation and example ^_^ |
Arguably yes, and accounts can and do lie about their follower counts. I would argue that the counts should be hidden, but it'd be up to Gargron to actually do that or not. |
|
Talking this through brought up another angle to view this from: Currently, on big instances, users have "working" favorite/boost counts. That subjects users on big instances to this dark pattern (if we view it as such). Users on small instances are, by design, somewhat protected from this, because they are shown instance-local favorites/boost-counts at best. However, this poses a clear inconsistency: The same data viewed from 2 different points in the network is different. This then raises the question of treating users based on the server-size they’ve chosen is fair. Also the inconsistency raises the inverse problem: Two users from different instances might come to an misunderstanding when chatting about what they’ve read, because they were presented different data. With this in mind, I believe that either choice is fine, but on a technical level we should strive making the information consistent across the network. If that is not possible or very hard, making it consistent by not exposing it to the user might be more fair and less confusing. |
|
I couldn't agree more with Nebukadneza. I have set up my own instance, but because we have less than 10 users there are no trending posts and the explore page is empty. This means that instead of using the explore page on my own instance, I am now forced to go to a big instance, and use its explore page. The end result is just that user experience is diminished, as I can not easily reply, boost or like anymore. The biggest issue with this in my opinion, is that it is extremely bad for decentralization. Not having what are (in my opinion) very important features like boost count, favorite count, and Explore is a very big reason not to join small instances or set up your own instance. |
|
I'm all for any way to improve this. I'm on a smaller instance and I rarely ever see the correct like counts. I have to actually go to the original post 99% of the time to see the actual like counts. I'm always looking at engagement counts on posts as I scroll through, along with actual content. Edit: I just saw a post on my home instance that had 2 likes, as in the number 2. On the original instance, it had 6,000 likes and 5,000 boosts. This is just not at all helpful to people on smaller instances. |
|
I agree that Likes should be federated with the same sort of privacy options that toots already have. I also think that showing the likes count (whether accurate or not) in the timeline should be a user's display option, despite the reluctance the team has had in the past (#420 et al). Short of those, I'd be happy if like counts worked properly between instances (when viewed on the post, as opposed to in the timeline). It really does feel like favorites is broken when you see tons of replies and boosts happening on a specific piece of content, and then after you hit Favorite, the number says "1". Users will always see that as broken, not principled. |
|
Hey everyone, I hope to re-raise some interest in fixing this issue! I've written a thread about it here: https://mastodon.social/@TodePond/109987697840027690 Any feedback would be greatly appreciated. |
|
I run a big(er?) instance. It's probably the Takei post that had over 6000 likes and 5000 boosts and it's extremely unfortunate that the rest of the fediverse didn't get to experience that the same way. Not federating likes causes an inconsistent behavior and this inconsistent behavior adds complexity, and this complexity gets in the way of what people expect from a federated network. The current user experience is broken. Instances that want to be isolated should opt out of processing likes and should run in limited federation mode. Their registration process should signal that they're choosing an instance tailored for a specific audience. Those of us who run deeply federated public instances should provide the expected experience that choosing a general public instance you want isn't something that comes with consequences. FOMO is real. Inconsistencies cause confusion and complexity gets in the way of expectations. |
There's a few objectionable points here, but the implication that instances which don't place such a high importance on the number of likes on posts are seeking "isolation" and should have isolation forced upon them is a particularly unfortunate one.
Inconsistency is unavoidable in a federated network like the fediverse. If likes were federated as originally proposed in this issue, the result would still not be a consistent number visible on every instance, as you appear to believe. Even if instances reported like counts to each other through some other mechanism, user expectations will nevertheless inevitably be betrayed when they come across an instance which pretends posts are more popular than they actually are. In short, the most feasible route to consistency in like counts is to not display them at all. I think there's a broader question here of how best to address the misunderstandings and misconceptions new users might have when they start using a federated social network for the first time. There's a lot that simply cannot be changed to accommodate the expectations they're taking with them as things currently stand. |
|
yeah, arguably the only meaningful part of the Like is who liked the thing. the count is secondary information. it's the equivalent of asking "how long is this list", where the list is likely incomplete because likes are not always public information. in other words, we already "properly federate like objects", we just don't make them public. in mastodon, a "favourite" is just letting someone know that you appreciated their post in some way. the most you could do is handle incoming likes for remote posts: https://github.com/mastodon/mastodon/blob/main/app/lib/activitypub/activity/like.rb the check for if you cared to change the audience on favourites, you would look here: https://github.com/mastodon/mastodon/blob/main/app/services/favourite_service.rb and i think you would have to call |
|
Thanks for sharing your thoughts everyone :) ❤️ I realise that: ie: This issue seems like an appropriate place to continue discussing the specific pros/cons/challenges of federating likes, which is just one proposed solution. ➡️ I might make a separate issue to focus on the topic of incomplete likes+boosts+replies more generally (unless anyone beats me to it) |
What's the objection?
I beg to differ that inconsistency is unavoidable. I'm not striving for perfection, just something better. It's one thing in complex systems to have a continuous margin of error because the system is highly dynamic in nature but it's another thing to introduce error that has consequences because we think we desire these consequences. I haven't seen any users that say this ambiguity is great. I see admins that may defend this because this is the default position, but we don't have to defend the default position. It's not illegal to grow, change and adapt according to what people want. Change is not failure. I'm not so concerned if my instance says 9.800 likes and yours says 9,275 likes. But when one instance says 9,000 likes and another says 0 - that is a problem.
This does nothing for consistency. This is just saying you don't like engagement.
I'm sorry, but what users expect is not a misunderstanding or misconception. This feature can be addressed and it's trivial to address. |
|
likely the objection is that "wanting to federate widely" and "wanting to see likes [/ counts]" do not imply anything about each other. word choice like "want to be isolated" and "should run in limited federation mode" makes no sense, and these conclusions do not logically follow from a valid premise.
the reason that inconsistency is unavoidable is because we are not operating in a unified system. rather than being distributed nodes in one network, the fediverse is more accurately a network-of-networks. what you refer to as "error" is more like each component network having its own source of truth. so yes, the easiest way to be "consistent" is to show nothing. put another way, that like count you see is not a global count, and it can never be one -- it is always local, based on what you received or are aware of. it should only be understood within that qualified context. the question is not "how many people have liked this post?" but rather "how many people have liked this post that we know of?" and more specifically, "who are these people that we know have liked this post?" and, simply put, not everyone cares to answer these questions or to even ask them. outside of that locality, any claim you make should be based in something verifiable, authoritative, or trustworthy; otherwise, it is worth nothing and may as well be a lie. the way to 100% verifiable counts is to have a signature on every single Like activity, and to share every single Like activity publicly. but i highly doubt anyone cares to put this much effort into verifying likes. so the next step down is to show only what you can verify. which creates inconsistency, because as we've said before, there is no global view -- we traded that global view for the locality of federation. consistency is neither possible nor desirable -- per CAP theorem, we chose availability and partition tolerance.
can the user not simply be wrong in their expectations? people are wrong about what "unlisted" does nearly every time it's brought up. there are possibly double-digit issues and discussions on this tracker that seem to expect unlisted replies to be hidden from timelines, with seemingly no basis for that belief. i would similarly say that if a user expects an accurate global like count, then this is an expectation that will never be fulfilled. presumably there exists at least one person who is not familiar with and does not fully understands the concept of verifiable claims. it is certainly possible that this lack of familiarity and understanding may lead to a false expectation. now, if we've accepted that inconsistency is inevitable and that likes are not always public, then we can do two things and no more:
preliminary guidance on how we might do this can be found in my earlier comment. |
|
I am sorry for having strong opinions on this stuff. They clearly do not align with the project or other admins, and I have caused harm to others with these opinions, so I am stepping away from these discussions and reconsidering what I hope to achieve. |
You've said that people who don't have the same perspective on likes should run their instances in "limited federation mode". The only way I can reasonably construe this is whitelist mode, but the level of importance people place on a specific type of incoming activity has nothing whatsoever to do with their desire to talk to people. You might think the number of likes Takei gets on a post is important, others do not. So ist das leben – other people have different perspectives.
Again, inconsistency is unavoidable, the "margin of error" is extremely large, but I'll address that below. It's not that we "desire these consequences", but that there's several ways of approaching like federation, all with fundamental shortcomings, and none of which can actually achieve consistency. The proposal in this issue does have some privacy implications, which I believe is specifically what Gargron is talking about.
If like activities were federated as originally proposed in this issue, before the hijacking/brigading, the numbers would still be extremely inconsistent. We're not talking about a difference between 9800 and 9275, it'd be more in the realm of 56 vs 9800. The idea here is that when you like a post, that like would be delivered not only to the actor which owns the liked note, but also to your followers. This means that someone on another instance needs to be following you for that instance to be aware that you sent a like for a note on a third instance. This proposal is not about federating a number, it's about federating individual like activities, and since the likes number is currently based on the number of known likes, this means that the number would vary extremely widely depending on the proportion of likers who're followed by people on your instance. This means it'll be affected by instance size, instance demographics, instance suspensions, and so on, and so forth. Federating a number instead is possible in principle, but this will also result in inconsistency, because:
I'm saying nothing of the sort, utter tripe.
If users expect a federated network to have qualities which are straightforwardly impossible due to the nature of federation, then they have misconceptions, they misunderstand the nature of the network, and addressing this is far more productive than asking the impossible of maintainers.
There's a certain something in saying that a problem you don't understand is trivial to solve! At any rate, so far we've seen that anyone who discusses the problem in concrete technical terms is downvoted into oblivion, so clearly you're not the only one in that boat. |
Related to this non-apology, I've discovered that you were the source of the brigading. If you're going to apologise for something, apologise for how you're treating contributors, not for "having opinions". |
Could we have the best of both worlds? Imagine if the post’s originating server keeps track of the like count and the usernames who liked it. This should be fast and accurate (if you trust the server). If you suspect the server is inflating the number, there could be a button to validate that each of the listed usernames actually did like the post (obviously much slower). Disclaimer: I’m reading this thread from the sidelines and don’t understand how mastodon works 😅 |
Keeping track of actors (analogous to usernames in your idea) wouldn't be enough because you can't straightforwardly work backwards from the actor to find out if they actually did like the post. It's along the right track though – AP does specify that the likes collection may be provided on an object (in this case a toot) and populated with like activities as a side-effect of receiving like activities which reference it, which seems more feasible for doing this. As I understand it, the likes collection could be used to express the number of likes on a post in a compliant way regardless of whether those like activities were actually made available to other instances (the total number of items property in a collection isn't required to match the number of items available to the requester) I think the problem with using this for verification is that like activities are not necessarily public, and if they're not public, they have to be filtered from the collection (and since they're not public, they probably couldn't be dereferenced against the instance they came from anyway), so there would usually be a discrepancy between the number of likes, and the number which could be verified. The ratio would be different depending on the circumstances, I'm not sure it'd be easy to put the line in a reasonable place. There's some privacy implications too, it'd make who liked what a lot more public. My point of view on this is that like count verification isn't worthwhile, but including the like count with each post could still be. I'm not too bothered by the idea that instances could inflate like counts, it's possible to do this with follower/following numbers already and people do it less than you might expect considering how funny it is (honourable mention to Rune). Not entirely the best of both worlds, definitely not a good result if consistency is your goal, for me it'd be fine. Anyway, actually a pretty good question! |
i don't know what you're talking about. I do not brigade anything. I wrote a blog post and shared it on mastodon. That is just sharing my views. |
this would be possible, yes. but it does have issues as you recognize. on one hand, the Like activities included within should be public (to not leak info), and they should be signed (to allow verification). anyone who cares to verify them and count them can do so. otherwise, you may take at face value the presented incidentally, the items in such a collection do not constitute verifiable claims -- anyone can make up whatever they want. i could claim that you're following me. are you actually following me? i can claim that you liked my post. did you actually like my post? no one can know for sure, unless there's proof. how to establish proofthe way you establish proof is either by having a bidirectional claim or by having a valid signature.
for the case of something like follow relationships, you would have to establish a bidirectional claim, as there is currently no way to attach proof for these relationships. for likes, you could either serve such activities publicly when requested, or you could attach a signature that allows other people to serve/republish it. on the other hand... are you really gonna check all that? all for a like or follow count? you may trust the source to not lie about the numbers can be (and already have been) fakedwe've already seen several widespread examples of people just making up numbers. whether it's likes, follows, followers, users, posts, whatever. all of these counts have been faked before and could be faked at any time without you ever knowing. what's the value in seeing them? sure, some of them are hilariously obvious, like an instance claiming it has the total population of the Earth as an active user count. you might similarly claim to have negative sixty-nine (-69) posts. want some real fun? make it a decimal. the data model says it should be a valid non-negative integer, but even if you validate that much, you have no way of validating further. i could claim 12 followers, or i could claim 1200, and you would never know the difference. so then, as a software or service provider, what do you do? do you uncritically repeat the claim, which may be a lie? are you willing to lie to your users? how to not lie to usersi posit this: if you show a user some information, either it should be true to the best of your knowledge, or it should come with a disclaimer that it might be false. there are two ways to do this:
the former is close to what mastodon currently does. this is why the counts are different than the source. the counts from the source generally aren't taken at face-value (except for following and follower counts, in some cases -- although i argue that we shouldn't do this). the latter is something we could do. we could show a disclaimer on each profile and post that isn't limited to incompleteness, but also takes trust into account. or we could streamline this by changing the wording from "10 likes" to "10 likes (3 verified)". that might complicate the UI, but at least it doesn't lie to the user. you can extend the general idea to the actual contents of those lists. if you have proof or verification that someone indeed liked a post, or someone is indeed following a certain account, then you can show a "verified" badge next to that item on the list. the purpose of such a badge is to signal to users that you have indeed verified this claim to the best of your knowledge before presenting it to them. alternatively, you can treat this the opposite way, by adding an "unverified" badge next to any item on the list that you're 100% sure of. the purpose of such a badge is to signal to users that you're not responsible for the claim -- be wary. your information may be outdatedok, so now what? we have a way to trust and/or verify certain claims. how can we be updated of such claims? this is, in some regards, even more difficult than everything above. you might periodically re-fetch a post and re-check its now you have another problem: how do you know when your local state is out-of-date? how do you know the collection has new items? you need either a consistently-paged Collection, or you need an OrderedCollection (specifically reverse-chronological, so the newest items will be first). if you're not careful, you might have to fetch the entire collection to account for gaps. this is not a big deal for collections with a few items, but once you start getting to hundreds, maybe even thousands of items, it's not going to be trivial. this is getting into #34 territory. etchopefully this helps explain why it isn't as simple as "just get the number from the source". it's a lot. |
|
I don’t understand the specifics of the issue, but the net effect is that a user on mastodon.social has a much better picture of which posts are popular than a user on a smaller instance. Very large user studies by Facebook and Instagram have shown that users feel that their time is less-well-spent when they can’t see like counts (which was a key reason they ultimately decided not to hide like counts everywhere). I recently migrated from a 3000-person instance to mastodon.social so I could see more accurate Like counts, and (very anecdotally, unblinded etc) it has improved my experience. |
If so, why does Yes, to properly honour the targeting of incoming
Yes, dereferencing I have a pet threat model where the Even if vanilla Mastodon were to provide the
I don't know of a Fediverse server implementation that would want to do it, but to give a closest example, Misskey displays |
Pitch
likeobjects are applied to posts, and posts are fetched for newly seen ones (similar to howannounceobjects are handled.likeobjects are federated to all followers (and of course the poster), similar to how replies work.Motivation
Many Fediverse softwares, for example, Prismo and PeerTube, threat likes as important information, so Mastodon should properly handle them. Also, this would further fill out federated timelines, since you'd see all posts that anyone followed on your instance likes, as opposed to only the ones they boost or reply to.
The text was updated successfully, but these errors were encountered: