This is not directly related to Consider Groups (which itself looks interesting), but just wanted to say that your website looks very, very nice. Well-designed, nice fonts, nice color palette. :)
Mailing list rebranded as Slack channels with a pretty UI similar to Slack is what it looks like to me. Is there a market for that, I am sure there is for people who are not familiar with mailing lists and prefer a web app interface similar to Slack for their mailing lists.
It's funny to see 3rd party integrations listed when IRC was barely more than telnet and was stupid simple to interact with programmatically. I wrote my first IRC bot, from zero knowledge to functioning in the channel, in 45 minutes. Try to do THAT with the Slack Integrations API or whatever. And that was when I was still learning how to code!
First, it's easy to find history. With a Consider group, you can see all of the history of all groups you're in, right there in the email client. So – a new engineer, say, on their first day in the company, can browse engineering@. (And they can see all the conversations the team have pinned there, almost like a super lightweight wiki.)
Second, it's easy to browse groups you're _not_ a member of. So, that engineer can stop by design@, and take a sneak peak of what the design team are working on now and then, without having their inbox fill up with stuff they're not interested in.
Some companies (notably Stripe) have built cool internal tools to approximate these benefits on top of Gmail and Google Groups. With Consider + Groups, you get everything combined in one place by default.
We hear this a lot, and it's something I'm personally interested in. There are also a few tradeoffs and downsides involved in building it… but it's something we’re actively considering.
Is there any work being done to add to SMTP and other open protocols to address these issues?
I had started to look into doing it as a hobby project, but as far as I could see, you need to be in the mail server to do the proper magic, and it would ad-hoc.
Basically what we'd need are ways to:
- Forward an entire conversation to someone. (To add someone to a channel.)
- Have the recipients of a message be based on them subscribing, not you adding them to the TO: or CC: fields.
- Have a way to subscribe and unsubscribe.
- Have a way to receive the available channels.
- Have a way to reference a past message.
All of which are supported by mailing lists... but nothing is standardized, nothing is protocol-based and email clients have no built-in supports.
I'm working on such a project, but only indirectly.
The core problem I see is that sending a message over SMTP means you push it to someone, and then you can't modify the message afterward.
This means (1) you can't add someone to a message. And as a result, if someone's added to a list, they don't automatically get the messages that were sent to the list before, because those were already sent.
And from another angle, it also means (2) you need to know all the recipients in advance. You can't send a message to the "public", for instance. There's no natural support for publishing all "channels", because there's nothing to subscribe to.
And from a third angle, it means (3) you have to build a separate system to archive a mailing list, because SMTP itself acts as if it forgets a message after it's sent. There's nothing in the protocol to retrieve a past message!
The solution I'm working on is a little circuitous, but I think it will work, eventually. I think email needs a synchronization protocol. Where everyone who has received a message will receive updates, in sync. And every email will have a URL that can be referenced in replies. And email servers will serve emails, rather than just firing-and-forgetting them like SMTP.
Now for the indirect part: I'm building this new email protocol on top of an extension to HTTP called Braid (https://braid.news). The idea is to first add synchronization to HTTP, in a way that allows data to be federated in a P2P network, like with email. Then you can host any data, anywhere on the web, and any client or server, anywhere else on the web, can synchronize with it. This gives you the same features as email, and then some.
Consider that most people use webmail anyway. And mailing lists host message archives on websites. So your email is already on the web. Well, now instead of having a different protocol for sending emails between servers (SMTP) and for getting emails from a server to a client (IMAP/POP/JMAP), and for viewing them in a web browser (HTTP), we can have a single synchronization protocol, which is general enough to share email messages between servers, and from servers to clients, all using the same network messages.
And it has the added benefits that (a) you can edit emails after you send them, (b) you can delete emails that you regret having sent (although you can't prevent recipients from caching a sent message), and (c) you can use the same protocol for posting a blog -- just send a message to a special "public" address, and your server's access control will allow any viewer to read it.
This last part is because we'll be switching email from a push protocol (SMTP) to a subscribe protocol (HTTP+Braid). With the Braid mail, when you send a message to someone else, you'll really just be pinging their server and saying "I'm hosting some emails that are addressed to you." Then their server will just do a
GET /inbox
On your server and your server will send them all the outstanding messages that it has access to (anything addressed to `<user>@that_server.com`). And if you send a message to `public`, then anyone who does a GET /inbox will see it.
Similar to this work is the JMAP specification in the IETF. (https://jmap.io) This is a great improvement over IMAP, but it doesn't handle the server-to-server case that SMTP does, and it also has to implement its own particular synchronization mechanism over web push APIs because it doesn't get to benefit from the Braid synchronization extensions to HTTP.
Finally — and perhaps most importantly — we can solve email spoofing. This is huge. The prevalence of spoofing is why it's so hard to run your own mail server. Most email providers ac...
i agree that email could use server-to-server synchronization. but isn't that what usenet does/did? i think it would be worth to explore the specific differences to usenet to see if there is anything that can be learned from it
Off topic: On the homepage, the tag line says "Email for startups" - is that a marketing buzz these days? What's wrong with "Email for small businesses"?
Small business is a broader term. Something for small businesses could be aimed at people running a restaurant. If I'm looking for something with a high degree of relevance to my team, which is definitely the case if I'm looking at this instead of just going with big well known products from big well known companies, then that makes it a less appealing statement.
Although I love the idea, that price would be a deal breaker for my teams. With G Suite at $12/mo/user it'd be hard to justify something with much less functionality for nearly the same price.
We think the price of a couple cups of coffee per month is a fair price for something used for multiple hours per day. :) We're free for 30 days, so you can work out if this works for you!
I feel like pricing yourself higher than slack without a comparable free tier is going to make it hard for people to evangelize the merits of the platform. That aside, I love your aesthetic, great typography and color choices
We just shipped Groups. I'd love to hear what you think. We've been using it in our company for several months, and it's greatly improved our communication culture.
Finally, if you're hearing about Consider for the first time – it's also an email client you can adopt just for yourself (although it works even better when multiple folks on a team use together!). Overall, we've tried to design for focus and flow throughout, and almost all features apply to your own private mail just as much as shared/team-level stuff. See more at https://consider.co/.
Pretty neat. I love pretty much everything about the public facing site.
Some feedback during my signup:
- nothing happens after I sign up with Google. Have to reload the page.
- the onboarding video is really bad. Please re-record with better acoustics and no offense to Allie, but do a few test takes before recording the production version. It feels way too amateurish as it is.
- why is the intercom chat widget there when I'm signed in? if the point of Consider is to eliminate anxiety during email processing, adding a little icon with yet another red notification is highly counterproductive.
- I like the 'later' button on individual emails.
- the filters are neat but maybe the 'done' category should be a first class citizen.
- search needs more focus. I want to be able to search from the inbox and to use it as more of a filter than a search. Doubt my requirements are unique to me.
36 comments
[ 2.1 ms ] story [ 75.3 ms ] threadEdit: https://consider.co/company that link in particular is worth checking out!
https://cdn.shopify.com/s/files/1/0722/6987/products/MDS0262...
"What if email had slack channels?" - you mean like threads and aliases?
Rebrand anything with a pretty UI and someone in an "office job" will want to use it...
- history (this is probably the biggest)
- in-line replies
- 3rd party integrations
- gif/photos/files
Two main things I'd call out.
First, it's easy to find history. With a Consider group, you can see all of the history of all groups you're in, right there in the email client. So – a new engineer, say, on their first day in the company, can browse engineering@. (And they can see all the conversations the team have pinned there, almost like a super lightweight wiki.)
Second, it's easy to browse groups you're _not_ a member of. So, that engineer can stop by design@, and take a sneak peak of what the design team are working on now and then, without having their inbox fill up with stuff they're not interested in.
Some companies (notably Stripe) have built cool internal tools to approximate these benefits on top of Gmail and Google Groups. With Consider + Groups, you get everything combined in one place by default.
Would be great if you had a video to easily showcase what the product could do, rather than me trying to imagine the features.
I had started to look into doing it as a hobby project, but as far as I could see, you need to be in the mail server to do the proper magic, and it would ad-hoc.
Basically what we'd need are ways to:
- Forward an entire conversation to someone. (To add someone to a channel.) - Have the recipients of a message be based on them subscribing, not you adding them to the TO: or CC: fields. - Have a way to subscribe and unsubscribe. - Have a way to receive the available channels. - Have a way to reference a past message.
All of which are supported by mailing lists... but nothing is standardized, nothing is protocol-based and email clients have no built-in supports.
The core problem I see is that sending a message over SMTP means you push it to someone, and then you can't modify the message afterward.
This means (1) you can't add someone to a message. And as a result, if someone's added to a list, they don't automatically get the messages that were sent to the list before, because those were already sent.
And from another angle, it also means (2) you need to know all the recipients in advance. You can't send a message to the "public", for instance. There's no natural support for publishing all "channels", because there's nothing to subscribe to.
And from a third angle, it means (3) you have to build a separate system to archive a mailing list, because SMTP itself acts as if it forgets a message after it's sent. There's nothing in the protocol to retrieve a past message!
The solution I'm working on is a little circuitous, but I think it will work, eventually. I think email needs a synchronization protocol. Where everyone who has received a message will receive updates, in sync. And every email will have a URL that can be referenced in replies. And email servers will serve emails, rather than just firing-and-forgetting them like SMTP.
Now for the indirect part: I'm building this new email protocol on top of an extension to HTTP called Braid (https://braid.news). The idea is to first add synchronization to HTTP, in a way that allows data to be federated in a P2P network, like with email. Then you can host any data, anywhere on the web, and any client or server, anywhere else on the web, can synchronize with it. This gives you the same features as email, and then some.
Consider that most people use webmail anyway. And mailing lists host message archives on websites. So your email is already on the web. Well, now instead of having a different protocol for sending emails between servers (SMTP) and for getting emails from a server to a client (IMAP/POP/JMAP), and for viewing them in a web browser (HTTP), we can have a single synchronization protocol, which is general enough to share email messages between servers, and from servers to clients, all using the same network messages.
And it has the added benefits that (a) you can edit emails after you send them, (b) you can delete emails that you regret having sent (although you can't prevent recipients from caching a sent message), and (c) you can use the same protocol for posting a blog -- just send a message to a special "public" address, and your server's access control will allow any viewer to read it.
This last part is because we'll be switching email from a push protocol (SMTP) to a subscribe protocol (HTTP+Braid). With the Braid mail, when you send a message to someone else, you'll really just be pinging their server and saying "I'm hosting some emails that are addressed to you." Then their server will just do a
On your server and your server will send them all the outstanding messages that it has access to (anything addressed to `<user>@that_server.com`). And if you send a message to `public`, then anyone who does a GET /inbox will see it.Similar to this work is the JMAP specification in the IETF. (https://jmap.io) This is a great improvement over IMAP, but it doesn't handle the server-to-server case that SMTP does, and it also has to implement its own particular synchronization mechanism over web push APIs because it doesn't get to benefit from the Braid synchronization extensions to HTTP.
Finally — and perhaps most importantly — we can solve email spoofing. This is huge. The prevalence of spoofing is why it's so hard to run your own mail server. Most email providers ac...
I feel the comparison with Google's pricing is appropriate.
Disclaimer: I work for Google, opinions are my own.
We just shipped Groups. I'd love to hear what you think. We've been using it in our company for several months, and it's greatly improved our communication culture.
Read a bit more about its origin here: https://medium.com/the-consider-blog/the-next-piece-of-the-p....
Finally, if you're hearing about Consider for the first time – it's also an email client you can adopt just for yourself (although it works even better when multiple folks on a team use together!). Overall, we've tried to design for focus and flow throughout, and almost all features apply to your own private mail just as much as shared/team-level stuff. See more at https://consider.co/.
Happy to answer any questions.
Sounds a lot like USENET to me.
Most of my time now is spent integrating at lowest cost possible, and minimizing new SAAS adoption.
When you tally the total cost of SAAS, it gets very expensive. I've decided to take the dragon now.
Some feedback during my signup:
- nothing happens after I sign up with Google. Have to reload the page.
- the onboarding video is really bad. Please re-record with better acoustics and no offense to Allie, but do a few test takes before recording the production version. It feels way too amateurish as it is.
- why is the intercom chat widget there when I'm signed in? if the point of Consider is to eliminate anxiety during email processing, adding a little icon with yet another red notification is highly counterproductive.
- I like the 'later' button on individual emails.
- the filters are neat but maybe the 'done' category should be a first class citizen.
- search needs more focus. I want to be able to search from the inbox and to use it as more of a filter than a search. Doubt my requirements are unique to me.
Good luck!