Loading...
Normal, Gallery, Tree
Вот опишу тут предварительную идею мессенджера.
Нам нужно:
  • IPFS – 1 шт. Просто установленный и запущенный демон. Возможно другие аналоги
  • Блокчейн 1 шт. С коротким временем формирования блока, причем нужны не все блоки, а только хвост в n-последних блоков
  • Небольшое поле данных вместо или вместе с транзакциями.
Все, основа для работы мессенджера уже есть, все остальное совести интерпретации клиента.
Как это будет работать
Допустим нека отправляет соримаку сообщение.
1. Текстовое сообщение подвергается компрессии, шифруется открытым ключом соримака и подписывается ключом неки.
2. Зашифрованное сообщение добавляется ipfs.
3. Формируется транзакция, содержащая зашифрованый и подписанный IPFS-адрес сообщения, адрес отправителя и получателя и рассылается узлам. В зависимости от реализации, транзакция "усилена" PoW, либо небольшой комиссией. Что нужно для защиты блокчейна от спама.
4. Соримак либо сразу видит транзакцию, либо увидит её после добавления в блок и синхронизации блокчейна.
5. Пытается расшифровать содержимое сообщения, в случае успеха получает IPFS-адрес.
6. Загружает сообщение через IPFS
7. Расшифровывает своим закрытым ключом.
Плюсы, в сравнении с другими мессенджерами
По сравнению с Tox мы получим:
  • в некоторой степени офлайн доставку сообщений, так как нужен только запущенный IPFS-демон отправителя, а он может быть любым, хоть публичным гейтом.
  • Возможность генерировать и одновременно использовать любое количество адресов. Все прелести HD-адресов, никаких паролей и возни с сохранением файловых бекапов.
  • Общую историю для всех устройств
По сравнению с bitmessage
  • Снижение количества передаваемых данных, так как передаются только IPFS-теги.
  • Преимущество новых и самых лучших форков биткоина, в случае реализации как форка
  • Возможность создания легкого клиента
