Notification service №1

DevOps SubGovernance Contest Proposals
#1

Contest for the development and implementation of the HTTP notification module for external applications and services

Create a notification provider with the ability to send notifications via the HTTP protocol

The latest version of the description of this contest is available bellow in the same thread: Notification service №1 - #3 by AlexNew

Motivation:

Free TON holders need a module that provides notification transmission via the HTTP protocol for interactive applications, online stores, IOT

Contest applications must ensure compliance with the terms of reference.

Dates of the contest:

____ 2021 - ___ 2021 UTC 23.59

General requirements:

  1. Availability of HTTP API methods.

    1.1. Adding a unique identifier and notification parameters to the internal database

    1.2. Displaying the optional configurations

    1.2.1. Module information (name, description, logo, support surf address).

    1.2.2. Displaying the structural input parameters for the current module.

  2. All HTTP API methods must return a 200 response if the requested operation is successful

Requirements for the HTTP Notification Module:

  1. Guaranteed delivery of notifications within N time (for example, 1-24 hours) and repeated delivery of notifications if the delivery address is unavailable.

  2. Support for HTTPS protocol

  3. When adding a new URL address, verification of the ability to manage a domain, website or a specific url address should be performed by the person * 1 requesting sending a notification to this address

  4. Logging of events of http notifications for the possibility of displaying them in charts

  5. Availability of documentation with examples of use.

