Web3 Notification Service (W3NS)

We are using the Internet Computer blockchain to build a decentralised Email, Push and SMS notification service for web3 apps on any chain.

Web3, Internet Computer, Open Source, Cross-Chain

Services

Web3, Internet Computer, Open Source, Cross-Chain

Intro

Right now, dApps on every blockchain suffer from a retention problem. They don’t have a good way to notify their users of events that require their attention and thus bring them back to engage. Instead, users must remember to constantly log back into the dApp to see if anything has changed while following a Twitter and/or Discord for alerts.

This is an extremely sub-par UX that is limiting web3 dApps and developers from scaling. It is caused by two things:

  1. Some users want to remain anonymous on-chain
  2. These users aren’t interested in sharing their phone or email for notifications because it means identifying themselves. How do we notify a wallet address of an event?
  3. For email, SMS and push notifications, developers are forced to rebuild web2 notification infrastructure and bear the costs.
  4. Using a service like Twilio requires developers to build an off-chain service that interacts with their smart contracts. On some chains this can cost them a lot in gas, and more importantly it is centralised and insecure.

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

Solution

The core of any online business is its growth engine. The cost to have someone engage with your dApp, the rate at which they engage with it, as a leading indicator to retention. A lot of money is invested in building dApps and advertising them, but bringing people back after each use is the key to long-term success.

With the success of the IC grant program many dApps are being built, the grants create the incentive to bring in devs to learn Motoko, and how to navigate the ecosystem. The output of this is dApps and tooling. Once someone has experienced the dApp as a user, short of bookmarking it, there is not many ways they are drawn back in.

We are building W3NS to fix that. Similar to how SNS by AWS unlocked a new wave of notification based marketing to existing users of web2 apps, we will unlock that same potential for web3.

The more engagement dApps drive, the more frequently users return to IC, the more successful the dApps are, the higher the incentive to come and build on IC. This is the feedback loop, without which we are all on a boat with holes. Leaking users.

It is vital that the foundation is built. We took that first step with our current HTTPS outcalls integration to send email from any Canister. That is a proof-of-concept (Phase 0), to achieve a data-driven marketing automation platform we need an easy-to-integrate, customisable, omni-channel marketing pipeline.

  • Easy-to-integrate, it should be as simple as a single inter-canister call to trigger marketing for a given user, or user segment.
  • Customisable, the logic of when to send messages based on specific user actions and segments should be easily customisable, via a nice drag-and-drop UI. “Flows” based retention marketing.
  • Omni-channel, email is not enough in a modern marketing environment, open rates can be low, SMS is a much more effective direct marketing medium. And push notifications are table stakes for a tech product.
  • These are the core, with room to expand in the future.

This describes layer 2 and layer 3. Once notifications can be conveniently sent, that can be abstracted into more complex, automated marketing funnels. Imagine when a user signs up for your dApp, you can make one inter-canister call and trigger a 10 email welcome flow explaining how to use your dApp in bite-size tutorials each day. Massively increasing the surface area of engagement. When users are not on your platform, how do you reach them?

Phase 1: SMS, Email, Push Notifications

Our proposed Phase 1 will extend our email support to cover SMS and Push. It is idempotent and scales cheaply, we will also support dynamic API keys so users can Bring Your Own Key (BYOK) to send via custom domain emails and vanity phone numbers (branded).

You will be able to subscribe users to specific Topics, which can then be used to broadcast to many users of similar interests, i.e. someone interested in the results of games in a fantasy sports league.

It will also leverage Daemon Contracts to store messages to be sent in the future. e.g. when a user adds an item to their cart on the future IC Shopify dApp and does not purchase you can schedule an abandon cart email and/or push notification with a discount code to be sent that evening. Bringing them back to purchase, increasing conversion rate, making those Shopify dApps more successful.

Phase 2: Scheduling

Scheduling is a key component to unlock Flows. A Flow is a series of notifications sent in a specific order over many days or even weeks. It takes the user on a journey and reminds them to return to the dApp.

Flows are the backbone of modern-day online marketing. You capture a mailing list and then you structure Flows to compel them to action. They require the ability to store logic around when to send each notification and to schedule them well into the future reliably. Missed notifications in the chain will confuse users and defeat the purpose.

In this phase we will also level up the support for customisation a dApp can do to their email templates, improving their branding and structure. Key for a coherent and beautiful email Flow.

Key output: Flows of Messages based on single user actions

Phase 3: Automation Flows

Phase 3 is the emergent industry of marketing automation that evolves from stacking Flows on top of each other, triggered by different user actions.

The creation of an easy-to-use UI for crafting these Flows.

The logical next step is an event-driven architecture that allows you to trigger Flows off of a series of events rather than any specific single action (i.e. a user has made 3 purchases within a month, or has clicked the cancel subscription button but then decided to stay) allowing you to tailor your marketing even more closely (core function of Klaviyo and Segment.io)

It also creates an opportunity in future for IC Identities to be mapped to other contact methods, so that when a user signs up for a dApp we can allow the dApp to contact them without knowing their phone number or email address. Keeping their data private, but still allowing them to receive vital information from the dApps they interact with.

Key output: Flows of Messages based on a series of user actions, a network effect of dApps signing up for our service as we have largest Internet Identity to contact details mapping.

Phase 4: Cross-Chain

A notification service like this can uniquely be built on the Internet Computer, and with future cross-chain integrations, be made available to developers building in other ecosystems. It is well known that most web3 developers build infrastructure like this off-chain - creating additional complexity, cost and centralisation for themselves. The success of Push (17.7m sent notifications, 60k+ total subscribers) in a relatively short timeframe shows the demand for a decentralised notification service, however their UX of requiring end users to install a custom app will continue to limit them.

As IC integrates more chains, we will do the same - making W3NS available for developers in those ecosystems.

Beyond

With this as a foundation there are many improvements that can be made, an IC-wide Idempotency Proxy, Dead Letter queues to resend bounced notifications, pub sub support (SNS features).

This can be an independently successful utility, making revenue from premium features for more sophisticated marketing automation tooling. Similar to Klaviyo ($10B valuation, 70k companies use it, ~$140M in ARR) and Segment (bought for $3.2B by Twilio to integrate event-driven tooling with outbound notification services, not unlike what we are proposing here).

Conclusion

The future success of IC relies on frequent usage of dApps by users to drive a critical mass, the less users that leak every day from the boat the faster we reach it. The missing link is being able to contact them when they are away from your dApp, we are about to solve that.