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.
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.