hi jim.

that's definitely interesting - i don't think this will make it into the first release, but i like the per-app permissions notion based on oauth. it fits well on the "grant permission read" or "grant permission write" options in oauth in general.


I fully understand the concern about privacy. To that end, here's
something you may want to consider:

Have application / web-site "over-rides" of the geo-code enable be
another option on OAuth. This way a user can control the creation of
geo-coding in their tweets on a finer grain basis.

The profile and OAuth enables would be ANDed: the user has to both
grant permission in their profile and via OAuth to allow a client to
create tweets with geo-coding for them.

If this is done, it may then be reasonable to have the profile default
be enabled rather than disabled, with the OAuth default being
disabled. The user would have explicitly check a box or something
during their OAuth dialogue to grant the client permission.

Just a thought. Comments welcome.

Jim Renkel

On Sep 1, 6:08 pm, Raffi Krikorian <ra...@twitter.com> wrote:
hey jim.

1. "the user.location is a completely separate entity (for now)"
that maybe sometime in the future it may be used, e.g., to provide a
default geo-coded location for a tweet. I would suggest that if the
user's profile location if ever geo-coded, that geo-code should be
to the <user> objects returned by API calls, at least the users/show
method. Users will want to know what may be, e.g., added to their
without having to generate a test tweet to find out.

2. Having the user's profile location geo-coded and returned in API
calls would be very useful now. Yeh, twitter client web-sites /
applications can do it for themselves (Mine certainly will if twitter
doesn't do it.), but may come up with different / inconsistent
And, trust me, it ain't as easy to get good results as it might first appear. To maximize use and consistency, it would be great if twitter
did the geo-coding and supplied it to everyone.

these are both great ideas.  right now, the geolocation API is really
focused on tweet-level information -- but we're actively thinking
about what's next.

3. Will twitter client web-sites / applications be able to turn the
geo-location feature on for their users, or do the users have to go to
twitter.com with a browser to do this? My concern here is that
twitter.com only supports two languages (English and Japanese) for its
UI, where my site (http://twxlate.com) supports these and over 40
Unless the user is fluent in English or Japanese, they won't be able
turn it on. I've already run into similar problems as I'm rolling out
test versions of OAuth support.

unfortunately not.  as we're pretty sensitive to our user's privacy,
for now, a user will have to go to twitter.com with a browser to turn
on the setting (remember, by default it is off).  if you have any
suggestions on how to make this user interaction better in the future,
i would be eager to hear them!

As I've written some pretty spiffy geo-coding applications for other
purposes, I plan on doing some pretty spiffy geo-coding stuff with
twxlate.com. But it needs to be usable, or users won't use it and / or may be annoyed by it. I would hate for that to happen to what promises
to be a really neat feature.

cool!  well - i hope what we're doing is usable!  if not, just keep
blasting me about it.  threads like these on the mailing list are

Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi

Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi

Reply via email to