Обновление примеров JSON_metadata для UIA шлюзов после реализации интерфейса пополнения и вывода токенов в кошельке dpos.space


Здравствуйте. В посте про код для UIA шлюзов я придумал коды для пополнения и вывода UIA. Но оказалось, что это не очень-то подходит на практике.

Сегодня реализовал интерфейс на https://dpos.space/golos/wallet для пополнения и вывода UIA активов некоторых, и понял, что надо реализовывать всё иначе.

Кстати, кошелёк уже новый (с поддержкой UIA активов).

Что добавил

  1. PRIZM от @prizm - вывод (ввода нет).
  2. YMRUB от @ecurrex-ru - и ввод, и вывод.

RUDEX от @rudex и WHALER от @whaler-fund не являются шлюзовым токеном.
WHALER вроде можно обменивать на Bitshares и обратно, но нужно ли это..., если токен популярен истинно Голосовский :-).
У Рудекса, думаю, в будущем появятся токены, типа RUDEX.BTC и пр. - тогда можно будет их и добавить.

Код

Писал на Javascript, поэтому отображу в этом формате:

var gates = {}; // Объект со шлюзовыми UIA
gates.PRIZM = {}; // Шлюз PRIZM
gates.YMRUB = {}; // шлюз YMRUB
gates.PRIZM.withdraw = { // Шлюз PRIZM - вывод
  account: "exprizm", // Куда переводим
  vars: { // Переменные (поля)
    address: "Адрес в блокчейне Prizm", // Пишем, что пользователю надо будет ввести адрес в Prizm.
    key: "Публичный ключ" // и публичный ключ.
  },
  separator: " " // Разделитель для memo - пробел. Если в memo один элемент, можно не указывать, но всё же лучше указать, чтоб не отклоняться от стандарта.
};

gates.YMRUB.withdraw = { // Вывод YMRUB
  account: "ecurrex-ymrub", // Аккаунт вывода (перевода)
  vars: { // переменные (поля)
    address: "Адрес кошелька Yoomoney", // Запрашиваем кошелёк
  },
  separator: " " // Разделитель для memo - пробел. Если в memo один элемент, можно не указывать, но всё же лучше указать, чтоб не отклоняться от стандарта.
};

gates.YMRUB.deposit = { // Пополнение YMRUB
vars: { // Переменные (указываем, что надо будет делать пользователю)
  address: { // Делаем переменную address, которая указывает адрес Yoomoney кошелька. Название в иных шлюзовых токенах может быть иным.
    name: "Адрес кошелька в Yoomoney", // Пишем, что эта переменная означает.
    value: `41001183294372`, // Пишем значение. Может быть и ссылкой, но интерфейсы тогда должны позаботиться о фильтрации, чтоб можно было копировать в буфер обмена текст (в данном случае адрес кошелька со ссылкой на визитку оплаты).
  },
  memo: { // Вторая переменная. Назвал её memo, как нам привычно, хотя это примечание к платежу в Yoomoney.
    name: "Примечание к платежу", // Что это
    value: "golos:" + golos_login // Пишем значение. В моём примере прописывается golos: и добавляется значение переменной golos_login (логин авторизованного пользователя Голоса).
  }
}
};

Важно

Я всё же надеюсь, что gates будет реализован в json_metadata, а значит, там не получится ввести переменную логина Голоса, как это сделал я в JS. Предлагаю ввести переменную $login.
Если скрипты её будут встречать, станут подставлять логин авторизовавшегося пользователя.

Проблема

Не продуман вариант, когда адрес генерируется для каждого пользователя.
Тут наверное сохраняется структура, типа

gates["RUDEX.BTC"].deposit = {
get_address: "https://api.rudex.org/?golos=$login"
}

Только так: другого варианта не вижу.
Ну и приложения в этом случае смотрят, что нет привычных полей, и тогда проверяют наличие get_address. После чего вызывают URL и получают адрес, например, в Bitcoin (кроме него ничего не должно быть на странице: просто строка с адресом).

Пока же этого нет, да и предложение вовсе не уверен, что будет реализовано, сделал вручную и без проверки get_address.

Всё

