Twitter Likes for Posts not by oauth'd user via the twitter API

[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.

[snarfed]

Interesting! Twitter v2 API definitely looks promising, I started migrating a bit ago, details in snarfed/granary#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]

Salmentions do look interesting. Wasn't aware of this particular distinction but it does make sense and I'd imagine pushes this outside the scope of anything on the table for bridgy.

For my own direct twitter integrations I'm having to use a combination of v1 and v2 api endpoints. I think using the v2 endpoint for this feature specifically does help avoid the scraping issue that is currently faced

[snarfed]

Feel free to check out #458 for more background on Bridgy + salmentions! And scraping isn't really an issue right now, we can already fetch anyone's likes with it, not just authed users, but v2 will still be good eventually. Feel free to follow snarfed/granary#136!