Отдельный плюс – несложная реализация, так как подобные альткоины уже есть, нужно только адаптировать. Либо же можно взять за основу тот же bitmessage.
Тут есть два пути:
Полноценный альткоин
Плюсы: мотивация узлов на обслуживание сети, у всех пользователей стазу есть и кошелек, полезные плюшки биткоиновых BIP'ов, основа для мобильного клиента.
Минус: нужен весь блокчейн (хотя-бы майнерам), платные сообщения и более высокий порог вхождения из-за этого.
Мессенжер с хвостовой цепочкой блоков без криптовалютной составляющей
Плюсы: не требуется хранить неактуальные блоки, простота использования и возможность изменять и улучшать протокол, например алгоритмы формирования блоков.
Минусы: малая мотивация к содержанию полных узлов, формирующих блоки, отсутствие либо низкий уровень развития существующих реалиаций.
Тащемта в матриксе история сообщений хранится в виде блокчейна. Разница в том, что там нужен сервер – но ты можешь поднять свой, это будет то же самое.
>>34065
>история сообщений хранится в виде блокчейна
Тут же в блокчейне не хранится история, сервер не нужен, Связь с пирами нужна, и то не везде.
>>34076
>Тут же в блокчейне не хранится история
Тогда зачем он вообще?
>>34077
Для хранения адресов, где хранятся сообщения. Выше же написал.
Не, не то. В общем я уже понял, как надо. Будет полноценный форк.
Основная фича: к каждой транзакции может быть добавлен небольшой объем данных. Достаточный для хранения IPFS-меток, хешеё торрентов, биткоин адресов и так далее в зашифрованном виде. Интерпретация значения полностью на приложении, которое будет использовать систему.
Определенные адреса (нулевой) будут с заранее известным открытым ключом, отправка сообщения на них будет приравниваться к открытой публикации.
На что это похоже: на системы типа Namecoin или Emercoin. Только вместо пар "имя" – "значение", будут только значения.
Для любого адреса можно получить историю значений, и если ты имеешь к ним доступ, или они публичные, ты можешь их просмотреть.
Это будет такая глобальная система хранения индексов, адресов и т.д. Много лучше чем DNS и все подобные системы, так как не подверженна болезням, вроде домейнинга совсем. Более того, содержание пар ключ – история значений много лучше, чем просто ключ-значение. Так как можно использовать один адрес для всего. Разные приложения будут находить в истории только значения своего типа.
Например, можно полностью сайт разместить в IPFS, а доступ к нему получать через по *coin-адресу. И обновлять значения по обновлелию контента.
Стоимость записи будет равна величине комиссии майнеру и очень низкой.
Пиши whitepaper со схемами и примерами, иначе я ничего не понял.
>>34079
>Пиши whitepaper со схемами и примерами
Нужно ещё проработать криптовалютную часть. Есть какие пожелания?
* Добавление к транзакции короткого сообщения.
* PoW - усиленные адреса: адрес начинается с некоторого количества нулей, которые усекаются. Для снижения адресной пыли.
* Гетерогенный, гибридный PoW-PoS майнинг.
* Нулевой(открытый) адрес.
* ZeroCoin (?) хотя не знаю, насколько это нужно
* Адаптивная эмиссия (?) либо инфляционная эмиссия.
>>34082
>Гетерогенный, гибридный PoW-PoS майнинг.
А есть статья по PoS? Кто-то мне кидал статью, но я не помню кто и где.
>>34079
На самом деле, вместо идентификатор сообщения является идентификатором на полную цепочку идентификаторов всех сообщений отправителя. Тогда сообщения вообще не могут потеряться, потому-что если получатель слишком долго не был в сети (долше времени охватываемого используемой частью блокчейна) то все равно сможет загрузить пропущенные до последнего сообщения. Это не очень важно для мессенджера, но может быть важно для других применений, где нужна вся история сообщений (изменений, постов).
>>34208
Добавляемые к транзакции данные 256-bit, по сути хеш во вне, оиносительно блокчейна. Сейчас думаю чтобы выкинуть нафиг Script, унифицировать заголовок блока с транзакцией. Тогда это будет транзакция, в которой хеш будет корнем MerkleTree для транзакций составляющих блок. Но пока не уверен.
https://en.bitcoin.it/wiki/Proof_of_Stake
ещё есть https://en.bitcoin.it/wiki/Proof_of_burn
У меня вот даже идея Proof-of-Usе
Доказательство использования.
Активные пользователи, тоже могут создавать блоки, компенсируя этим свои расходы. Главное, чтобы суммарная награда за блок была ниже, чем потраченное пользователем. Чтобы у него не было мотивации делать фальшивые траты.
Пропускная способность
Со всем всем всем максимальный размер транзакции получается около 1KB, в минимальном виде около 300B. Если у биткоина, например, при одном мегабайте на блок получается 7 транзакций в секунду, 150 мб в день и более 50 GB год, то у меня 3 - 7 транзакции. Полные узлы нужны только майнерам, но даже в этом случае следует учитывать, что блок должен разноситься по сети быстрее, чем делаться. Из-за чего у меня диллема. Делать его слишком тяжелым, хотя его все равно будет недостаточно для всего P2P обмена, и приложениям нужно будет взаимодействовать офчейн, записывая в блокчейн только важные данные.
Либо же делать максимально легким, с дорогим местом в блоке, тем самым стимулируя оптимизацию его использования? Легкий вариант будет более быстрым, разве что.
Pointer(Coin) PTR
—————–
* Примерный размер транзакции 250 - 1000 байт
* Размер поля данных 512 байт
* 1 блок / 30 секунд, 100 KB
* Спецификация майнинга. В зависимости от номера блока и хеша предыдущего блока меняется тип блока, Для каждого блока свой алгоритм майнинга и сложность.
* Адаптивная награда за блок. Стремится к средней величине комиссии в 1 PTR/KB. Константная составляющая на момент запуска. Адаптивная составляющая увеличивается на 5% каждый месяц, после 20 месяцев полностью переходит на адаптивную. Пересчет награды за блок каждый месяц. Возможна ситуация с нулевой наградой за блок.
* 0.1% (?) комиссии считается "уничтоженным". Позволяет сокращать объем валюты условиях нулевой награды.
* Заданного максимального количества монет нет, но складывается в зависимости из потребности/используемости системы.
* Премайн 5*t блоков, где t-количество типов блоков.
Предварительный набросок.
Сравнение с аналогами
SCAMNAME ALGO NAME FIELD VALUE FIELD TIME COST UPDATE DELETE
NameCoin PoW 255 1023 ~200 days 0.01 0.00 N/A
Emercoin PoS/PoW 512 20*1024 variable* 0.17* 0.12* 0.00
Datacoin PoW – 128k permanent 0.05 – –
Pointer multiple – 512 permanent 1 – –
>>34104
Алогритм нахождения блока – хэш-лотерея + PoS + PoW. Последние цифры хэша текущего блока определяют блоки, участвующие в минтинге. Степень сходство хэша транзакции в участвующем блоке с хэшем текущего блока снижает сложность PoW.
В биткоине, альткоинах, onion-сервисов часто ищут "красивые", начинающиеся с какого-нибудь слова, например
https://neboardo3svhysmd.onion/
Фактически, это означает что часть адреса легко можно подобрать, и использовать её не очень эффективно. Таким образом если ввести требования, чтобы адреса начинались с определенной строки(значения), уже можно считать, что оно есть по умолчанию.
Например
    neboard    o3svhysmd
