FWD:Everyone
fwdeveryone.com
fwdeveryone.com
- 99%+ of non-commercial email threads now parse correctly, better than Gmail in most cases. E.g. check out the inline reply parsing here: https://www.fwdeveryone.com/t/Gb8CYKvGS6uFSXdb_hwiTA/blog-po...
- We now support oEmbed, so you can embed email directly within Reddit and Medium posts. And also within Confluence, your own site / blog, and hundreds of other places. C.f.: https://www.reddit.com/r/nyc/comments/87a7my/restaurants_wor...
- The site now works really well on mobile and tablet.
- We've added organizations. Organizations can have public and private repositories. When publishing email to a public repository, by default permission request emails only go out to non-members of the organization. (And permission is never required to publish stuff to a private repository.)
- You can now anonymize any message contributor. Anonymized message contributors don't receive permission requests. Users can later anonymize or de-anonymize themselves at any point. (This works even if message contributors haven't yet created an account.)
- Threads are now SEO optimized. We basically take all the incoming garbage HTML that is modern email, and output it as really clean and minimalist HTML. (This also ensures that the redaction feature never breaks.)
- We now have pretty decent video tutorials: https://www.youtube.com/watch?v=Zwh9TJWoG6k&list=PLJAEYmnEjI...
- Users and organizations now have RSS feeds of their email, e.g.: https://api.fwdeveryone.com/user/inbox.atom?username=alex391...
- Lots of recirc features, e.g. trending threads.
New features in the pipeline:
- Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.
- The front end is being completely re-written in React. Right now the front end loads in about 800ms, we're hoping to get it down to half that or less. (In comparison, the oEmbed loads in 80 - 130ms, hard to get much better without changing the speed of light.)
- We're building a Gmail plug-in. This will allow people to publish directly from their Gmail, and it won't require read-only access to the user's entire inbox. (Even though our privacy policy is very good!)
When we built the site we knew that no one needs or is looking for a new social network, so we figured that we aren't going to get many sign ups until people have read at least 100 really good threads on the site. We're not quite there yet, in terms of having enough content and traction for this to be a real business yet, but we're trending in the right direction and I'm hopeful we'll be close by the end of the year.
But yeah, overall we're basically just trying to make the Internet fun and weird again, the way I remember it when I was a kid but with a more modern twist. And also a real business model, no BS advertising, ever.
Also, for all the stuff that gets published about how addictive social networks are, try actually building one; nothing is more addictive (or inspiring) than a blank page.
I've been on the home page a few times and haven't yet signed up.
My behavior on the homepage has been to click the "more example threads" button.
I'd guess that the thing that would make me more likely to sign up is to be able to see/discover more great threads before signing up. (Similar suggestions that people have given to twitter, i.e. provide max utility for logged out users so people who aren't yet converts can experience the magic. I think that might apply to your site)
Hope this helps and I'll look forward to seeing the site succeed!
Tl;Dr I'd personally be interested in seeing more cool threads on the homepage and perhaps displayed in a way that makes it easier to find ones that are particularly interesting to me, so that I can get "hooked" on the service.
(Makes me think of Chamath's talk, where he talked about facebook's magic moment being 7 friends in 10 days https://ryangum.com/chamath-palihapitiya-how-we-put-facebook... - I wonder if your magic moment is getting people to discover a thread that is both really useful or interesting to them and that they feel is secret/that they likely wouldn't have been able to find elsewhere on the internet)
Thanks! Expect to see more content in the near future.
And we definitely need to redo our front page and incorporate more cool content. It's a lot better than when we launched, but I feel like we haven't quite hit a level of professionalism that's reflective of the rest of the site.
We’re trying to avoid raising capital, so what we’re really looking for right now is a larger company (1,000+ employees) to adopt us for a year so that we can keep evolving the internal tooling and make sure it’s satisfying a real need. (If anyone is interested, send me an email.)
Do you even have a sharepoint add-in?
This is horrible! I mean, people can always be jerks, and publish private email. But you're facilitating that. This could readily be used, as an example, as a type of revenge porn. Sure, victims can anonymize themselves. But only after the information has been published, and potentially scraped. And you know that jerks will be scraping your site, for just this reason.
The default must be requiring explicit permission from all participants. Without permission, even anonymization is insufficient to protect against abuse.
That's still the default. There are lots of legitimate use cases for publishing stuff without permission though, e.g. emails from Steve Jobs or whatever.
Normally when social sites get a lot of traction and then die it's because they go into a death spiral of negativity: e.g. Secret, Whisper, Yik Yak, etc. The best practice for avoiding this is to err on the side of too much friction when launching, and then to reduce friction for people who are contributing positively to the community.
That's basically the model we're following. The whole point of the site is to showcase positive interactions between people. E.g. showing conversations between VCs, between academics, lawyers, etc. I think the site is too wonky to get overly negative, but if it starts going that way then we'll be very quick to change things up again.
That's good to know.
> There are lots of legitimate use cases for publishing stuff without permission though, e.g. emails from Steve Jobs or whatever.
Just because he's dead, and was a public figure, is it morally acceptable to publish private email? Or even legal, without permission from his estate?
A quick search gives me the following.
https://blogs.findlaw.com/law_and_life/2018/04/is-it-legal-t...
https://writersweekly.com/this-weeks-article/legal_emails
https://law.stackexchange.com/questions/3980/is-it-legal-to-...
Edit: Also:
http://nulawreview.org/extralegalrecent/do-not-forward-why-p...
I love to read correspondence from folks like Newton[1] for example and I want my grandchildren to be able to read Jobs exchanges as well.
[1] http://www.newtonproject.ox.ac.uk/texts/correspondence/all
Edit: Perhaps there's now legitimate public interest for most everything about him. But maybe some Apple-related stuff is still off limits.
With respect to copyright, when you send someone an email you're using an agreed upon protocol (RFC 5322, RFC 5598, etc.) that implicitly grants the recipient a copyright. Now you can say this is a bad argument because no one ever reads those, which is true. But if this weren't true legally, then every time you replied to an email it would be illegal since (in most clients) the full text of the previous email gets copied below the new text. Users also can't really use the platform to violate the copyrights of third parties (e.g. by attaching music or whatever), since the platform is tied to their email account.
From an ethical perspective, the reason we specifically excluded whistleblowers as a user story is that you can't build a sustainable business around it, since you can only be a whistleblower once. we've designed it to force uploaders to have skin in the game. E.g. they can't anonymize themselves, and they're forced to link their Gmail accounts. I think that's enough to prevent the vast majority of bad behavior. E.g. you could also copy and paste someone's private email into a HN post, but it's just not done. The only thing we really do is make the process easier by letting people making redactions, anonymize people, send permission requests, etc., but that's not exactly a selling point for people who would be egregiously abusing the site.
I had no clue that email protocols "implicitly grants the recipient a copyright". What are cites for that? Neither https://tools.ietf.org/html/rfc5322 nor https://tools.ietf.org/html/rfc5598 includes "coptright" except in the "Copyright Notice".
But anyway, I get your point about "forc[ing] uploaders to have skin in the game." Maybe that will be enough. Because, as you say, there are many other ways to leak confidential stuff.
But anyway, sorry about taking this down the legality path. It is a cool service that you're providing. And I would never argue that you're legally responsible for what users do. I'm just concerned about the abuse potential.
Maybe you could enable publication without explicit authorization only when all correspondents were registered users. That would encourage users to get their contacts to register, increasing your userbase.
Replying is always legal (copyright-wise, at least, notwithstanding other laws that might prohibit it for some other reason, e.g. CANSPAM), so long as your reply does not include my original message or a portion thereof (aside from parts that I didn't really author in a meaningful way, e.g. email headers).
Replying with quotes, forwarding, or sending a paraphrased/summarized equivalent to my email may or may not be automatically legal depending on your jurisdiction's laws around fair use. Unless you know that it falls under fair use, it's almost certainly safer to treat it as illegal without prior authorization.
It's also not a necessary condition because an internal company mail server wouldn't run into copyright issues since the company owns the copyright on all their employees' work.
"Uploading a copyrighted work that I downloaded via GET with POST must be legal otherwise HTTP would be illegal."
My point is that when you send someone something you've written as an email, it constitutes an informal agreement (essentially a private contract) with the recipient.
> It's also not a necessary condition because an internal company mail server wouldn't run into copyright issues since the company owns the copyright on all their employees' work.
That's true, but anyone with a company email address is legally considered a representative of the company. (That's why you always need to deactivate people's email addresses when they leave.) So while the company (almost) always owns the copyright over work created, the employee is able to dual license that content by sending it via email.
Anyway just to be clear we're not saying you should go ahead and dox all your friends. We're not ad supported, that doesn't benefit us at all. (If your first experience with the site is getting doxxed, you're probably not going to sign up, and almost certainly aren't going to start paying for the business product.)
Is there any precedent you're basing this opinion on? Because it's not like your company just gets to decide this.
What are the terms of this supposed contract? If JK Rowling sent you the text of Harry Potter do you believe you have the right to distribute it through your site?
Do you believe that there would be a meaningful difference between Netflix sending you the same bits over email vs HTTP?
There's no clear precedent. Clearly a judge isn't going to let us host a PDF of Harry Potter or whatever. If it ever came down to it I think there would just be a multi-pronged test, along the lines of the current test for fair use and securities law.
In the case of Harry Potter it's an exogenous work that was created and copyrighted outside of an email client, it has significant economic value on its own, and there would be substantial economic harm done from us hosting it. In the case of normal email conversations most of those factors wouldn't apply, especially since in many cases seeing how people interact with one another is more valuable that the content of any individual message.
Regardless, I paid my $6 to the library of congress to become a registered DMCA agent, so the copyright issue really doesn't apply unless we A) start ignoring DMCA takedown requests B) actively induce people to violate copyright.
That means:
- copyright is still with the sender (or their employer)
- no rights to publish the message.
The users of your service will regularly violate copyrights if they didn't get explicit permission to publish.
Check out section A of http://nulawreview.org/extralegalrecent/do-not-forward-why-p....
If you send me an e-mail, absent an NDA, I generally have permission to disclose it to third parties. If FWD:Everyone required permission from all participants, they would simply fall prey to FWD:Everyone2 who didn't.
https://injury.findlaw.com/torts-and-personal-injuries/invas...
My guess is that forwarding would be fine but publishing wouldn't (in the US) and that you as an end user don't have to worry about the GPDR.
Examples of illegal behavior would be publishing it, forwarding it to a marketer, or eg. for a recruiting agency forwarding to a company fir which I haven’t given permission.
While technically true, I remember the days when publishing private messages was considered heinously rude. We didn’t need disclaimers and contracts and legalese for everything, because people - even on the Internet - behaved like decent human beings.
Before you use this service, I recommend to verify that it is legal in your jurisdiction to use this. E-mail, by default, is meant to be private (though the "private" aspect can be organization A plus customer X or organization A plus organization B or sysadmin logging the conversation and backing it up). If its meant to be public, there are mailing lists for that. And if GPG is used to encrypt the content, it for sure isn't meant to be shared!
Permission from whom? Certainly not from me.
If I e-mail a support engineer who is helping a customer with a problem, I expect they may tell the customer everything I say.
If I e-mail a colleague saying I'm worried our new product isn't up to our usual quality standards, I expect them to share that with other insiders but not risk embarrassing the company by releasing it publicly.
If I e-mail HR asking if our medical insurance covers syphilis, I expect them to keep that private even from other insiders :)
This is one of those cases where the CS logic of "If I can show one person I can show n people" doesn't apply.
[...]
> - Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.
This is a really an abuse of trust. When I send an email, I expect it to exist for a certain audience that's it. If I wanted it to be public, I would have posted it on a public forum. It's not up to the recipient to decide what should be done with my content. I'm the one that decides that. If you want to get legal about it, as the author, the copyright is mine, not the person I send it to.
Not only are you running afoul of privacy, and abuse issues, you're running afoul of legal issues.
This is a really abusive idea.
Are you sure about this? I doubt that communication can be copyrighted. Once you sent me your email, it's mine, not yours.
Otherwise email forwarding in general is completely illegal.
First of all, the author retains ownership of the copyright. They can freely redistribute copies of what they have written unless they're subject to an active contract limiting their use of those rights (e.g. a time-limited exclusive license -- IANAL but AIUI there is no such thing as a permanent exclusive license unless you also get perpetually reimbursed).
So if you're sent a copyrighted work by its author, you may legitimately infer that you have the right to access it but you don't have the right to republish it or make copies accessible in any commercial way (like an ad-sponsored online platform).
Additionally communications are subject to privacy laws. So you may be in violation of the author's personal rights even if you publish their e-mails non-commercially because you violate their "reasonable expectation of privacy".
This is not entirely dissimilar to the case of "revenge porn" by the way: if you send your loved one an intimate picture for private use, you can not only ask that they destroy the picture at any point but they are also prohibited from publishing it without your approval. Of course in this case the violation of personal rights also stems from the fact the photo is a depiction of the author.
But if you really need a clear example, imagine you are sent the draft of the next Game of Thrones season (or what have you) by its author. Unless you have explicit permission, you have no reason to assume you would then be allowed to go on and publish that document. Even without an NDA there's likely a "reasonable expectation" you will treat it as confidential and you'd be in violation of that by passing it on.
Note that I'm talking about my understanding of German (and likely by extension EU) laws, not necessarily American laws. I'm well aware the US has different laws and I suspect those might vary on state level too.
If you're not sure whether the author of an e-mail is okay with it being forwarded, maybe try asking them? If you don't think they'd allow you to (and there's no legal reason to ignore their wishes, e.g. to submit the e-mail as evidence of harassment), maybe you shouldn't?
"Once you sent me your email, it's mine, not yours."
"Once you let me download Star Wars, it's mine, not yours."
Email forwarding in general isn't illegal. There are plenty of times where you could forward an email where there are no issues of copyright. Like an autogenerated notification for example, that email wouldn't be copyrighted at all. On the flip side if I send you a copy of my book in an email you certainly don't have the right to forward it as that would be an unauthorized reproduction. The question is generally where certain types of personal and professional communication fall.
"Are you sure about this? I doubt that communication can be copyrighted. Once you sent me your email, it's mine, not yours."
If you and the recipient both reside in countries which are signatory to the Berne Convention, then this is very much incorrect. Copyright is automatic, and goes to the author. The medium by which I distribute my copyrighted works does not somehow invalidate that automatic copyright.
"Otherwise email forwarding in general is completely illegal."
In a strict sense, yeah, probably. This is why the FSF and OSI don't consider programs without any license to be suitable for FOSS: in the absence of a license, most countries - thanks to the Berne Convention - assume no permission from the copyright holder at all by default unless otherwise established via a license agreement.
Of course, the average person is not going to start suing you for every email from said person you've forwarded without explicit permission; indeed, the average person probably won't know you've ever violated that implicit copyright at all if you're only forwarding it privately. That dynamic changes entirely, however, if you then go on and publish that email as part of a blog post.
hello@fwdeveryone.com
I recall an app that (I want to say it was for Mac) that turned the trash into a recycle bin and actually "recycled" the content in the sense that files were then sent to other users to look at and if they took them out of the trash the file was gone for everyone else (as if it was a physical print out).
It was kinda neat... weird... probabbly a security nightmare... but interesting.
- Tokens can only be used from our servers, and their use is logged by both us and Google
- Tokens are rate limited on Google's end, both per user and per app.
Both of these combine to make any sort of large scale breach essentially impossible. We also don't access and store any email messages until you've already chosen to publish them, and even then they're stored encrypted unless they're publicly accessible. (E.g. the remain encrypted if not everyone gives permission or if you're publishing with a private repository.)
I filed a feature request ticket with Google asking them to log when an app accesses a full message, so that way we can prove that we aren't accessing any emails except the ones you choose you upload. So we'll see if that gets added.
We also have very extensive tests for everything privacy and security related on the back end, which helps.
The main thing to note is that we're explicitly not designed to be a platform for whistleblowers. One of the design decisions we made is to associate threads with email addresses rather than usernames. This is useful because it let's people give permission or anonymize themselves without first making an account, and then later have their threads associated with their account. Great for usability, but it also means that if you want to be an anonymous whistleblower there are other platforms that are better suited for that.
Anyway once we have the Gmail Add-on, that will make it so we only have read-only access to the currently active thread where you activate the add-on. It's only a couple weeks of work, right now I'm just hoping we can get Google to add a couple more API wrappers so that we don't need to write any new code to parse threads.
The other option would be to have threads go live in X hours unless someone opts out. Right now our main goal is to have the permission options be clear, intuitive, and consistent so that people start to build up a mental model of how it works.
There's a need for this. Please build it.
"neither scenario has materialized yet."
Well yeah, it's a young product. Only a matter of time before it's abused.
"The other option would be to have threads go live in X hours unless someone opts out."
Substitute "hours" with "days" and I might be okay with this. "Hours" is way too short.
It's a bit of a pet peeve for me to see pages like this that are primarily static but are not accessible without JS, but I can understand that making a page built with a JS frontend work without it might be more work than it's worth, at least for an early stage project.
However, you really should put up some sort of notice to users - while being able to read a short blurb about what the site is nice, even just "<noscript>This site requires Javascript to view.</noscript>" is better than a blank page or permanent loading screen.
There is actually a bunch of animation and interactivity on the site though. E.g. if you click on anyone in a thread, you see their bio and their other threads. And when you hover over a user’s popsicle stick on the newsfeed it pops up, which is stupid but oddly satisfying... We tried to give it the feel of popping bubble wrap.
Anyway prerendering more stuff is on our roadmap, so once that’s set up we can reevaluate.
alex.krupp@fwdeveryone.com alex.sheehan@fwdeveryone.com
In general though there is no max length on the passwords and all characters are valid.
For plaintext emails without forwards, we use a slightly modified version of Email Reply Parser to strip replies. We made a couple changes so that messages with inline replies aren't stripped.
The next step is running everything through through BeautifulSoup. We use this to strip out most of the garbage from the HTML and rewrite it to make it beautiful. For example, paragraph text within divs gets unwrapped and placed within paragraphs. And text within divs that's styled to look like blockquotes gets placed within actual blockquote elements. This is not only good for SEO, but makes it easy for us to normalize the typography and style across threads to create a consistent reading experience.
There's also some logic here for formatting emails from things like Zendesk and Mixmax correctly. And this is also where the highlighting and redaction get applied.
Right now we just unwrap text within tables and place it in paragraph elements, I need to change this algorithm a little though to allow actual tabular data.
The next step is running the text through Bleach, first to linkify any plaintext URLs (and sanitize URLs), and next to remove all the remaining markup and attributes we don't allow.
Then you enter the death field of regex. The algorithm we use to unwrap text within divs and tables creates some extra whitespace before and after the newly created elements, so when you have nested divs and tables some of this needs to be stripped. We also strip out semantically invalid markup and empty elements. E.g. there is a lot of stuff that looks vaguely like this:
body = body.replace('<li></ol>', '</ol>')
The last step is that we run everything through BeautifulSoup again to make sure the whole thing is idempotent. I hear this isn't the Computer Science approved method of guaranteeing idempotence, but in this case it works. (Basically there are just a couple cases where the regex can lead to having unbalanced tags, so we need to make sure it's valid markup again.)
Overall the whole process is pretty easy to read and understand, and it generally produces better results than Gmail so I'm pretty happy with it. If we were processing millions of emails per hour I'd probably put more work into making it more efficient, but for now it's fast enough to feel instantaneous even for threads with dozens of messages.
Unless permission requests are mandatory and forever will be (regardless of anonymization), I will automatically refuse to communicate via email (and possibly any other implied-private medium, including one-to-one chats, mail, and SMS) with anyone I know to be using this service; instead, the only communications from me with these people will be through systems/services in which communications are already assumed to be public or shared (e.g. forums, mailing lists, public social media posts, blog posts / webpages, etc.). Likewise, I will never use this service myself; there are plenty of services out there that facilitate public-record written electronic communication while being upfront about it.
To reiterate: my emails to others should be considered private between myself and the recipient unless both of us explicitly consent to their publication, anonymized or otherwise. That's basic fucking courtesy - courtesy which FWD:Everyone seems to be explicitly designed to violate.
https://news.ycombinator.com/item?id=17401425
> 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.
And yes, it does violate basic expectations - that's on purpose.
"Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment."
It requires opt-in from all parties now, but there's already a publicized plan to change that.
"And yes, it does violate basic expectations - that's on purpose."
I'm not sure how "don't worry guys, we're intentionally building a product to facilitate the wholesale violation of decades-old email etiquette and common courtesy" is supposed to make this idea sound any less horrific.
E.g. Gmail has a reply all button and a forward button, but they don't encourage users to abuse them. They're just there for situations where it's (hopefully) appropriate, and they trust users to exercise good judgment. And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails.
There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed.
Last I checked, neither of those buttons are designed to publish the whole conversation to the whole world via the World Wide Web. Your product is. Therefore:
"we're changing the product to make it possible to upload stuff without permission"
Then you're changing the product in a way that is absolutely unacceptable for privacy reasons.
"we're not trying to induce bad behavior"
I'm not trying to induce meth addiction; I'm just selling it and hoping it won't be abused.
"And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails."
Then you're missing the point: I want to minimize the potential for abuse to ever happen in the first place. Hence the ultimatum in my top-level comment: if I know someone is using this service, then I'm going to refuse to communicate with that person via implicitly/semantically-private channels (in fact, it'd be nice if there were some way to programmatically get a list of email addresses registered with this service so I can maintain a blacklist on my SMTP servers and prevent myself from sending anything to them by accident). I might waver from that if FWD:Everyone offers the ability to preemptively register my email address(es) in an "automatically deny permission" list.
"There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed."
Then that request for verbal permission should be along the lines of "hey, I want to post our conversation from a while back to FWD:Everyone; do you mind logging in real quick and approving it since the request probably went to your old email?". Even better if FWD:Everyone would keep track of who owns what emails and send requests to alternate emails if not approved in a certain amount of time.
Otherwise, tough beans. Just because Disney didn't respond to my email asking for permission to sell bootleg copies of Frozen on the black market (e.g. because I sent it to the wrong address or because it's obviously going to be a "no") doesn't mean I'm automatically allowed to do so.
In other words: if I'm unable to provide consent, then assume that I do not consent. Inconvenient, sure, but that ain't my problem.
No way I'll use it, nor allow anyone else I know to do so.
I'd still be skeptical.
It's just a fancy mailing list then? Minus the SMTP leg, plus privacy/consent issues and moving to a non-free storage format as well as concentrating the presence of the "thread" at one site.
The best email lore out there is saved to mailing list archives and can be linked to and shared just as easily. And mailing lists take "forwards" too.
For corporate customers who want to publish into an org, rather than the world, this service might actually be very valuable. For non-corporate uses this might make some sense, but for me... I'd not let a third party read my email.
It's more of a social network built around email conversations. E.g. we make it easy to not only to leave comments and share on social, but also to embed threads within any other site.
Unlike email lists, we're also designed to make it easy to share great conversations after the fact, rather than having everyone copied on every message as it happens. I think one good use case for the site is sharing the best conversations from otherwise private mailing lists. (With everyone's permission, or if the list specifically allows it.)
> moving to a non-free storage format
If you look at the API response for our threads, it's actually much easier to parse than any archival format.
That said we're not (currently) an archival product; we don't store the original raw messages, and we don't output them into archival formats designed for longterm storage. I would like to integrate with some archival products in the future though. Right now when you donate your email archives to a university, they are only readable in the reading room of the university after signing an NDA with the librarian. I think we offer a good solution for making it easy to redact some of the more interesting threads and get them on the web, and I think a lot of that stuff would be super interesting.
Putting content in a blog post means the author thought the information was worth at least copying and pasting (and possibly even editing). A lot of blog posts aren't even worth the time reading the title. This is somehow less than that.
I think this is a truly terrible idea. But what do I know? google thought it was a good idea to have copies of the usernames/passwords for all the sites I visit stored on their servers. I think that's also a truly terrible idea - but they're a billion dollar company.
I would never use (to share) and I am doubtful I would find any thread between two other people worthwhile. But if they can find a paying userbase, mazel tov.
Also, when our Gmail plugin gets released the OAuth story will be much better. Basically they have a scope that's read-only OAuth, but the plugin only gets access to the thread that's currently open when the user activates the plugin for that thread. That's exactly how it should work. There are still a couple features missing, we can build it without them but we're trying to work with Google to save some duplicated code on our backend.
Email would only be viable if it was a self hosted script. You're not getting access to my IMAP server. Duck that.
Further, I don't think everything is "communityfiable". Like I said earlier, interesting conversations don't happen often, so stuff like following a person due to his one email upload or whatever, recommendations etc all seem a bit too much. Following would make sense if it is someone who uploads stuff often, but in this case anyone who does it would be breaching someone else's privacy unless the uploader is part of the conversation and everyone agrees to share it. But, again, as I said earlier, interesting conversations happen only once in a while.
That said, I remember how twitter was derided in the beginning as being a platform for people to share boring stuff that no one cares about, but it turned out to become something else, though not by design but only by chance, and is now quite successful.
Use cases I think are especially compelling:
- Industry leaders who get asked the same questions a lot
- Professors and notable intellectuals who already give their email archives to a university when they die, and would like some of the accessible on the web.
- Politicians. Their emails are already published under FOIA, but I think it would be super useful to folks campaigning also.
- YouTubers, bloggers, Twitch folks, etc.
And then there are dozens of business use cases also for sharing stuff internally.
I’m sure there are lots of other uses beyond these though!
Mails are replied to, mails are forwarded, long chains of emails happen, your stuff gets out.
A colleague at one of my first work places made fun of a client. 10-20 replies and forwards later, his mail was sent to a client. Luckily I think his message was buried too deep in the resulting mail and the client didn't see it.
I did, though, as did several people from my team. We didn't say anything but we all learned a lesson that day :)
Before then, you would reply to points in line and trim unneeded information. The entire conversation wasn't bolted on to be ignored by 99% of people.
Just don't write offensive stuff :)
Alternatively just send us an email and I'll delete it.
You can see this in action in this video: https://youtu.be/MqbTUDCvYB8
That fact that it's email makes it more likely for an accidental leak of personal information.
But yeah we have a bunch of travel advice like that, it's definitely fun to read.
Fuck. No.
If this is (and to be honest I didn't read it that closely) just about making a particular email public, why not just have an inbound address?
submit@fwdeveryone.com
I'd actually consider using a service that did that.
We'd love to! Unfortunately going from just the last email in the thread to being able to reconstruct the entire thread would be exceedingly difficult.
Also, being able to use DKIM / SPF / DMARC / ARC to ensure the authenticity of conversations is very important to us. If you get a permission request from our site, we want you to be 100% confident that what you see when you preview the thread is going to be what you actually wrote, and that the uploader wasn't able to change the text at all. We support making redactions and anonymizing folks, but are strongly against people being able to change the text of what they or others wrote after the fact.
The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage. We're all for reducing friction, but we'd rather do it by just making a really slick Add-on so that we don't have to compromise on that core value.
As for the Gmail OAuth situation, I completely agree and have been raising awareness of this on HN since long before this became a big issue the other day. You can see my tickets requesting narrower OAuth scopes here:
https://issuetracker.google.com/issues?q=reporter:alex.krupp...
Are you sure you have really tried? when you forward an email, it includes all the headers you need to for your validations.
If I'm wrong and it's possible to do then by all means I'll do it though. The one approach that would work is building an InboxSDK plugin and having it forward every message in a thread automatically, because that way you'd have the header of each message. But then the security story is arguably much worse than OAuth.
--000000000000061f91056a2a279c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Good. That's the way it should be.
"The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage."
What you call "magic" is a blatant and disgusting violation of my privacy. Those messages are "not on stage" for a reason; if I wanted them to be "on stage", then I would put them there myself. You have no business "looking over [my] shoulder" at all, let alone inviting everyone else in the world to do so.
I am having a hard time understanding if this is written sincerely or as satire.
I hope you are being humorous here because if this is indeed true, it does not look like something I would appreciate. I really don't want anyone to have the experience of looking over my shoulders into my inbox to see how I actually talk with others when I am not on stage.
I have always perceived email as a private mode of communication. Has this perception changed recently among the new generation of application developers?
> When uploading a thread as an individual, we email a permission request to each non-anonymized person who contributed at least one message to conversation. A thread will only go live if there is unanimous consent. This means that if even one person hits 'Decline' or doesn't respond to the permission request, the thread will remain private.