> Hypothetically, you would 'reduce friction' by not sending email to the service, instead just give it the keys to your IMAP server! We currently use read-onl

> Hypothetically, you would 'reduce friction' by not sending email to the service, instead just give it the keys to your IMAP server! We currently use read-only OAuth, so basically the same in terms of friction but easier to secure. > And users wouldn't need to inform people who email them that their email is public We actually currently require double opt-in permission for each message contributor in a thread to share stuff publicly. That might change in the future, we're still playing around with the model. The new best practice with social apps is basically to launch while erring on the side of having too much friction for the app to be successful, and then keep successively reducing the friction for people contributing positively to the community. Otherwise you risk gaining a bunch of immediate traction but going into the death spiral of negativity, which is the main way that social startups die if they already have initial traction. This wouldn't have worked ten years ago, but it makes more sense in a world where things take off more slowly anyway due to increased network saturation.