yeah - this was inherent in my notion when i was saying that we would send
you to a twitter.com endpoint.  this is similar to how you enable geo right
now on a mobile client -- there isn't an API to do it, but there is an API
to read the state.  the client can send the user to a twitter.com mobile
optimized page to switch it on.

this is clearly a work in progress,

On Tue, Apr 13, 2010 at 6:54 PM, Naveen Ayyagari
<nav...@getsocialscope.com>wrote:

> I can understand the security issue with providing an endpoint.
>
> However, I am not sure there is a lot of value in displaying the
> information in a client, when the user would then be forced to leave
> the application, open a browser, possibly login, then click pending
> requests, then find the user they want to approve from the list they
> had already been reading, then finally be able to take action to
> approve or deny.
>
> Maybe twitter could consider some providing a url that a client can
> launch that would take them directly to the approval for a user.
> Ideally this would work for m.twitter.com and twitter.com
>
> Already there is:
>    http://m.twitter.com/friend_requests
> which asks the user to login and then takes them directly to
> friend_requests page. However it does not seem to be optimized on
> m.twitter.com for mobile clients, and is acutally quite unsightly and
> difficult to navigate on my BlackBerry (The Curve 8310 which is one of
> the most common BlackBerry models in the wild right now)
>
> Maybe friend_requests could be extended to allow something like:
>     http://m.twitter.com/friend_requests/UID or
>     http://m.twitter.com/friend_requests?id=uid
> This would allow a client to launch a browser and twitter to display a
> simple accept/reject page directly without much additional user
> interaction. When browsing on a mobile client, the fewer clicks it
> takes a user to take a specific action, the more likely they are to
> engage.
>
> Actually, a slightly more complex implementation (maybe overkill), but
> may provide better user experience:
> http://m.twitter.com/friend_requests?src_id=uid&target_id=uid
> Where src_id is the uid of the user making the request (i.e. if I was
> using this from my account src_id would be my uid and target_id would
> be the uid of the user I want to approve or reject). By including the
> src_id, twitter can determine if there is a current twitter session in
> the browser and if the src_id is equal to the uid of current session,
> then a login page may not be required and can skip the login step.
> Otherwise, just let the user login, then take them directly to the
> requested approval page. This version simply covers the case where the
> user is logged in as one user on the website, but as a different user
> in a client.. As I said, it may be overkill, and may be acceptable to
> just display an error message if the request is invalid.
>
> I think I was clear, but if not feel free to tear apart my assumptions
> or if there is some security risk I am not considering with this type
> of implementation?
>
> --Naveen Ayyagari
> @knight9
> @SocialScope
>
>
> On Apr 13, 9:06 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> > > Is there API endpoints planned to accept/reject incoming and cancel
> > > outgoing pending requests?
> >
> > no - there is not.  its following the theory that a "malicious client"
> could
> > then accept friend requests to your protected account without your
> > knowledge.
> >
> > > I am curious, what the use case is for a list of ids for pending
> > > requests? Without APIs to interact with pending requests, what would
> > > this information be used for?
> >
> > to display to the end user.  for the end user to take action, a twitter
> > client could redirect them to a twitter.com site.
> >
> > > For a mobile client, exposing this type of information is valuable to
> > > the user, but user objects (not ids) would be required to create a UI
> > > for someone to view and then interact with such requests.
> >
> > users/lookup would help with that.
> >
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Reply via email to