Hi Brian, Happy to provide feedback. A couple more questions inline, see [CBE]
On Wed, Jan 7, 2009 at 7:37 PM, Brian Hendrickson <[email protected]> wrote: > > > Hi Chad, > > Thanks for the feedback! > > On Jan 7, 1:00 pm, "Chad Etzel" <[email protected]> wrote: >> By logging intohttp://tweetpass.com/api/do you automatically store >> the password somewhere? If so, how is it stored? encrypted? You >> should really tell the users what is happening (even tho it is in >> alpha stage). > > I created this rough draft of the Tweetpass service so that developers > can test the "proxy" API, it doesn't have much end-user-friendly > documentation yet. [CBE] That may be, but I am now curious as to the fate of the twitter password I entered to your site to test it out... I am assuming it must be stored somehow to make the proxy API calls effective? So, what happens to those passwords? > >> Also, the /api/ page does not appear to have <html><body> tags? >> >> It also doesn't appear that I am able to change anything on my >> "homepage" or save it... am I missing something? or is this still in >> implementation phase? > > That's because the first password you see is not "active" until you > make an API call against it. The Activity box is empty, and the Host > says "not in use". Those will light up when you hit the API. [CBE] Ah, makes sense, tho not immediately intuitive.. I think this may be why people haven't tried out the proxy API yet, as they did not know they had to use the API first in order to make their homepage "active" so to speak. Is the idea, though, to limit the activity that can occur from a given host? If so, how do you limit that activity with the checkboxes? Or do they become available once you actually use that particular disposable password...? If that's the case, what's to stop the 3rd party app from abusing that password before I have a chance to go back to tweetpass and configure the usage rights? > >> Logging Out did not actually log me out as I was able to return to >> /api/ without needing to re-enter any user/pass info... > > That appears to be affecting some browsers and not others, quitting > the browser should complete the logout. Seems to be related to my > latest mod_rewrite addition, fixing now... > >> This site sounds like a good idea (until we see what Twitter's OAuth >> looks like), but looks like it still needs some work before it is >> usable? > > Exactly, yes. It's a rough draft to see if the idea is sound while > gauging interest > >> I apologize if my tone seems critical, but this seems like one of >> those services you have to "get right the first time" or risk total >> user abandonment. > > Totally agree with this sentiment > > I can see that many of you have authenticated and created disposable > passwords in my database, but not many hits on the API yet. That will > allow you to see the full service at work, and you could make use of > that disposable password. Don't let it go to waste! :-) > > Thanks again Chad for sharing your ideas. [CBE] Glad to help, -Chad > > -- Brian > > > >> -Chad >> >> On Wed, Jan 7, 2009 at 2:58 PM, Brian Hendrickson >> >> <[email protected]> wrote: >> >> > Hi Twitter-dev-talk, >> >> > I would appreciate your feedback on a new service I've been working >> > on, it's called Tweetpass. I was motivated to get it working after I >> > wrote a comment about Twitter API security on Rahsheen's blog this >> > past weekend.http://sheenonline.biz/-- I decided that instead of >> > complaining I should try to make a difference of some kind. >> >> > Tweetpass makes fresh, disposable Twitter passwords, which can be used >> > at (compatible) 3rd-party Twitter services. (there are none, yet) >> > Also, it makes it simple for the end user to delete the passwords >> > individually, and toggle the API methods individually. >> >> > It works like this: >> >> > Twitter microbloggers: >> >> > a) submit their nicknames athttp://tweetpass.com >> > b) look in their Replies tab and click a link >> > c) do Basic Authentication against twitter.com >> > d) receive Tweetpass passwords to use at (compatible) 3rd-party >> > Twitter services >> >> > e) turn API methods on/off per-password >> > f) delete passwords anytime >> >> > Developers: >> >> > a) change their code to (conditionally) call the tweetpass.com API >> > (see below) >> > b) put the Tweetpass logo on their site >> >> > Twitter API methods: >> >> > twitter.com/statuses/update.json >> > twitter.com/statuses/friends_timeline.json >> > twitter.com/statuses/user_timeline.json >> > twitter.com/statuses/show/ID.json >> > twitter.com/USERNAME >> > twitter.com/USERNAME/statuses/STATUS >> > search.twitter.com/search?q=HASHTAG >> >> > Tweetpass API methods (so far): >> >> > tweetpass.com/statuses/update.json >> > tweetpass.com/statuses/friends_timeline.json >> > tweetpass.com/statuses/user_timeline.json >> > tweetpass.com/statuses/show/ID.json >> > tweetpass.com/USERNAME >> > tweetpass.com/USERNAME/statuses/STATUS >> > search.tweetpass.com/search?q=HASHTAG >> >> > How you can help: >> >> > If you're a developer who happens to use only these few API methods, >> > you can test your service against the Tweetpass API. The simplest >> > thing to do is search and replace "twitter.com/" with "tweetpass.com/" >> > in your code. Then you can proceed tohttp://tweetpass.comto get your >> > disposable passwords. >> >> > Thanks for your feedback and ideas about Tweetpass. >> >> > -- Brian >> >http://tweetpass.com >> > 503.358.7501 >
