Зарегистрировать сервис

1. 1

   Запустите сервис

   Поднимите то, что вы предлагаете — шлюз Telegram, оракул FX, хост снапшотов, узел публичного API. Реестр рекламирует существующие сервисы; он их не разворачивает.

2. 2

   Установите свою личность

   Сгенерируйте пару ключей узла и держите кошелёк готовым к подписи. Peer ID вытекает из пары ключей; публичный ключ публикуется рядом с ним.

3. 3

   Подпишите событие регистрации

   Соберите поля ниже, подпишите их кошельком и опубликуйте. Событие распространяется по протоколу gossip — без регистратора, без очереди, без одобрения.

4. 4

   Публикуйте обновления состояния

   Поставщики периодически объявляют «В сети», «Обслуживание», «Деградировал» или «Не в сети». Клиенты используют это, чтобы обходить вас, когда вы недоступны — а если вы совсем прекратите публиковать, ваша регистрация истечёт сама и перестанет появляться в обнаружении.

5. 5

   Будьте выбраны

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

Service ID

Глобально уникальный и постоянный — смена эндпойнтов или цен никогда его не меняет (§8).

Тип сервиса

Один из типов реестра. Поставщик может запускать несколько сервисов, каждый со своим ID.

Личность поставщика

Кошелёк, личность узла, peer ID и публичный ключ выше.

Сетевые эндпойнты

Где клиенты достигают сервиса. Несколько эндпойнтов это нормально — по одному на регион.

Поддерживаемые версии протокола

Чтобы клиент мог понять, может ли он с вами говорить, прежде чем пробовать.

Географический регион

Какие регионы вы обслуживаете, если хотите сказать. Самозаявленный и непроверенный — ничто в протоколе не измеряет, где находится сервис, и никогда не будет: геолокация эндпойнта ответила бы, где заканчивается ваш сокет, а это другой вопрос, чем кого вы обслуживаете. Клиенты видят его помеченным как заявленный.

Возможности

Что сервис действительно делает — валютные пары для оракула, каналы для шлюза, хранение для снапшотов.

Оформление

Имя, фраза, логотип и сайт, всё необязательно. Логотип это IPFS CID, а не URL, так что зрители берут его со своего узла доступа, и никто не узнаёт, кто смотрел вашу запись. Имена не эксклюзивны: реестр не помешает кому-то ещё зарегистрировать ваше, так что ваш Service ID это то, что вас идентифицирует.

Цена

Если вы берёте плату. Необязательно и рекламируется как метаданные, а не навязывается реестром.

Метка времени и подпись

Событие подписывается и распространяется по gossip в сеть. Никому ничего подавать не нужно.

Адрес кошелька

Подписывает регистрацию и каждое последующее обновление. Кто держит этот ключ, тот управляет записью сервиса.

Личность узла

Имя, под которым ваш узел себя публикует, стабильное между перезапусками.

Peer ID

Выведен из пары ключей вашего узла. Это то, что набирает клиент, и то, что доказывает, что он достиг вас, а не кого-то, рекламирующего ваше имя хоста.

Публичный ключ

Публикуется, чтобы любой мог проверить ваши подписи, не спрашивая его у вас.

• УведомленияNotification Provider
• Ценовые оракулыOracle Provider
• Риск-аналитикаRisk Intelligence Provider
• СнапшотыSnapshot Provider
• Шлюзы продавцовMerchant Gateway
• Узлы APIPublic API Node

Управление может добавлять типы со временем. Поставщик может запускать несколько сервисов; каждый получает свой Service ID.

Сам реестр не просит ничего, кроме подписи. Отдельные спецификации сервисов могут требовать стейк — поставщик риск-аналитики, чьи данные двигают споры, отвечает за большее, чем хост снапшотов — но это задаёт сервис, а не реестр, в котором вы регистрируетесь.