Hi.
When can we expect to have email support for canisters? That is, when can we have the basic web(1) functionality on sound crypto principles? This is needed in order to build full-stack websites. Email is a foundational protocol. I would like to send email natively, without 3rd party (web2) integrations.
We’d also love to see support of using canister to verify user email.
Email is a protocol that relies on web2 infrastructure, it’s not possible to send an email to a traditional email server without using that same infrastructure.
I’d love to see a paid notification service built on the IC that would handle the off-chain infrastructure required for canisters to send emails securely.
Email is a web1 creation and existed way before web2. First documented usage was 1971.
Couldn’t we build a dedicated canister (like Bitcoin) for this?
Are you saying the “World Computer” will never be able to send e-mail?
I’m not really a big fan of calling Sendgrid to send e-mails and even more to build canister to do that and call that the standard for ICP. That’s not “all on-chain”.
Couldn’t we build a dedicated canister (like Bitcoin) for this?
How would this dedicated canister work?
The dedicated Bitcoin canister is integrating with another decentralized network. Any email-equivalent of that would inevitably just do the same thing that you’re doing in your own canister and integrate with off-chain infrastructure.
Are you saying the “World Computer” will never be able to send e-mail?
I’m not sure exactly what you mean, because you are already doing that in your canister.
Any existing email provider out there is centralized, gmail, proton, hotmail, whatever… It doesn’t matter what kind of service you use to send the email, it will eventually reach one of those centralized services so that it can be delivered to the target email address. That’s not a limitation of the Internet Computer, that’s just how email works. So “all on-chain” isn’t possible when your target destination is “off-chain”.
If you were to send IMAP, POP or SMTP requests directly from a replica, similar to HTTPS Outcalls then you’d have several problems:
Maybe a subnet could own a threshold key for DKIM signing though, I don’t know enough about cryptography to say that for sure, but either way the SPF records would still be necessary.
To solve those problems, you’d need some off-chain component.
I guess it’s just way more complex than I thought.
But I think my ask is fairly straight forward, at least philosophically. I’m fine with traffic being routed through intermediaries (if the destination e-mail is web2 then obviously it needs to hit through web2), but what I’m asking is to build the sending and receiving functionality on-chain. I would assume that blockchain singularity implies being able to build almost anything. Is an SMTP server too much to ask?
I’m asking is to build the sending and receiving functionality on-chain
You are already doing this, through HTTPS Outcalls. What advantage would you have by making the SMTP requests instead of HTTPS requests?
I’m fine with traffic being routed through intermediaries
So if that’s the case, what is wrong with using an HTTP API that makes the SMTP request on your behalf? In both cases, it goes through an intermediary. The trust and centralization properties are the same.
Is an SMTP server too much to ask?
I explained some difficulties with SMTP in my previous response, I’m confused about what is missing here.
So your solution to the problem is to use Google (or other web2 centralized options) instead? And who makes an account to the service provider if a dApp is controlled by DAO? Doesn’t that defeat the purpose of having all on-chain and no centralized intermediaries?
So your solution to the problem is to use Google (or other web2 centralized options) instead?
Instead of what? It’s the only solution if you don’t want your emails going into a spam box.
who makes an account to the service provider if a dApp is controlled by DAO
You realize that no matter what we do on the IC, the sending email address still needs to be owned by an individual, right? A DAO cannot hold and own an off-chain domain to have email addresses in the first place.
Doesn’t that defeat the purpose of having all on-chain and no centralized intermediaries?
If you don’t want centralized intermediaries, then don’t communicate using protocols that rely on centralized intermediaries.
I agree with @integral_wizard’s intent and desires here. We know there are technical challenges, but it seems crazy that ICP would not be able to provide native email support.
There has been similar pushback to web sockets and HTTP outcall support on ICP. A lot of progress has been made on each. Neither are perfect yet, but we’ve got something working pretty nicely.
Let’s keep pushing this forward and figure it out.
One of my own major use cases would be allowing a canister to own a web2 account with npm or PyPI for example.
I think what @NathanosDev is trying to say is that all email servers and providers are centralized, so you’d need to create a new email provider infrastructure that all the other email providers would recognize as valid and not spam.
For those other centralized providers to trust the new provider, a reputable and legal entity would need to be in charge.
It’s like saying “as an Internet Computer app I want to make a phone call”. That entire network is built on top of integrations with other centralized cell providers and networks.
Then there’s the issue of DNS the domain an email is sent from.
Every single domain, from google.com to sonic.ooo to ic0.app (yes, nns.ic0.app) is centralized. There was if fact an issue when Spamhaus started blocking the ic0.app domain that affected the ability to access IC apps.
Remember this?
There’s just a lot of things that aren’t worth the time to try to get on chain when there’s so many other cloud and crypto functionalities to build that would have a bigger impact with much less effort.
I’d really prefer DFINITY focus on things that are more achievable and closer to their core strengths of engineering and cryptography.