[Show IC] Web3 Notification Service (W3NS)

[MJW]

Problem: dApps today are set up to fail

Most dApps today have user retention and engagement problems.

Why?

Web3 notifications suck.

As developers, we spend a lot of time, effort and money building dApps and acquiring users. But we don’t have a good decentralised way to continually engage them; to notify them of events that require their attention, or encourage habit-forming behaviours.

Right now, notifications suck for users and developers

Without notifications, users must remember to constantly log back into your dApp to see if anything has changed, while following a Twitter and/or Discord for alerts. This is an extremely poor user experience, especially relative to Web2 expectations.

If Web3 developers want to use email, SMS or push notification services in our dApps, we’re forced to build centralised off-chain services to manage this for us. This both adds development overhead and also introduces points of failure.

So, as developers, how do we send notifications in the most decentralised way possible, without having to set up lots of new infrastructure?

With the IC’s HTTPS Outcalls feature and upcoming cross-chain integrations, we are creating a decentralised, secure notification service for developers building dApps on any chain, starting with IC.

Creating a Web3 Notification Service (W3NS)

I’m part of a team that’s solving the Web3 user retention and engagement problem.

We’re an Aussie Web3 development studio focused solely on helping developers build better on the Internet Computer.

With the IC’s HTTPS Outcalls feature, Internet Identify authentication and upcoming cross-chain integrations, we are creating a decentralised, secure notification service for developers building dApps on any chain, starting with IC.

Engage users with email HTTPS outcalls

We’ve just released our first product on the IC - an email notification service built with HTTPS outcalls.

Developers can now use this to engage users with transactional emails straight from their IC canisters.

We are using Courier’s idempotent API to make HTTPS calls. Courier then allows developer to configure their email provider of choice (e.g SendGrid, Gmail or SES) to send user emails.

Check out our demo video on Loom

Or watch our full IC Community pitch on YouTube

What’s next?

Right now we’re sharing a demo app you can use to send emails. However, our short term goal is to build an Open Internet Service that’s easily accessible by builders on any chain and supports:

• SMS & Push notifications
• Notification scheduling & flow designer
• Automations based on events and user behaviours
• Cross-chain notifications email, SMS and push notifications

Our end vision is a full-stack Web3 marketing and user-engagement platform.

Try it out!

Want to try our email notification service? You can access the code here and integrate into your own app:

GitHub - ArgonStudiosXYZ/ic-emailer

We’d love your feedback! Are there other features you’d like to see, or do you have a cool idea? Let us know in the comments

Find out about Argon Studios here: https://www.argonstudios.xyz/

[skilesare]

You are a scholar and a gentleman! I’ll DM you and we can talk about how we can integrate this with the event system we’re building. Great work!

The bridge to the outside world will almost always have centralized chokepoints, but we have to live in the world that exists. Hopefully if/when Apple allows web-based notifications we can move to something more robust and decentralized than what we have now.

[MJW]

Thank you! I’ll look forward to your DM.

[amircryptola1]

Loving where this is headed, the need for something like this came up with a conversation I had with a dev last week. Excited to dig in in the meantime

[paulyoung]

I have some concerns with implementing notifications using HTTP outcalls alone.

I think this is a good summary:

Discussing A standard for push notifications and subscriptions in wallets

I think the main concern that was brought up during Friday’s call was that at least some push notification services require the caller to include sensitive information in the request, which would be exposed to nodes in the subnet and then boundary nodes. If a bad actor were able to obtain this information and impersonate a trusted application the results could be pretty disastrous. From what I can gather, Apple (specifically) generates a key pair for you. Storing the private key in a canister …

[skilesare]

An off chain integration is certainly going to be required for handling keys, but having a simpleinterface and integration into a service that does notifications will.be a huge step for adoption.

[MJW]

Hi, thanks for your reply and for sharing your thoughts on this. We agree and it’s something we’ve considered and discussed with the IC team.

The summary is that they were onboard with our current approach of setting it via setter function instead of having in the source code.

Additionally, in the future, IC is adding secure enclaves that we can use to hide sensitive data.

Happy to discuss further!

[domwoe]

This is definitely an important issue that users need to be aware of when using such a service.

Boundary nodes as well as node providers in the respective subnet can - in principle - see your API key and hence send e-mails with the associated account.

Ideally, we’d find a service provider like courier that accepts authentication via self-signed certificates, HTTP signatures or a proof-of-possession token instead of just API keys.

[MJW]

Hey! Let me know if you try out the service and need any help/have any feedback. Thanks for your support.