This change has been a long time coming. Originally, we asked for write permissions because it wasn't possible to upgrade from a read token to a write token at a later date, and we needed a small subset of write operations (primarily follow/unfollow, but we've also experimented with updating Twitter lists).
Earlier this year, Twitter made it possible to request either kind of token when making the initial OAuth request. We tried to implement read-by-default, upgrade-to-write against this but it turned out not to quite work - a user could upgrade to a write token when we prompted to them, but then if they attempted to sign in to the site in the future Twitter would prompt them to downgrade to a read-only token.
So in the end, we implemented it using a method we could have all along - by setting up two different Twitter OAuth applications (called "Lanyrd (read-only)" and "Lanyrd (full-access)") and doing our initial signin auth against the read-only one, then asking for read-write permission against the full-access one when the user first attempts a write-requiring action.
I'm very glad we've solved this now. It was only a small vocal group that complained about us asking for too many permissions, but they absolutely had a point.
Thank you very much for explaining the technical reasons that make this difficult, and thank you for continuing to seek a solution despite those difficulties. As someone who cares about what permissions sites ask for, I appreciate you fixing the problem, and I appreciate even more that you've concisely explained the solution in a way that other sites can more easily act on.
Nice to read that somebody actually cares about the permissions they ask and provide a careful approach to asking the user the appropriate permissions when needed.
While I applaud this decision something struck to me as BS:
> Twitter's JavaScript follow button isn't appropriate for us for a few reasons: firstly, it requires JavaScript (almost all of Lanyrd's functionality works both with and without JavaScript turned on)
Is Javascript really an issue in 2012? I mean, people can hardly use Twitter.com itself without JS turned on.
In part, it's a matter of stubborn principle. I don't like the way the web is trending towards JavaScript being required for most websites, and I'm determined to lead by example with Lanyrd.
That said, there are sound technical reasons for working without JavaScript. Our mobile web app, http://m.lanyrd.com/ uses pushState and HTML5 offline caching if available, but falls back to working as regular HTML pages if JavaScript isn't available. This made it easy for us to add support for older devices, particularly older BlackBerrys, which choked horribly on our JavaScript - we simply avoid executing JS on those devices entirely, giving them a perfectly functional degraded experience with very little extra development work needed.
> Is Javascript really an issue in 2012? I mean, people can hardly use Twitter.com itself without JS turned on.
Perhaps not twitter.com, but there are other ways to use twitter. (I use a command line python app (pytc).) So, it is quite feasible to browse with JS disabled and still use twitter. I like that websites have a fallback, so good on Lanyrd.
Prettiness is subjective - I like our current design, and we've had a lot of praise for it, but clearly it isn't to everyone's taste. We've recently expanded our design team so we'll be making a bunch of changes in the near future.
We're useful in helping people figure out which conferences and events they should be going to. We have comprehensive event listings for a wide range of different topics (try http://lanyrd.com/topics/user-experience/ or http://lanyrd.com/topics/web-design/ or http://lanyrd.com/topics/startups/ or http://lanyrd.com/topics/ios/ for example). If you sign in with Twitter we'll show you events the people you are following are speaking at, attending or tracking which we've found works extremely well as a recommendation mechanism. You can also subscribe to emails with suggested events so you don't have to keep visiting the site.
For events that we have a schedule for, our iPhone and Android/Mobile Web apps will store it offline so you can quickly check what's happening during the event.
If you're a conference speaker, you can use us to build up a profile of the talks you've given. Here's mine: http://lanyrd.com/profile/simonw/
If you organise conferences, you can use our speaker profile pages to find speakers for your events (and watch videos of their presentations to see if they'll be a good fit), e.g. http://lanyrd.com/profile/paulg/
Finally, we're building up an index of slides, notes and video from talks. If you want to learn Scala for example, our collection of Scala talk videos might be a good place to start: http://lanyrd.com/topics/scala/video/
We're a YC company (Winter 2011) that helps people get more out of conferences and professional events, by finding the right events to attend, meeting the right people at the event and catching up on slides, notes and video afterwards.
If you sign in to Lanyrd with Twitter we'll suggest events to you based on the people you follow - including events your contacts are speaking at, attending or just tracking through our site. Give us your email address and we'll send you a semi-frequent email with new events your contacts are interested in.
You can also browse the site without signing in at all, or subscribe to our RSS and iCal feeds. Here are some of our lists of upcoming events:
Finally, we have mobile apps designed to help you keep up to date with the schedule, speakers and attendees while you're at an event. We recently updated our iPhone app http://lanyrd.com/iphone/ and we're currently working on a new version of our Mobile Web / Android app http://lanyrd.com/mobile/ - both iPhone and Mobile Web apps use offline storage so you can still see the schedule etc even if you're travelling abroad or are on dodgy conference wifi.
Earlier this year, Twitter made it possible to request either kind of token when making the initial OAuth request. We tried to implement read-by-default, upgrade-to-write against this but it turned out not to quite work - a user could upgrade to a write token when we prompted to them, but then if they attempted to sign in to the site in the future Twitter would prompt them to downgrade to a read-only token.
So in the end, we implemented it using a method we could have all along - by setting up two different Twitter OAuth applications (called "Lanyrd (read-only)" and "Lanyrd (full-access)") and doing our initial signin auth against the read-only one, then asking for read-write permission against the full-access one when the user first attempts a write-requiring action.
I'm very glad we've solved this now. It was only a small vocal group that complained about us asking for too many permissions, but they absolutely had a point.