Я не знаю, почему onion адреса такие маленькие, и действительно ли они надежны.
Вот что получилось с биткоина.
Считаем, что первая единица не нужна, тогда поиск трех следующих знаков у меня уходит меньше минуты.
Некоторые мысли появились насчет PoS, получается свести необходимость PoW к минимуму.
Деньги не нужны?
Что если убрать всю "денежную" составляющую глубоко во внутрь и вообще целенаправленно затруднить использование как валюты. (Например сложный алгоритм сравнения, где большее значение не всегда большее, произвольное уничтожение и просрочку монет). Таким образом можно вовсе урезать блокчейн до N-последних блоков(cоответствующий определенному временному промежутку), а для остального хранить цепочку заголовков до генезис блока и все. И если не делать его "блокчейном для всего", а адаптируемым под конкретное приложение, то можно делать на нем P2P сети в которых все узлы будут полноценными и все. А легкий клиент будет возможен только если разделяет одни и те же ключи с полным узлом.
Мне нехватает маны для постинга на имиджборд.
Может вообще возникнуть вопрос, зачем все это нужно.
Цель первая: все узлы известны. Так как блокчейн известен всем узлам, а информацию друг о друге узлы узнают из блокчейна, то они все известны друг-другу. Информация не сможет потеряться между узлами сети, если она попадает в блокчейн, она считается опубликованной и известна всем (Естественно, что при этом она может быть защифрованна и предназначаться кому-то конкретно, и другие узлы даже могут не знать кому). просто отсутствие потерь.
Цель вторая: Общая история. То есть, если на момент отправки сообщения адресат не в сети, отправитель все равно может отправить сообщение. Адресат, как минимум, увидит уведомление. Опять же, даже если отправитель теперь не в сети. Фактическая загрузка сообщения произойдет в тот момент, когда это будет возможно.
Цель третья: добросовестное использование. Система очень усложнит возможность спама узлов. Таким образом это ещё и полностью заменяет необходимость капчи.
Потому я вопрос "а нужны ли деньги" задаю даже в некотором глобальном смысле. Так я считаю деньги вообще есть система распределения ресурсов, и защиты от недобросовестного использования. Хотя она это очень неэффективная система. Так что нужно ли вообще переносить эту неэффективность в сеть? Биткоин тоже показывает свою неэффективность в этом смысле. Во первых, у узлов слишком много возможности накапливать монеты. Так имея не очень большую сумму, уже можно эффективно заспамить сеть. Да, это дорого, но это вполне возможно сделать тем, кто может себе это позволить. Во вторых, до сих пор нет не одного приложения, использующего биткоин с этой целью. В третьих, "денежное" применение требует ненужных костылей, например, то что транзакции не анонимны, это уже как следствие.
Еда по талонам
Да, что-то такое. Участвуя в формировании блоков, узел получает монет, который может использовать для записи сообщений n-сообщений в m-последующих блоков. Цель же PoS-алгоритма: эфективно распределить вероятность нахождения блока каждым узлом.
Исходя из этого, какой размер блока и время создания подойдет если исходить из того, что:
  • Запись имеет размер 1 кбайт.
  • Длина хвоста цепочки заранее определена и заранее известен максимальный размер требуемого дискового пространства (что вес цепочки заголовков достаточно мал, чтобы им пренебречь).
  • Блок после нахождения должен успевать доставлятся узлам, которые являются простыми пользователями.