Напоминаю, что в кошельке https://dpos.space/golos/wallet, если кликнуть по UIA токену (должен быть в списке), появится список действий.
Если вы выбрали YMRUB или PRIZM, увидите помимо "перевести (токен)" и "обменять (токен)" ещё либо пополнение с выводом (YMRUB), либо только вывод (PRIZM).

С вами был незрячий разработчик, делегат и автор @denis-skripnik. До встречи в новых постах.


Comments 15


@denis-skripnik напиши с учетом изменений в каком виде ты ожидаешь gate в json_metadata к UIA?

как вариант, возможно задействовать плагин account_notes который добавляли в 19 ХФ, в планах его использовать для форумов, а значит включим на нодах + правки в JS либе

из вики

Возможность пользователя хранить личную информацию в хэш-таблице хранилища в виде key-value

Объем информации для хранения на отдельном Узле (ноде) блокчейна определяется с учетом ресурсов этого Узла.

В плагине account_notes реализован вызов операции set_value_operation, выполняющей создание, изменение и удаление записи в хэш-таблице хранилища. Операция вызывается с полями account, key и value.

Для изменения записи в хэш-таблице операция вызывается с ключом уже имеющейся записи. Для удаления записи в хэш-таблице операция вызывается с ключом уже имеющейся записи и пустым значением.

В конфигурационный файл config.ini нод добавлены следующие настраиваемые параметры:
— an-tracked-accounts — «белый» список аккаунтов. Используется для задания списка аккаунтов, которым разрешено сохранять записи. По умолчанию задается пустое поле, разрешающее хранение записей всем аккаунтам;
— an-untracked-accounts — «черный» список аккаунтов. Содержит список аккаунтов, которым не разрешается хранение записей. По умолчанию задается пустое поле;
— an-max-key-length — максимально допустимое количество символов в ключе. По умолчанию содержит значение 20;
— an-max-value-length — максимально допустимое количество символов в записи. По умолчанию содержит значение 512;
— an-max-note-count — максимально допустимое количество записей для одного аккаунта. По умолчанию содержит значение 10.

В случае превышения в сохраняемой записи установленных граничных значений операция не выполняется. При этом сообщение об ошибке не выдается. Для контроля успешного сохранения информации пользователь должен запросить у Узла его текущую конфигурацию и сопоставить данные сохраняемой записи с граничными значениями этого Узла.

19.11.2020 18:56
0

я про json_metadata в asset_create и asset_update. Там сейчас только image и description, а можно добавить и gates.

19.11.2020 19:00
0

@denis-skripnik понял, ну вместе с какими-то правками добавим и это воркеру, если нужно. Только без изменений в веб-клиенте gates где и в каком формате заполнять будут, у тебя?

19.11.2020 19:05
0

Вообще это скорее делают те, кто создают скрипты. В любом интерфейсе непросто это делать, т.к. там назначение переменных и прописывания их значений... В общем, создатели шлюзов (скриптов шлюзов). А Клиенты лишь отображают инфу по вводу и выводу.

19.11.2020 19:36
0

@denis-skripnik ну да, я вот тоже думаю это чисто в код добавить, а уж кто будет пилить шлюз - заполнит gates

19.11.2020 19:39
0

@lex я думаю, что заполнять эти переменные должны сами шлюзы. тк. я лично против, чтобы была указана прямая ссылка для перевода (как вот щас в посте Дениса) вместо его номера. по номеру могут переводить и из приложения и из браузера - есть выбор. при ссылке - выбора меньше, а комса больше :) я бы мог просто в обменке настроить обмен через мерчант, как было раньше. но вот здесь решил дать "большую свободу" в выборе.

19.11.2020 19:59
0

Прикол в том, что можно давать ссылку, а можно и не давать. Я у себя сделал со ссылкой пока, а также рядом разместил кнопку "копировать", после клика по которой в буфер обмена помещался адрес кошелька без какого-либо html кода.

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

19.11.2020 20:03
0

@ecurrex-ru так этот условный "gates" только ты сможешь заполнять (как эмитент UIA), это же по сути допполе в json_metadata
где пока только урл картинки тикера и поле для ссылки на описание актива

ну а о формате, тут как договоритесь (эмитенты, сервисы)

19.11.2020 20:09
0