snarfed
commented
2 years ago Interesting! Twitter v2 API definitely looks promising, I started migrating a bit ago, details in https://github.com/snarfed/granary/issues/136, but full migration is paused for now because it's missing a few things, eg complete retweets.
Bridgy's behavior here is intentional though, due to IndieWeb semantics, not to an API limitation. Direct likes of your post, or of your POSSEd tweet of your post, are different from likes of someone else's post or tweet that merely links to ("mentions") your post. Generally the former would get sent to your post as webmentions, and it would show them, but not the latter.
(Salmentions are a partial exception, they'd result in webmentions for these likes, but the two types still wouldn't be considered equivalent.)
vandie
So as I understand it, Bridgy uses granary which itself uses Tweepy, Which does include the Twitter API v2 endpoint for getting users that liked a tweet as
AsyncClient.get_liking_users.If you test this endpoint via the Twitter API playground, you can see that it is possible to get the users that liked tweets that the oauth user did not post themselves.
This api endpoint is limited to 75 requests per 15 minute when under the user scope (which bridgy uses via oauth). That being said, given that Bridgy polls on a set time interval, it would be possible to only run this if the number of likes had changed on a tweet thus meaning that this limit would be unlikely to be hit for a given user. If more than 75 tweets were liked since the last poll, I suppose it makes sense to get the oldest posts first as the newer posts are more likely to receive further likes.
Could Bridgy not potentially use this api endpoint to get likes on tweets that reference a given URL even when the site owner had not posted the tweet themselves. I ask because honestly, a majority of the likes my blog posts get are on tweets of others that share the link making this a very valuable feature.