As a marketing specialist, I need to be able to send information to ICP users without forcing them to log in to a third-party dapp. As it stands right now, most people are using email, but email is incompatible with web3. I want to be able to send newsletters, notifications, and messages directly to people’s wallets.
Requirements
I need to be able to use HTML/markdown to craft a media message
Users need to be able to subscribe to my messages
Users need to always be able to delete messages
Users need to be able to block messages from source
Wallets should notify users that they have received a message
Why
unlike the rest of web3 ICP is an internet alternative. We should be able to fill these gaps to become a true internet alternative. We need a way to notify our users.
Risks
All risks here should be same as any communications platform
Spam, fishing scams,
Practical Application
I am a blogger and I want to notify ICP users when I post content. My blog would have a subscribe button that takes in the users account and when I post something his wallet should notify them.
Considerations
This is not a proposal nearly a brain storming session.
We touched on this a little bit in the developer community call on Discord this morning but it was mostly identifying challenges rather than proposing solutions.
I know this might not be exactly what you’re looking for but thought it would be interesting to add it to the discussion, as it could spark some thoughts.
I was thinking you could do a process where:
On subscribe you mint a NFT into subscribers wallet.
Then you airdrop your newsletters/messages as NFTs into the wallets of the holders of the subscriber NFT.
Subscriber can delete any message/newsletter by sending it to a burn address.
Subscriber can unsubscribe by sending their subscriber NFT to a burn address
If the messages all come from one canister and newsletters come from another then they could be grouped.
Also I think you could do fun stuff like customize airdropped NFTs to be specific to each holder, such as have settings on the subscriber NFT like username and theme, and so their NFTs are all in dark theme and use their username when addressing the reader.
You could even note if and when they viewed the newsletter and give rewards based on like the first n number of readers.
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 is also problematic.
Perhaps if one of the third party services allowed its customers to provide their own keys, we could use Threshold ECDSA to sign requests in a secure manner.
Another concern was around idempotency and having to trade off consensus/replication if the push notification server doesn’t recognize the Idempotency-Key request header.
You can upload the public key portion of a user-managed key pair to associate it with a service account. After you upload the public key, you can use the private key from the key pair as a service account key.
However:
The key you upload must be an RSA public key that is wrapped in an X.509 v3 certificate and encoded in base64.
I don’t think Threshold ECDSA can help here. If such a thing as Threshold RSA were possible and implemented then it might provide a path forward.
I tagged the above people based on the white paper. Also tagging @Manu@dieter.sommer@Jan since they are mentioned in the motion proposal for Threshold ECDSA.
@cryptoisgood perhaps worth mentioning that because canisters can service HTTP requests they can provide RSS feeds.
I believe RSS clients poll feeds once per hour or something like that so it wouldn’t be the most cost-effective way to go but it is something that would work today.
If we have WebSocket support, can wallets implement the rest of the stack on top of it? I think the critical question is whether the users need off line support. For example, on iOS / Android the system can deliver push notifications when the app is not running. Do we need to be able to notify the user when the wallet is not running on the client?
I did donated some tokens when the project previously named EPNS. The idea is good however there are couple technical and non-techinical issues can not solve. Just like text message, policy of push notification might be different in different country, Apple and Google/firebase service might be unavailable. The message routing problem is critical to this solution.
I think there are two kinds of usage to mobile notification. One is while mobile app is running, you can use Socket/WebSocket even WebRTC to get a realtime/instance message, like a chat app.
However WebSocket is not very functional while the mobile app is switched to background, especially on iOS, the socket will be disconnected silently. Devs will have to keep it alive manually, or use push service to “notify” the client to remain connected.
The favorite solution “WalletConnect” uses its own messaging/pushing solution in its v2 version.
I think we can explore similar architecture combining boundary nodes and canisters. Might be great web3 infra to IC in the future.
Is there any follow ups on this topic?
We are a wallet provider and will support Bitfinity in the future.
We are using WalletConnect heavily and have a close connection to them.
Within our wallet we added a custom function to communicate with there endpoints and push notifications to the user.
I would like to see a walletConnect integration in Bitfinity. Anyone of you ever reached out to them?
