
Show HN: Consider Groups – Like Slack Channels for Email - josh_steiner
https://consider.co/groups
======
1as
Hey HN! I'm one of the founders of Consider.

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...](https://medium.com/the-consider-blog/the-
next-piece-of-the-puzzle-5557d68c5141).

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/](https://consider.co/).

Happy to answer any questions.

------
dwrodri
A pretty website, but I'm not entirely sure how this differs from a mailing
list based on your landing page.

~~~
1as
(I work at Consider)

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.

~~~
GarethX
Any plans for a unified inbox? I’ve two email accounts and switching between
them in Consider is a hassle.

~~~
1as
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.

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

~~~
toomim
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](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](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 actually blacklist entire C-blocks of IP
addresses, because they have been used to send spam. So the only practical way
to send emails these days is to use one of the big mail providers which is
already trusted by other mail servers -- and thus email has become
centralized, into a few big boys. If we solve spoofing, we can decentralize
email again.

Spoofing is so easy because SMTP doesn't inherently care who is sending a
message, so there's no default way to verify the sender. A multitude of patchy
standards (SPF, DKIM, DMARC) have tried to add layers of signatures onto the
messages, each trying to patch flaws in the last one, but even altogether they
can't solve spoofing. Since SMTP is a _forwarding_ protocol, they have to
verify the signatures of every server in between A and B, and this breaks, for
instance, when a mail server _modifies_ a message, adding text to the subject,
or a footer, or even just a header, and thus breaks the signatures on the
email that was sent out.

But if emails are _served_ over a synchronized HTTP, rather than _pushed_ with
a fire-and-forget SMTP, then it's trivial to verify the sender -- it's already
built-in with SSL/TLS certificates. You just GET the message.

And because this is HTTP, we can go ever further. We can also add in metadata,
like have public/private keys generated for each user, and serve that at a

    
    
        GET /user/<foo>/public-key
    

URL. This is much better than how SPF does it -- by forcing you to hack
metadata into your mail server's DNS records. It uses this DNS hack because if
they hosted the keys over SMTP... it would basically turn SMTP into HTTP.

Similarly, a server can publish its mailing lists at a

    
    
        GET /lists
    

URL. And if you fetch a list, you'll get all the emails in the list. So you
don't need to implement a separate system to archive your mailing list -- it's
all just built in!

~~~
em-bee
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

~~~
toomim
Interesting! Good point. I'll look into it.

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

~~~
josh_steiner
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!

~~~
werber
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

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

Good luck!

------
spectramax
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"?

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

------
abhinavsharma
This makes a lot of sense. Email and Google groups continues to be heavily
used by companies even though google has underinvested in it for years now.

------
nullspace
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. :)

Edit: [https://consider.co/company](https://consider.co/company) that link in
particular is worth checking out!

~~~
bb88
Font looks like it comes from a 1980's magazine advertisement:

[https://cdn.shopify.com/s/files/1/0722/6987/products/MDS0262...](https://cdn.shopify.com/s/files/1/0722/6987/products/MDS02629_grande.jpg?v=1454763670)

------
rrggrr
I route emails to Slack using Zapier, which gives us rule based routing, text
extraction, and follow on operations.

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.

~~~
quickthrower2
? is it worth spending a lot of time to avoid SaaS fees?

------
grumpy8
Landing page looks real nice, congrats

------
makk
I love that this is an email tool for reducing Slack usage. Lol.

------
Nursie
I should probably investigate more but ...

Sounds a lot like USENET to me.

------
ravivyas
As others mentioned, great website.

Would be great if you had a video to easily showcase what the product could
do, rather than me trying to imagine the features.

~~~
1as
Yep, we should definitely add this. Thanks!

------
Zaheer
How does Consider compare to Superhuman?

------
ctocoder
Hate the font

------
rinchik
isn't it an SMTP abuse? And just a perverted version of IRC (or Slack)?

"What if email had slack channels?" \- you mean like threads and aliases?

