3 ms·

Ha, that's a good one! Let other people read your email. LOL. Hypothetically, you would 'reduce friction' by not sending email to the service, instead just give

Ha, that's a good one! Let other people read your email. LOL. Hypothetically, you would 'reduce friction' by not sending email to the service, instead just give it the keys to your IMAP server! And users wouldn't need to inform people who email them that their email is public, because once it's on their screen they could post a screenshot to the web anyways. ...oh wait, that's a real thing that you did. You just didn't put the http:// http:// in your comment to avoid self-promotion. After reading your examples (which are a really helpful way of showing what your service does, BTW - thanks for not burying that in a video or forcing me to sign up), I can see the appeal for your service. It's Instagram for email: In exactly the way I keep every photo my phone takes backed up and organized on Google Photos, but selectively post to Instagram, I could selectively send mail on a "social email" account and keep normal transactions private. Fascinating! I suppose I have a small portfolio of emails helping some people solve problems (running/cycling tips, local routes, etc and some tech support) that I have meant to post to a blog but just never got around to it. Making that blogging automatic would be neat! Nice idea and implementation, I apologize for mocking it! I'll definitely keep the principle in mind.

Alex3917 8y ago
> 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.

Alex3917 8y ago

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