Wallets discovery and dialog proposal

Wallets discovery and dialog proposal

Общее

1. Для согласования TX между кошельками происходит диалог, согласно протоколу, но туда надо добавить возможность включать произвольную информацию в пределах разумных размеров (например, любой текст, который увидит человек или любые бинарные метаданные, если общается бот или какая-то логика более высокого уровня)

2. Для шифрования сообщений вполне пойдет принцип PGP, для чего 2м кошелькам достаточно знать публичные ключи друг друга. Рандомный ключ (+ I.V.) для AES например 256 шифруется публичным ключом собеседника (а последний может быть и RSA и EC, не важно), остальное сообщение AESом с помощью зашифрованного ключа.

3. Главное: публичные ключи, о которых пойдет далее, относятся только к шифрованию диалога, к процессу формирования UTXO и логике самого кошелька в целом они не имеют никакого отношения

4. Ситуации, когда одна сторона не знает, кто к ней обращается (например, некий бот собирает пожертвования на храм Бахуса и Венеры, или это обменник (*ниже)). Такой кошель уже по определению теряет часть своей анонимности и может опубликовать свой публичный ключ тем или иным образом. Доверять ли этой публикации решает сам инициатор диалога (ну вот, в качестве примера возьмем имеющиеся монетки с адресацией, когда сам адрес является ПубКл кошелька - слать туда или не слать решаем сами). Этот инициатор тогда посылает свой публичный ключ в первом сообщении

5. В секьюрных случаях Публ ключ может быть передан по какому-либо секьюрному каналу (телеграм и т.п.) между знакомыми и вставлен в кошелек

Публикация публичных ключей (для диалога!). Это все опции, имеет смысл реализовывать все что возможно

1. Есть PGP key services, которые изначально были в помощь шифрованию email, но и тут могут пригодиться. По какому либо идентификатору можно заполучить программно ПублКл

2. Децентрализованный вариант, как еще одна опция. Ключи храним на IPFS (https://ipfs.io), но там имя файла человеческое не задать, поэтому мэппинг имя->ключ можно организовать в виде смартконтракта на Eth (запись будет стоить публикующему немного, ибо это транзакция, чтение бесплатно)

3. Прям у себя на сайте (зеленый замочек в браузере виден? копируйте-вставляйте в кошель). Или ссылку на ipfs в виде QR кода (сам ключ длинноват для QR)

Secure channel. Тоже опции

1. Связь по TCP напрямую. Самое быстрое и простое, оба кошеля должны быть в онлайне. Но все будут знать, что эти 2 IP общались между собой

2. Через прокси (ретранслятор). Когда кто-то или оба из кошельков за файрволлом. Тоже должны быть в онлайне, и факт общения может быть установлен. Можно запустить подобные ретрансляторы, а список известных адресов могут выдавать ноды в рамках протокола.

3. Через инфраструктуру мессенджеров. Надо поизучать вопрос об интеграции с их АПИ. Но тут получается, что пациенты совсем друг друга хорошо знают и имеют в контактах мессенджера. Но зато есть возможность быть в оффлайне во время диалога.

4. Броадкастить (по крайней мере 1-е сообщение диалога) через инфраструктуру beam nodes. Сообщение распространяется по сети с некоторым убывающим TTL и с высокой вероятностью доходит до кошелька. Почему ноды могут быть заинтересованы в ретрансляции этого хлама? Ну если они майнят, то такое общение может обернуться неким txFee > 0 через какое-то время. Тут проблема как экономически бороться с флудом, поскольку сообщения шифрованные, и ноды их никак валидировать не в состоянии. Может в таких случаях обязать какой-нибудь PoW приделывать к сообщению? При этой схеме тоже все стороны должны быть в онлайне и прицепиться к нодам сети на предмет прослушки таких броадкастов (и фильтрации своих из общего потока с помощью своего приватного ключа).

5. BBS service - это ретранслятор + история. Отдельная сеть из узлов, которые реализуют "общую шину" для данного рода сообщений. Клиент может прицепиться к одному или нескольким таким каналам, получать по запросу некоторую историю сообщений и в реальном времени фильтровать входящие. Здесь cons и pros как что в предыдущем пункте, но есть и хорошее: 1) можно слушать из N существующих каналов M<N, сообщение соответственно может быть доставлено в соответствии с какими-то битами публичного ключа в M каналов, а не все N, получатель об этом знает, но факт того, что он переварил то или иное сообщение, скрыт. 2) Оффлайн до определенной глубины времени

6. Объединение №4 и №5: сообщение гуляет по сети и попадает в BBS так или иначе. За счет рандомного TTL затирается из истории адрес отправителя, за счет BBS неизвестен получатель.

7. Случай когда слушатель каналов маломощный вроде мобильного клиента и/или ограничен в трафике: частично жертвуя анонимностью, поручает BBS сервису фильтровать для него канал. Для этого вместо одного публ. ключа нужно 2 штуки: 1) Selector public key, 2) Messaging public key Соответственно протокол диалога обогащается еще одним заголовком - некие позывные (не секретные) шифруются ключом селектора, остальное уже секретный канал

Что хотелось бы в UI и в целом в приложении

1. Address book - хранилище имен контрагентов и их публичных ключей. Имена уникальные лишь для этого кошелька, никакого центрального хранилища имен не надо

2. Возможность ввести публичный ключ из clipboard и придумать для него имя

3. Отображение сообщений, которые приходят как мета с сообщениями протокола. В этом случае владелец кошелька (или его бот) подтверждение пусть дает после приема каждой подобной меты, продолжать ли диалог

4. Возможность поиска публичных ключей во внешних хранилищах: pgp key services, решения на ipfs и т.д.

5. Возможность генерации своих ключей для общения, публикации публичной части под каким-либо никнеймом, индивидуальной передачи публичного ключа собеседнику по любому каналу (через telegram secret channel как пример)

6. (??? спорный момент) Интеграция кошелька с АПИ мессенджеров

(*)(atomic swap отдельная тема, тут надо придумать как можно лочить TX с помощью любых видов хэшей, присутствующих в других блокчейнах, опционально и в дополнение к тому что есть, за большее fee конечно, ... ...)