like
objects are applied to posts, and posts are fetched for newly seen ones (similar to how announce
objects are handled.like
objects are federated to all followers (and of course the poster), similar to how replies work.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.
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 like
objects should be accepted (and added to posts as announce
objects are) instead of being ignored.
I would like to see at least the amount of likes a certain post gets.
Small instances might always see the favourite counter of a post at 0 until the user favourites it, which kind of defeats the reason for a counter.
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 as:Public
, like they currently are, they should go into the outbox and be properly federated.
If likes are
as:Public
, like they currently are,
Likes are not currently addressed to as:Public
. They are not even included in the outbox. To verify this, check any user's outbox. You will only find Create and Announce activities.
a la Facebook's "{user} liked a post by {otherUser}"
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 Like
activities that target posts made by remote users.
It's requesting two things:
Like
objects targeting remote posts by attaching them, not discarding themLike
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)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 notifications@github.com
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
https://github.com/tootsuite/mastodon/issues/11339?email_source=notifications&email_token=ACQ5OX23FXSC7WOSGOJEYBTQES34TA5CNFSM4IETZIM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4KUQHY#issuecomment-521488415,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACQ5OX2WDZYPIUJ6IGW5CTLQES34TANCNFSM4IETZIMQ
.
the former could work
Since I was mainly arguing for the former, should I make a new issue for it or is this one enough?
I am quite new to GitHub issues, apologies for the newbie question.
frankly it's not anyone's business what i choose to Like, except for the person who owns the object.
Then why is it labelled as:Public
?
@TemporaryUsername12481 can you give a live example of a Like
from Mastodon addressed to as:Public
?
Favorite a public post. That like
is as:Public
, anyone on your server or the server where the post originated can see it.
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)
if you cant see the total counter of boosts and favourites you dont really need those features cause you can just Bookmark it.
At least a option to "opt-in" to a "Global" counter would be nice so you dont need to check the orignal instance if you want to know more about the activity of the toots.
Most helpful comment
I would like to see at least the amount of likes a certain post gets.
Small instances might always see the favourite counter of a post at 0 until the user favourites it, which kind of defeats the reason for a counter.
It doesn't necessarily need to behave like boosts that bring the toot that has been interacted with to the timeline.