Good old email on holochain?

What about an absolute minimalist implementation of good old email on holochain? Both fully advertisment free AND simultaneously fully gratis for self hosters (aka “hemail” users). In case one is briefly offline as host (encrypted) data gets temporarily cached in the “hemail network”. That’s it. Nothing more. Doable?


Hey @lsuess.
I have been asking the same question… where is the HMail App!? :slight_smile:
I want to maintain email on my devices agent centrically … (as one can do with crypto)

fortunately it seems @ddd-mtl is already on the case with Snapmail
and has posted these links elsewhere in the forum:

I see these my thoughts on the architecture might differ slightly… with the public DHT being a registration username / handle lookup to get agent addresses and the rest of the communication using peer2peer send-receive and capability claims …

  1. I know my friends username eg bob1. i go to the mail app and ask for bob1’s agent address.
  2. I write the outgoing email to my source chain private and create a capability claim for bob1
  3. i send him the claim… when online he receives notification of the mail.
  4. he reads my private source chain entry for his email and copies it to his source chain inbox.
  5. bob1 sends an acknowledgement message back.

just my thoughts for now


Yes. As any software, there are multiple valid ways to do this.
The main problem with holochain email is handling asynchrounous messaging.
In your proposed design, sender and recepient must be online at the same time for it work (step 4).
This is may or may not be seen as an issue, depending on intended design.

It looks like a nice initiative but:

  • Should we implement internal protocol and something like a proxy, gateway to smtp, pop, imap, messengers like, signal telegram, … ?

  • Is it possible to implement and deploy protocols (smtp,…) embedded into Holochain ?

  • If we use a proxy, gateway we break the distributed nature of the idea ?

I am starting with Holochain and I could not see how to implement a specific protocol easily.


1 Like

hey… we discussed this with ddd-mtl in a hack session…
one interesting part was async comms offline - receive online… as email works
to do this the thinking was to encypt message receipts on a throwaway DHT’s

look forward to testing this out
it was also mentioned by @ddd-mtl that there were a few things that if they made changes in the core would help a lot … i suggested he note his wishlist here in this thread.

as far as protocols are concerned most of them are server centric so doesnt make sense in the p2p systems… once you get the email … there are only two people holding copies … the person that sent the email and the copy you have… so backup your devices… (auto archive features coming soon in holochain)

I must say that my previous message is more aimed at validating elements of my understanding of Holochain than at bringing a solution or a relevant opinion, as I am in an exploratory phase.
Your answer prompted me to go back and read again the concepts and some Holochain articles. I realize that I made a mistake and a shortcut with the serverless concept. Indeed a serverless function deployed on Googgle, AWS, … can be invoked by an external event without the user being connected and change the data layer. This is not the case with Holochain. Thank you because I felt that something was missing but I hadn’t found it.


I wrote the list of changes required in Core in this thread

1 Like

@nphias One tricky thing with the Throwaway DHT pattern is that you need at least one always-online persistence-holder to make it work for async comms. You could hire a Holo host, I suppose, but I prefer patterns that work with Holochain only and merely get enhanced with the addition of Holo hosting. If you’re not too worried about the robustness of the encryption schemes in use these days, Asynchronous Private Messaging might be something to explore. (Would love some criticism of that pattern – calling any of my write-ups ‘patterns’ is a bit of a stretch, because they haven’t been used and battle-tested.)