Auto_populate_reply_metadata includes mentions for special URLs

extended-tweet

#1

When using auto_populate_reply_metadata=true, some additional mentions seem to be added to tweets depending on URLs that are present in the tweet. For example when youtube links are present in the tweet, auto_populate_reply_metadata=true will add @YouTube mentions to the resulting tweet even if the original tweet being replied to does NOT mention @YouTube. I’ve noticed that the iOS native app seems to know this will happen and pre-populates the reply box with @YouTube so the user can delete/exclude it if they want. I cannot find any API that lets me emulate the same behavior - how can I know the FULL list of users that auto_populate_reply_metadata=true is going to be adding to the resulting tweet?


#2

Well spotted. There are some additional details to add to the documentation on this - users named in cards / or tagged in media will be added. However, this feature is not yet live or launched, so anything you are seeing today is subject to change between now and when the replies changes are ready.


#3

Thanks for the quick reply, Andy. Looking forward to finding out more!


#4

Seen this in the twitter web ui, reproduced it with auto_populate_reply_metadata before finding this thread which makes my findings redundant but I’ll post it anyway.

Parent tweet:

Reply posted from twurl with auto_populate_reply_metadata=true

Reply posted from twitter web:

As the tweet says, the “people in conversation” dialog of the twitter web UI mentioned dx_test1 and dx_test2, no mentions of github. So it seems they have the same problem with not knowing what mentions will be included in the final message.

users named in cards / or tagged in media will be added

Clearly the best solution for this is to include the cards payload in all tweet objects for all API clients :smiley:


#5

Thanks for the suggestion :wink: not sure we can make that happen in the immediate future, but I will get the docs updated regarding which entities will be added on replies.


#6

I might be missing it, but I think this situation is still relevant - and now that the new simplified replies have been formally rolled out, it’s even more pressing for us third party client authors. It seems that the auto populate flag still ends up adding mentions automatically based on URLs within the tweet. Users very much don’t expect that to happen and we don’t have any API (that I know of) to fetch the list of users that would be auto-populated for a reply to a given tweet (which seemingly the official clients “just know”).


#7

Wait… maybe this isn’t actually happening anymore after all? Perhaps I spoke too soon?


#8

I believe this relates to cards, which are not included in the Tweet payload. I’d need to test further.


#9

Yeah, looks fixed to me. It was the first thing i tested when I noticed it went live, but I verified again just now with the same examples I used earlier:

BTW, congrats on shipping this feature in a decent state. It’s tolerable, unlike previous iterations. And some of the worst ideas never made it to the implementation (like turning all non-replies starting with @ into public tweets, that was scary)


#10

Just to revisit this. Users tagged in cards are not included, but users tagged in media are. This leaves a slightly annoying situation, since the API to tag users is not currently available (nor is it prioritised on the roadmap), and those users do not appear in the rest of the Tweet metadata. Looking into possible ways to improve this situation, but at present, the way this option works, there are cases where additional users tagged in a parent Tweet may be added by the server.


#11

Hi Andy,

Any update on this, is it going to fix?

Also, I did not find a way to get the tagged users in documentation.
Is there a way to get the tagged users of Media, so that we can exclude them while replying to tweet.

Thank You


#12

There is no API to retrieve tagged users at this time.


#13

Thank you for the quick reply Andy.
So there is no way to exclude the tagged users with this new functionality at this point.


#14

Correct.