Show HN: IMAP-based message broker client written in Go

  • Email is missing chat. Email is missing encryption. Email is missing anonymity. Yet email is the last free, public, globally distributed network we have. Phones, radio, even snail mail all have fees and oversight from a central source.

    I can totally see this project being combined with a "smart" encryption system (one that can tell when to encrypt emails to people that support it) to sit right on top of our current SMTP setup to provide "progressive enhancement" for apps that want to add these things to email.

  • I can't decide whether this is amazing or horrible, and I like it.

  • Nice.

    A useful next step would be to have an IMAP server with no queuing delay. When a message comes in via SMTP, and there's a connected client authorized to receive it, the message gets delivered to the client before the SMTP connection is closed. If no client is available to receive the message, queue the message and return "250 Queued" vs "250 Delivered". No mail bounces; all rejections are made during the active SMTP connection.

    Similarly, a pure mail forwarder (SMTP in, SMTP out, no local mailboxes) would be useful. Again, it should open the outgoing SMTP connection while the incoming connection is still open, and return statuses immediately.

    This no-queuing approach to SMTP gives us chat over email. It will interoperate with existing queuing-type servers, but if the whole chain is no-queuing, you get immediate delivery with a status telling you it reached the client.

    (All this would apply only to messages with only one "To" address. Everything else gets dumped into a database for later bulk delivery as normal.)

  • It panics sometimes instead of returning the errors and there's no way to catch that in a clean way in go.

    This is however such a great idea to send some commands to your pet projects. At the very least, don't know of a (dirty or non-dirty) solution which is this quick.

    I would say, why not (maybe not, because some naive soul uses this on anything high-volume and hilarity ensues).

  • The interface is slightly weird. If I call Sub() twice (e.g. in two different goroutines) for the same queue, each message will be received by one of these two subscribers (because the channel is shared). I'd expect exact opposite: all of them to receive each message.

  • Actually this gets me thinking: what about making a signaling server for webrtc chats using IMAP ? This way we got a truely decentralised chat system.

  • Very clever...not sure its something that I would use in production...but definitely fun.

  • A nice PoC to trash your IMAP service.

  • Where is this world going to