Extended Tweet display indices

[richardhyland]

I’ve noticed two things since the new API changes yesterday

1. The display indices are hiding mentions in replies as the prefix, but Twitter website is still showing these parts of the display Tweet. Are we meant to be hiding the mentions from now or is this a bug in the API response at present

2. On an initial mention which doesn’t contain in_reply_to_status_id, the prefixed screen name is still part of the 140 and the display tweet. I’m guessing this is intended behaviour, however does this mean i can only add my 49 additional screen names (to to the maximum) on replies and not new mentions to be counted towards 140 when that part of the API change is rolled out?

[andypiper]

1. The display indices are hiding mentions in replies as the prefix, but Twitter website is still showing these parts of the display Tweet. Are we meant to be hiding the mentions from now or is this a bug in the API response at present

No, there’s no need to obey that indexing for the prefix at the moment - it’s just in preparation for the replies changes to come in the near future. It is not a bug per se, just part of the API response that was enabled at the same time as the attachment update. Apologies for the confusion there.

2. On an initial mention which doesn’t contain in_reply_to_status_id, the prefixed screen name is still part of the 140 and the display tweet. I’m guessing this is intended behaviour, however does this mean i can only add my 49 additional screen names (to to the maximum) on replies and not new mentions to be counted towards 140 when that part of the API change is rolled out?

An initial mention which is not a reply will be included inside the Tweet text. This is correct and the expected / intended behaviour.

In the future, if you were to create a reply to that Tweet using the auto_populate_reply_metadata parameter, then all of the @mentions would be looked up by the server, “moved” to the metadata and indexed out of the display area. The original / first @mention is implied by the Tweet that is first in the replies chain and cannot be removed.

I’ll see if I can come up with a way of documenting this more clearly, as I realise it’s a bit brain-bending when you can’t yet experiment and see the API responses for yourself!

So let’s try this:

First/new Tweet (from @evilpiper)
@andypiper how was the latest Dr Who episode?

All of that counts as text in the Tweet

Reply Tweet (from @andypiper)
in_reply_to_status_id + auto_populate_reply_metadata + tweet_mode=extended
I loved it, especially when the Sontarans destroyed all the Rutans.

Note that I don’t need to include @evilpiper in the body of the reply on the API call, but the replied-to username will appear in the full_text of the Tweet object, and in the user_mentions entities. I get the full 140 characters to use if I want, although I didn’t in this example!

You can carry on adding additional @mentions to the text of further replies until the total hits 50 in the user_mentions entities, at which point they would be silently dropped, or you could edit them down again with exclude_reply_user_ids.

[richardhyland]

Thanks for the reply, so in actual fact you can’t create a NEW tweet for instance that includes 50 in the user_mentions as there probably isn’t enough space, but you could reply to a tweet and add 49 more users to it?

Is that correct as auto_populate_reply_metadata requires an in_reply_to_status_id parameter

[andypiper]

There certainly won’t be enough space to create a new Tweet with 50 @mentions, you’d run out of 140 characters very fast. You also can’t reply to a single Tweet and add 49 users, since again, you’d have no room - consider my reply example - I’ve used 67 characters of text already, so I’d have to add any additional users into the (140 - 67) remaining space. The 50 is an upper limit that could in principle be reached through a series of organic replies involving different people; in practice I doubt that it is something that will be frequently met.

auto_populate_reply_metadata does indeed require in_reply_to_status_id as the initial status is where the reply chain will be looked up from; note the change in API behaviour here, which is that attempting to reply to a deleted or subsequently protected Tweet will now result in an error, rather than an orphaned response with no upward chain.