Because of the error states that can come back from this, we'll keep collection creation a distinct action, separate from publishing.

https://write.as/canary.txt

Should also enable switching between light and dark mode.

Done technically; when we release, we need to announce this in the standard places.

Still need to put a minimum bound on the window, but the editor at least works much better.

This needs to go out only after API support; otherwise we'll potentially get false negatives on isRTL.

On API v1:

Rather than add indices and requiring running writeas list before any operation, if the user gives a partial (<12 characters) ID, we should look up the ID in the local posts file and perform the operation on any matching post. If there are duplicates / ambiguous results, return an error message.

Looking at this again, I'm not sure it's necessary or (more importantly) will do more good than potential harm. If it's requested in the future we'll devote time to it.

This gets less important as time goes on, but we'll keep it in mind just in case we find some time to tackle this.

This is a minor release that isn't as important as 2.0 functionality. I've moved the more important tasks to 2.0 and we'll tackle these issues in the next iteration.

There won't be an explicit sign up form on Write.as. The clients will handle user/Collection creation, so this is covered by the Pad client in T135: Support creating a new alias when publishing a Pad post.

This requires too much of an overhaul of all our database calls, and we can live with hand-written SQL if it means backwards compatibility and stability.

Everything is in place; now certain parts of the app simply need to create the login token and deliver it to the user.

We'll need this to also use with the Write.as CLI when a user authenticates and the option to login through the browser is presented (T193).

OS X should use edit

Will be nice to have when we (and our Tor users) get bigger. Isn't necessary for now.