Notification provider contest discussion: who should have Apple registration for push notifications? CreateWills by Gulzaman Khan.
Notification provider contest. Apple registration for push notifications: who should have it?
The goal of the contest is to send notifications to browsers and mobile devices about events happening on the Free TON blockchain. However, companies like Apple ask for permissions. Should this permission be given to the contestants, or should this permission be requested by the jury and the contestants have to provide their working code?
- How will the notifications be triggered? From the SDK code or directly from the smart contracts?
At the end, we plan to create a DeBot that will have several interfaces. One of them registers the user with the notification provider using the device token and the application ID, and the other interface sends encrypted subscription data to the smart contract of the subscription. Our cloud service takes them, decrypts them, and provides a queue that is read by the notification provider.
While we don’t have a DeBot, we’ve provided a simple REST API-based web application for our Kafka to pass data directly to the queue. We can temporarily work with this API and then switch to DeBot.
- Why should we rely on a centralized cloud service?
We are not developing a queue. Basically, you can implement your own queue, but it will not be included in the contest evaluation.
Surf will be one of the customers of this notification provider.
Alex talks about the need for multiple off-chain organizations to send these notifications.
Ekaterina reminds that the queue provider and notification provider should not be allowed to work together. This will open the connection between the user’s credentials and their wallet to the company that does it. So there may be a queue on our part, and we ensure that we do not provide decoded information to anyone. You are just submitting something to the users, you don’t even know what’s in there. Ton Labs encrypts all data in our queue. So, basically, you just see someone’s ID and match it to the same ID in your credential database, but you don’t know what kind of wallet that user has. You cannot match it in any way on the blockchain. The main point is not to be able to match the wallet to the device credentials.
The result of this contest will be the source code for this service. So, in fact, anyone can run it afterwards.
- If I want to deploy this solution, do I need my node, or can I use other nodes?
You will be able to use the cloud queue. Therefore, you don’t need your node.
It was agreed to discuss the issue in a week, Alex asks TON Labs to provide a more detailed plan.
Gulzaman Khan proposal discussion
Gulzaman Khan created a proposal. He needs help in developing the blockchain part: the code needs to be written, and the main governance, as part of their cooperation, will allocate funds for the implementation of this contest.
Pavel asks Gulzaman to provide a final proposal, on the basis of which they will consider their next steps.
After discussing questions from the agenda, some participants continued the meetup in Russian.
Chuck suggested the following solution to the Notification provider contest issue: make the phone app and the receiving part as a free service to contestants during the contest.
Alex promised to study all the risks of this proposal and noted that it was a good solution to the problem.