Parameters for the HTTP module:

  •  URL (the line starts with https://)

  •  Method (GET, PUT, POST, …) (optional parameter, by default it's POST)

  •  Query (a parameter line), optional parameter, by default it's “param”

https://tonlabs.notion.site/Notification-provider-onboarding-3dd961bce8954d0da80208b9a908c773

Additional terms:

All applicants will have to rewrite the HTTP API within ~4 weeks to be compatible with the top-ranked solution. (it is necessary to decide if it is necessary)

Evaluation criteria:

  1. Compliance with the terms of reference

  2. The quality of the documentation description for the module

  3. Easy to set up and simulate

  4. Operates in accordance with the terms of reference and the declared functions

  5. Cross-platform

Reward:

1st place - :gem: 100’000

2nd place - :gem: 75’000

3rd place - :gem: 50’000

Jury:

  • Jury members whose team (s) intend (s) to take part in this contest by submitting materials will lose their right to vote in this contest.

  • Each member of the jury will vote on a scale of 1-10 for each submission, or he can reject it if it doesn’t meet the requirements, or he can abstain from voting if they consider themselves unqualified judges.

  • The jury will provide feedback on your works.

  • Duplicates, modifications of other works that don’t meet the requirements, as well as incomplete or inappropriate works will be rejected.

  • The voting period is 15 days.

Jury reward:

An amount equal to 5% of the total of all tokens actually awarded to the winners will be divided equally among all jury members who voted and provided feedback. Voting and feedback are required to receive this reward.

Procedural requirements:

  • only 1 application is accepted from each team.

  • Submitted works must not be a modified version of another work.

  • All works must be available for opening and viewing by the jury, so double check your work. If the work is not available or doesn’t meet the described criteria, the work may be rejected by the jury.

  • Participants of the contest must submit their work before the deadline for accepting applications. If the work is not submitted on time, it will not be counted.

  • If the submitted work contains links to the work performed, the content of these links must contain the participant’s contact information, preferably Telegram ID, so that the jury members can compare them and check who owns the work. Otherwise, your work may be rejected.

Denial of responsibility:

Anyone can participate in the contest, but Free TON can’t distribute tokens to US citizens or US organizations.

Конкурс на разработку и внедрение модул я HTTP уведомлений для внешних приложений и сервисов

Создайте провайдера уведомлений с возможностью отправки уведомлений по протоколу HTTP

Последняя версия описания этого конкурса доступна ниже в этой же теме: Notification service №1 - #3 by AlexNew.

Мотивация:

Держателям Free TON нужен Модуль обеспечивает передачу уведомления по HTTP протоколу для интерактивные приложения, интернет магазины, IOT

Конкурсные заявки должны обеспечить соответствие техническому заданию.

Сроки проведения:

____ 2021 года - ___ 2021 года UTC 23.59

Общие требования:

  1. Наличие методов HTTP API.

    1.1. Добавления уникального идентификатора и параметров уведомления во внутреннюю базу данных

    1.2. Выводить конфигурации опционально

    1.2.1. Информация модуля (название, описание, лого, серф адрес саппорта).

    1.2.2. Вывод структурных входных параметров для текущего модуля.

  2. Все методы HTTP API должны возвращать ответ 200, в случае успеха запрашиваемой операции и ошибку в любых других случаях

Требования на модуль HTTP уведомлений:

  1. Гарантия доставки уведомлений в течении N времени (к примеру, 1-24 часа) и повторы доставки, в случае недоступности адреса доставки
  2. Поддержка протокола HTTPS
  3. При добавлении нового URL адреса должна осуществляться проверка возможности управления доменом или сайтом или конкретным url адресом, лицом *1 запрашивающее отправку уведомления на данный адрес
  4. Логирование событий http уведомлений для возможности вывода в графики
  5. Наличие документации с примерами использования.

Параметры для HTTP модуля:

  •  URL (строка начинается с https://)

  •  Method (GET, PUT, POST, …) (необязательный параметр, по умолчанию POST)

  •  Query (строка параметра), не обязательный параметр, по умолчанию “param”

https://tonlabs.notion.site/Notification-provider-onboarding-3dd961bce8954d0da80208b9a908c773

Дополнительные условия:

Все претенденты должны будут в течении ~4 недель переделать HTTP API совместимое с решением занявшим первое место. (нужно ли это. надо решить)

Критерии оценки:

  1. Соответствие техническому заданию

  2. Качество описания документации к модулю

  3. Простота настройки и моделирования

  4. Работает в соответствии с техническим заданием, заявленным функциям

  5. Кроссплатформенность

Вознаграждение:

1 место – :gem: 100’000

2 место – :gem: 75’000

3 место – :gem: 50’000

Жюри:

  • Члены жюри, чья команда(ы) намерена(ы) принять участие в этом конкурсе, предоставив материалы, теряют свое право голосовать в этом конкурсе.

  • Каждый член жюри будет голосовать, оценивая каждое представление по шкале от 1 до 10 или может отклонить его, если оно не соответствует требованиям, или воздержаться от голосования, если они считают себя не квалифицированными судьями.

  • Жюри предоставит отзывы о ваших работах.

  • Дубликаты, модификации других работ, не соответствующие требованиям, неполные или неуместные работы будут отклонены.

  • Период голосования составляет 15 дней.

Вознаграждение жюри:

Сумма, равная 5% от общей суммы всех жетонов, фактически присужденных победителям этого будет разделена поровну между всеми членами жюри, которые голосовали и оставляли отзывы. И голосование и отзывы являются обязательными для получения этого вознаграждения.

Процедурные требования:

  • от каждой команды принимается только 1 заявка.

  • Представленные работы не должны быть измененной версией другой работы.

  • Все работы должны быть доступны для открытия и просмотра жюри, поэтому, пожалуйста, дважды проверьте свою работу. Если работа недоступна или не соответствует описанным критериям, работа может быть отклонена членами жюри.

  • Участники конкурса должны представить свои работы до окончания приема заявок. Если работа не поданная вовремя, работа не будет засчитана.

  • Если в представленной работе есть ссылки на выполненную работу, содержание этих ссылок должно содержать контактные данные участника, желательно Telegram ID, чтобы члены жюри могли сопоставить их и проверить, кому принадлежит работа. В противном случае ваша работа может быть отклонена.

Отказ от ответственности:

Участвовать в конкурсе может любой желающий, но Free TON не может распространять токены среди граждан США или организаций США.

2 Likes
#2

Это не опечатка?) | Isn’t that a typo?

#3

HTTP Notification Provider Contest

Contest for the development and implementation of the HTTP Notification Module for external applications and services. This module should have an ability to send notifications via HTTP protocol.

Motivation

Free TON holders need a module that provides notifications transmission via the HTTP protocol for interactive applications, online stores, IOT and other consumers. At the same time, anonymity of the blockchain users must be ensured.

Timing

Submission period: 15 September 2021 - 15 October 2021 23:59 UTC

Voting (assessing) period: 15 days

General architecture

In order to ensure the anonymity of blockchain users, a separation has been made between the blockchain data and the addresses of the recipients of this data. For this, the following modules are introduced:

  • Queue Provider - knows what to send (data itself). It doesn’t have any information about the real world address of the recipient. It allows the user to configure an event source based on the following parameters: “Account address” and its message types: internal / external In / external Out

Queue provider forwards prepared and encrypted messages to Notification provider. Each message contains a key by which the Notification provider can match the corresponding recipient

  • Notification Providers - knows where to send (recipient real world address like IP and port, e-mail, APN ID, FCM ID, etc). It doesn’t have any information about the data. It receives and sends the data encrypted.

It could be possible to have several types of Notification Providers depending on the type of recipient and the transport (browser, http-server, smartphone devices, e-mail, etc.)

This contest is about HTTP Notification Provider Module or in short, HTTP Notification Module.

HTTP Notification Module sends http requests with blockchain events to the registered consumer.

The Http Notification module provides users with the ability to configure itself via REST API.

HTTP Notification Module’s possible consumers are online stores, external web-services, telegram bots, vkontakte, and any service with Internet connection and external access from the Internet. This means the consumer requirements include the presence of an http-server to receive push-notifications.

General requirements:

  1. Availability of HTTP API methods.
    1.1. Add a unique identifier and notification parameters to the internal database
    1.2. Get the configuration - optional
    1.2.1. Module information (name, description, logo, surf address - to be able to reach out to service developers for support).
    1.2.2. Get the structural input parameters for the current module.
  2. All HTTP API methods must return a 200 response if the requested operation is successful and corresponding HTTP error code otherwise.
  3. http-server with some UI (telegram bot, web page, etc) should be provided to test the work of the module

Requirements for the HTTP Notification Module:

  1. Guaranteed delivery of notifications within N time (for example, 1-24 hours) and repeated delivery of notifications if the delivery address is unavailable.
  2. Support for HTTPS protocol
  3. When adding a new URL address, verification of the ability to manage a domain, website or a specific url address should be performed by the person, requesting to send notifications to this address
  4. Logging of events of http notifications for the possibility of displaying them in charts
  5. Availability of documentation with usage examples.
  6. Compiling, building, deploying, running and testing instructions with prerequisites.

Parameters for the HTTP module:

• URL (the line starts with https://)
• Method (GET, PUT, POST, …) (optional parameter, by default it’s POST)
• Query (a parameter line), optional parameter, by default it’s “param”

Queue Provider API

API of the Queue Provider which could be used to get blockchain events stream is described in the following document: https://tonlabs.notion.site/Notification-provider-onboarding-3dd961bce8954d0da80208b9a908c773

Evaluation criteria

  1. Compliance with the technical requirements provided in this contest description.
  2. The quality of the documentation description for the module.
  3. Easy to set up and simulate.
  4. Operates in accordance with the terms of reference and the declared functions.
  5. Cross-platform.
  6. Source code (open source, Free Software licence).
  7. Apart from uploading a submission, a code should be submitted in accordance with GitHub - everscale-org/readme.

Reward & Vesting

  • 1st place - :gem: 100’000 TONs
  • 2nd place - :gem: 75’000 TONs
  • 3rd place - :gem: 50’000 TONs
  • 4rd place - :gem: 40’000 TONs
  • 5rd place - :gem: 30’000 TONs
  • 6rd place - :gem: 20’000 TONs
  • 7rd place - :gem: 10’000 TONs
  • 8rd place - :gem: 5’000 TONs
  • 9rd place - :gem: 3’000 TONs
  • 10rd place - :gem: 1’000 TONs

Rewards up to 10K will be paid at the end of the contest. Rewards above 10K will be paid as follows: half at the end of the competition and half in equal parts over 12 months (vesting). The conditions for obtaining the vesting are as follows:

  • Github issues should be responded to within 24 hours.
  • Critical module malfunctions should be fixed within 3 days.
  • In the case of a Queue Provider API changes or other blockchain changes, the code must be updated no later than within 1 month after the change.
  • All other adequate issues should be resolved within one month.

Jury

  • Jury members whose team (s) intend (s) to take part in this contest by submitting materials will lose their right to vote in this contest.
  • Each member of the jury will vote on a scale of 1-10 for each submission, or he can reject it if it doesn’t meet the requirements, or he can abstain from voting if they consider themselves unqualified judges.
  • The jury will provide feedback on your works.
  • To avoid inconsistency in the counting of votes, each juror must either vote for all entries or abstain.
  • Duplicates, modifications of other works that don’t meet the requirements, as well as incomplete or inappropriate works will be rejected.
  • The voting period is 15 days.

Jury reward

An amount equal to 10% of the total of all tokens actually awarded to the winners will be divided equally among all jury members who voted and provided feedback. Mandatory voting for all proposals and feedback are required to receive this reward.

Procedural requirements

  • only 1 application is accepted from each team.
  • Submitted works must not be a modified version of another work.
  • All works must be available for opening and viewing by the jury, so double check your work. If the work is not available or doesn’t meet the described criteria, the work may be rejected by the jury.
  • Participants of the contest must submit their work before the deadline for accepting applications. If the work is not submitted on time, it will not be counted.
  • If the submitted work contains links to the work performed, the content of these links must contain the participant’s contact information, preferably Telegram ID, so that the jury members can compare them and check who owns the work. Otherwise, your work may be rejected.
  • Jury voting should follow DevEx global proposal requirements

Defense of contest submissions

At the end of the submission acceptance period, AMA-session will be appointed for participants, jurors and everyone else. At this session, each contestant team has to present their work.
The presentation language is English or Russian. The presentation time should not exceed 10-20 minutes.
If a contestant cannot present the work on-line, they should make a video recording and publish it on YouTube but any questions that arise should be answered.

Governance rewards

An amount equal to 2% of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

The same percentage of the monthly reward will be received by the persons responsible for its distribution (vesting distribution overhead).

Contest announcement and attracting new members rewards

An amount equal to 5% of the prize fund will be allocated to announcing partners who participates in announcing the contest in different media according with the following table: media list for technical contests announcements, to be distributed equally among them:

  • @anovi
  • @Alex770
  • @lesnik13utsa
  • @Kronchs

Each participant of the contest, when submitting an application, will be asked through which announcing partner he/she learned about the contest. After the end of the contest, for each participant who won a reward, an amount equal to 5% of his/her reward will additionally be distributed:

  • To the announcing partner who attracted him, if the referral was given during work submission;
  • Or equally to all aforementioned partners of the announcement program, if the referral was not specified.
3 Likes
#4

Hey there everybody.

I have a question/request/proposal to organizers, related to one particular aspect of the contest requirements, namely the 3rd one – domain/website/url ownership verification.

In my experience, the most common solution for such problem (when we talk about webhooks) is using HMAC: Client and Provider share a secret, Provider asks Client to encrypt something with that secret then tries to decrypt the response with it and, in case of success, considers ownership confirmed.

To implement the strategy described above we lack such shared secret and the best thing I’ve come up with yet is to make Notification DeBot to generate one: Client would have it right after Notification contract creation, Provider would have it when DeBot sends a subscription request and that’s it. Would that be possible for the DeBot to have such functionality?

I’m looking for a way with HMAC because I believe that domain name ownership confirmation (e.g., like Google’s GSuit does) is a bit of an overkill for the webhooks functionality, especially taking into account that it’s a common practice to verify webhook callback URL ownership on a regular basis, e.g. hourly.

I’d appreciate any advises, hints or comments.

#5

Hi, @sergemedvedev
I don’t think we should force all providers to use this particular method of checking ownership of the webhookUrl, so this feature should not be implemented directly in DeBot.
Let each provider choose their own method, and the user will make the final choice.

But it will be useful if DeBot shows the provider’s response (as a plain text) to the user’s POST request. This functionality needs to be added.
In this response you can tell the user what to do next, show him the generated secret or link to your README, etc.

1 Like
#6

Do you mean the callback registration request (sent by DeBot) by “user’s POST request” or some additional API call which user makes directly (without DeBot in the middle)?

#7

The first one

the callback registration request (sent by DeBot) by “user’s POST request”

1 Like
#8

Could you please elaborate on that a bit.

#9

Добрый день всем.
Подскажите, с чего начинаеть участие в конкурсе?
я не вижу описания процедуры как подать заявку?

#10

@Rustam232 , prepare your solution, describe it and then submit it through the contest page.

#11

Please, follow the link to Notion website in " Queue Provider API" section. You will find all the information there Notification service №1 - #3 by AlexNew

#12

Information about the structure of the parameters that must be passed to the notification service to create the notification entity.
Items 1.2.* Are optional

#13

By application.
:one:It is necessary to create a wallet - I use TON Surf. Blockchain Communicator: data browser, crypto wallet and private chat for android (copy the seed phrase after starting the wallet and creating the address in the settings)
:two: You need to unsubscribe on the forum in the topic. The usual text, which indicates that you are submitting an application and it is desirable to indicate your telegram. Copy link to your message
:three: Create a PDF application with information about your work and your data: telegram, wallet address, etc.
:four: Add an application for the competition Free TON Community

image

If you have any more questions, you can write to me in telegram @lesnik13utsa

#14

Good afternoon
I’m reading:>

  • Create notification containing "<nonce> <encodedMessage>"
  • Use hash from step 4 and hash from step 3 to find the matching webhook_url or device_token
  • Send notification to the user’s device or site

Does it mean that I, as a provider, have to make POST with plain text ?
Not JSON ?
I think it is better to send serialized object: {nonce: String, encodedMessage: String}

#15

Hi! @lesnik_utsa
Do you have an answer?

#16

Better ask this question in telegram here Telegram: Contact @freeton_dev_exp

#17

Hi! Here’s my submission.
Repo : https://github.com/chain-action/http-notification/tree/contest
Description : (attached to contest submission);

Surf : 0:a9ef47b6bec35e001d1f295b34b9ec9abc0ca5c8623de4f414b4fd0b0dc6ca08

1 Like
#18

Hello there!
I’m glad to present my work.

Contact: @tonevents
Introductory video: ton.events - Introductory Video - YouTube

1 Like
#19

Solution from MTW team - GitHub - mytonwallet/ton-http-notification-provider: HTTP notification provider for Free TON blockchain
Merging to the Free TON · GitHub is here New features for VScode extesnion by mytonwallet · Pull Request #9 · freeton-org/devex · GitHub (our previous PR from another contest is not merged yet)

1 Like
#20

RSquad participates!

Submission-6

stand with client:
http://ton-provider-demo.rsquad.io

1 Like