Небольшой бамп.
Допустим, я собираюсь сделать альтернативный клиент для Twister. Это не так, но это поможет понять суть задачи. Цель – более удобный интерфейс для пользователя, чтобы не требовалось отдельно запускать демона и заходить через браузер. С другой стороны, пользователям привычно пользоваться интерфейсом на html+js+css, и классические GUI тулкиты плохо подходят для такого. И не случайно, потому-что интерфейсы такого рода уже существуют много лет, и они хорошо адаптированы под задачу. По этой причине, первая мысль, на чем делать интерфейс – Electron. Такое даже используется в подобных случаях, например в Sia. Но его не все любят из-за прожорливости и, возможно, не только. На чем ещё можно такое писать? Qt/QML подходит? Или есть какие ещё примеры?
>>35547
>Цель – более удобный интерфейс для пользователя, чтобы не требовалось отдельно запускать демона и заходить через браузер.
Но зачем? Это же модульность и юниксвей. Браузер это удобный инструмент для фронтэнда, а демон – это демон, которого можно вынести в сеть. Я считаю, надо вообще все приложения запускать в браузере, а браузер сделать DE.
>>35553
Причин несколько. Во первых не нужны многие фишки браузера, например полная адресная строка, https, куки и прочее. Во вторых – более тесная интеграция с десктопом. В третьих, отсутствие необходимости держать сервер, что может быть лишней уязвимостью. В четвертом, более удобный запуск приложения. Вот представь что текстовый редактор atom работал бы через браузер.
Но в общем, ты согласен что нужно в html, и что классические десктопные GUI тулкиты плохо для этого подходят.
>>35554
>Во первых не нужны многие фишки браузера, например полная адресная строка, https, куки и прочее.
Адресная строка нужна для закладок. Чтобы не реализовывать закладки каждый раз с нуля в софте.
https нужен для того чтобы прокинуть демона через сеть и защитить соединение.
Куки это настройки.
Всё вышеперечисленное нужно
>Вот представь что текстовый редактор atom работал бы через браузер.
Он и так работает через браузер. Только если ты запустил 10 атомоподобных приложений, в памяти будет висеть 10 браузеров. И обновлять все 10 нужно будет отдельно целиком.
>более удобный запуск приложения
Согласен, для standalone приложения демон это немного Эребор.
>>35554
>например полная адресная строка
Вот это и самая проблема. Web-интерфейс через браузер приводит к тому, что потом ссылки вида http:127.0.0.1:port/. Это в случае с локальным по вообще ненужная хрень. Вон в зеронете уже из-за принято так ссылки давать. Порт потому никто не меняет. Хотя с другой стороны, внутренние ссылки можно оформлять так, чтобы они сами транслировались в нужный тип ссылки в клиенте. А конкретные хранить просто как хеши. Но это еще нужно научить пользователя не ссылки постить, а хеши.
С другой стороны, web-интерфейс очень удобно использовать с docker.
>>36882
>Web-интерфейс через браузер приводит к тому, что потом ссылки вида http:127.0.0.1:port/
Ну в случае ipfs например ссылки дают на ipfs.io, а специальный плагин их преобразовует в 127.0.0.1
Но вот при наличии адресной строки, все равно избранное на неборде реализовано самостоятельно. Закладки слишком малофункциональны. https нужен ровно там, где он нужен. В моем случае, функционал проброса клиента будет немного избыточным. Потому что клиент сам предполагается разбить на части: демон работающий с блокчейном и интерфейс приложения. Первому до второго вообще нет никакого дела. А клиент можно запустить, там, где им нужно пользоваться.
Есть ещё причина не использовать браузер. Например, не все хранят историю и куки между запусками браузера(например я). Но хранить пользовательские ключи нужно, чтобы не вводить их всякий раз. Кроме того, доверять хранение приватных ключей браузеру несекурно.
>>35556
>https нужен ровно там, где он нужен.
Кэп?
>В моем случае, функционал проброса клиента будет немного избыточным. Потому что клиент сам предполагается разбить на части: демон работающий с блокчейном и интерфейс приложения.
Это удобно. Клиент пишется отдельно, демон отдельно. Тулкитофобы радуются.
>Например, не все хранят историю и куки между запусками браузера(например я).
Ты ССЗБ, и чо?
>>35557
>Кэп?
Я про то, что вопрос секурной передачи данных по сети вообще не стоит. А нужность возможности прокидывать гуй весьма сомнительна.
>Тулкитофобы радуются.
А браузерофобы нет.
>Ты ССЗБ, и чо?
Хранение закрытых ключей в виде куков или закладок в браузере вообще в подобной среде не есть хорошо.
>>35558
>Я про то, что вопрос секурной передачи данных по сети вообще не стоит.
Почему?
>>35559
>Почему?
End-to-End шифрование же.
>>35560
Это не отменяет шифрования между клиентом и демоном.
>>35561
Демон не хранит ключи.
>>35562
в wallet.dat
>>35558
>Хранение закрытых ключей в виде куков или закладок в браузере вообще в подобной среде не есть хорошо.
А где их хранить? Если совсем параноик, можно сделать браузер, в котором надо вводить куки руками при каждом запуске.
>>35561
Демон не хранит ключи.
>>35562
в wallet.dat
Нашел идеальный юзкейс – блоги. До этого думал про мессенджер, или про форум. Но так не к чему и не пришел: блокчейн характеризуется низкой пропускной способностью, а решение масштабируемости так ещё никто не реализовал. Даже форум характеризуется высокой активностью постинга. А вот блоги подразумевают редкие но содержательные посты. Только комментарии всё так же будут дороги, но срачи в комментах не так важны, потому-что в блогах важнее сами посты.
//Вообще такой подход используется в Alexandria и в разрабатываемой Akasha.
Только вот IPFS cырое глюкалово. Плюс, я предполагаю, что посты – это в первую очередь текст, они должны быть небольшими по объему и их можно случайным образом выбирать для раздачи, так чтобы контент и не хранился полностью на каждом узле, но был с высокой вероятностью доступен, даже если автор вышел из сети, а его блог никому не интересен. C IPFS это плохо получается, а торренты для этого немного тоже не очень: много мелких файлов, плюс секьюрность желательно выше. Наверно нужно велосипедить.
>>40102
>А вот блоги подразумевают редкие но содержательные посты.
Ты про блог отдельного человека? А зачем там блокчейн, если у него один автор?
>>40105
Для того чтобы каждому не приходилось хостить свой блог + для комментариев. А вообще я уже продумываю многопользовательские профили, одна из киллер фич может быть.
>>40105
>А зачем там блокчейн, если у него один автор?
Вон для примера twister. Да, автор один, но подразумевается что профиль не изолирован от всего мира, можно и всякие плюшки делать типа репостов из других профилей.
>>40131
Твистер в блокчейне хранит только регистрации пользователей.
>>40132
>Твистер в блокчейне хранит только регистрации пользователей.
Вот почему он так говенно работает.
Где-то видел табличку сложности майнинга onion-адресов. А сейчас найти не могу.