Raffi,

 

I have noticed that the API sometimes returns user ID's that are out of sync
with username. I think one case is where a Alice retweets Bob's tweet, and
then Bob changes his name to Charlie. When I try to reply to it, it doesn't
show up as "in reply to" to original tweet because the reply contains "@Bob"
instead of "@Charlie". It would actually get confusing because a new user
could sign up as Bob and kind of "take over" Charlie's old @mentions that
contain "@bob". Is this change an attempt to address that, by fixing the
screen_name->userid mapping at the time a tweet is created?

 

When we post tweets that include @mentions, can we include our own
entities/user_mentions in our request body, so that Twitter can notify us if
one of the mentioned screen names has a different userid than what we were
expecting and/or one of the mentioned screen names is not a valid screen
name anymore? That would be extremely helpful in dealing with this edge
case-even if it was subject to some race conditions over a narrow period of
time.

 

entities/user_mentions/screen_name and entities/user_mentions/text are
redundant. I would rather just pick the text out of the tweet using original
tweet text indexed by the indices property, to save bandwidth.

 

Regards,

Brian

 

 

Raffi Krikorian wrote:

 

As part of our JSON and XML payloads, we are going to start supporting an
entities attribute that will contain this parsed and structured data.
you'll see it like so:

 

{

 "text" : "hey @raffi tell @noradio to check out http://dev.twitter.com
#hot",

 ...

 "entities" : {

  "user_mentions" : [

    {

      "id" : 8285392,

      "screen_name" : "raffi",

      "indices" : [4, 9]

    },

    {

      "id" : 3191321,

      "screen_name" : "noradio",

      "indices" : [16, 23]

    }

  ],

  "urls" : [

    { 

      "url" : "http://dev.twitter.com";,

      "indices" : [38, 64]

    },

  ],

  "hashtags" : [

    { 

      "text" : "#hot",

      "indices" : [66, 69]

      "url" : "http://search.twitter.com/search?q=%23hot";

    }

  ]

 }

 ...

}

 

as shown above, we'll be parsing out all mentioned users, all lists, all
included URLs, and all hashtags.  in the case of users, we'll provide you
their user ID, and for hashtags we'll provide you the query you can run
against the search API.  and, for all of them, we'll also tell you at what
character count the entity starts and stops -- that should really take the
burden off you guys to parse the text properly.

 

this entities block will probably be extended later, and these entities are
just the start.  have we missed anything?  is there anything else you would
like to see?  as always - just drop us a note, and look for these entities
to start slowly rolling out.

Reply via email to