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