Amen to that. We reached $2M ARR as 3 engineers at Missive [1]. As the CTO, I can tell life wouldn’t quite be the same without the ability to save the day in the production console at the speed of light.
CTO at Missive here. Thanks @pimterry for summing it up nicely. A note about the User-Agent: we do not forward it to the origin server as @mike-cardwell said. Our proxy always passes an iPhone User-Agent as a “lowest common denominator” to ensure CDNs won’t serve WebP images.
Hi, I work in the tracking space, specifically first party trackers. This approach is not effective.
Here are the reasons: 1) rarely care what client the user views the email in; 2) any request to the server is enough information to identify the user, email, and open/received; 3) a tracking pixel is an antiquated form of tracking; 4) the list provided doesn’t include some big names (FB for one).
The only effective way to stop the tracking, that I’m aware of, is is to cache the result of the request. Even that doesn’t stop newer techniques. Instead what you need to do is to cache the request and then apply a model to determine if a similar request leads to a similar result for other users and serve that from the cache. To the best of my knowledge no one has built that yet, and could probably be circumvented.
Blocking "known" trackers is always going to be a cat-and-mouse game, though. Blocking all 1x1 images and similar would help as well, if you're doing that. But I'd still be concerned about spam that's using remote images for "this email address exists and a human reads it" verification. I'd also be concerned about read-receipt services, especially those that might support self-hosting rather than using a central service that you can easily identify.
By the time you check if the image is 1x1, you've already downloaded it.
The alternative expensive solution is to download EVERY image a user receives and store it indefinitely. That way the trackers aren't any more useful than "was the email received".
In short, I'd love a better solution to " load all images " vs " load no images " but that's where I ended up talking to our frontend engineer at Fastmail. Obviously he had thought about the problem a lot more then me (I do operations not any frontend) and there's no easy solution.
We are using and customizing ProseMirror exhaustively at Missive (https://missiveapp.com/) Our rich text editor allows teams to collaboratively compose / review email drafts in real time.
In our first version, we used Firepad because it provided collaborative editing somewhat effortlessly. You can imagine how people have very strict requirements regarding email and old habits anchored in other apps (Gmail, Outlook, to name a few). Here’s the one thing we hadn’t thought that made Firepad a deal breaker: spell checking. Firepad’s rendering does not use `contenteditable`, which makes browser-native spell checking impossible to provide. Big bummer for many people.
We started searching for a contenteditable-based tool that supported collaborative editing. At the time, ProseMirror was the only candidate left after discarding Quill due to its overly simplistic document model (no nested lists nor multi-line quotes) and I believe this still holds true today. ProseMirror has actually come a long way to allow proper spell checking (see https://github.com/ProseMirror/prosemirror/issues/390). Marijn very kindly responded to feedback on this topic and ended up rewriting significant parts of ProseMirror to support it. I am extremely thankful for his dedication.
We are very satisfied with ProseMirror as part of our stack. I don’t think any other editor library offers all the options we need. Thanks a ton Marijn!
Ha! I’m the one who opened that ticket. I had implemented my own spell checker which was having some performance issues and was pleased to see ProseMirror works much better now with the browsers spell checker!
It’s 100% web, yet it feels just as snappy as the best native clients. We also have a native macOS app that wraps the webview and provides a Dock icon, system notifications and Quick Look (space bar to view attachments).
We (founders of ConferenceBadge.com) never enjoyed Slack nor other chat apps because they encourage immediate attention, or you just end up missing out. And we are a team of 4… can’t imagine using it in larger organizations.
We never found any tool that would completely satisfy our collaboration needs, so we created Missive: https://missiveapp.com
It’s built on the idea that conversations should be scoped and archivable, just like emails. It’s both a full-featured email client and chat app. We can share emails and comment within threads, as well as create new chats from scratch and invite only the right people to discuss specific matters. When a topic is over, we just archive or snooze it like emails.
Started as a collaborative email client, but expanding to offer chat and general team communication features. Your inbox already acts as a todo list, so it’s the best foundation to build a powerful and unified collaboration platform. We’ll ultimately become your one true todo list. One that gathers tasks from all channels: email, chat, etc. This pretty much makes us competitors to email clients, Slack, Basecamp, help desks, CRMs… name it. Big ambitions! ;)
Hi, author here. “Chat fatigue” posts are quite numerous these days, so this probably sounds familiar. But we do think our app - https://missiveapp.com/ - is a solid foundation for building a new kind of communication tool. It is pretty unique in its genre. Mixing email threads and scoped chats in one common list. What do you think?
[1] https://missiveapp.com/