Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Расширенные правила форматирования текста в ii/idec: https://club.hugeping.ru/rOf069UX8K24yAzvWa9NПока работают только на этом конкретном сервере написанном на Go - надо такое в мою PHP-ноду тоже добавить... P.S. Например там отображаются добавленные в текст сообщения картинки в формате XPM
|
23 Sep 2024 17:50 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
В своё время забыл опубликовать тут скриншоты текстового клиента IDEC, написанного на питоне:
|
23 Sep 2024 23:45 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Настроил Rewrite чтобы урл для ii-клиентов был проще - теперь вместо домен/ii-point.php?q=/ можно просто писать домен/iii/ т.е. чтобы запросить список эх в текстовом виде надо вызвать https://sprinternet.io//iii/list.txt(к этому же серверу можно по http:// обращаться, но через порт 8080: sprinternet.io:8080/iii/list.txt) А открыв http://sprinternet.io:8085 можно перепрыгнуть прямиком в веб-интерфейс моей ii/IDEC-ноды по старому адресу http://shaos.net:8085/ii-web.php
|
29 Sep 2024 00:23 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Стал раз в сутки по апачи логам считать самых активных качальщиков ноды - в списке как другие ноды сети IDEC, так и боты типа Google, Facebook и Yandex: Строка пишется внизу вебстранички слева... P.S. Плюс ещё в специальную эху посылаю ежедневный отчёт - вот например данные за 2 октября: см. https://sprinternet.io/iii-web.php?echo=spnet.stats
|
02 Oct 2024 23:29 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
| | | | Shaos wrote: Далее по всему этому считается хэш SHA256 (32 байта), бинарное представление которого переводится в base64 (что даёт 43 символа), от которого берутся первые 20 символов (46.9% от всей строки), но т.к. base64 наряду с буквами A...Z a...z и цифрами 0...9 ещё имеет 2 дополнительных небуквоциферных символа + и / для пущей читабельности они заменяются на символы A и z (именно так - большая A и маленькая z) - уникальность хэша от этого немного портится (покрытие уменьшается в 1.88 раз с 64^20 до 62^20, что даёт 7e35 вариаций), но хэш становится "безопасным" для передачи как угодно. ... P.S. А вот относительно новый сервер ii-go, написанный на Go, заменяет небуквоциферные символы на A и Z (большую) - собственно так и было написано в документации (как пример). И плюс к этому разрешает редактировать сообщение после того как ему уже присвоен ID и оно сохранено на сервере (и даже уже передано на другие сервера) - при этом содержимое сообщения меняется, но его хэш остаётся прежним, что несколько противоречит всей концепции.
P.P.S. Если бы не последнее исключение (и ряд старых сообщений, в которых хэш считался как-то иначе), то имя сообщения можно было бы использовать как уникальный адрес объекта в сети IDEC - на всём этом можно было бы городить распределённое хранилище файлов и т.д. | | | | |
Ради интереса посчитал статистику по соответствию хешей названиям мессагов В старом ii архиве (46481 штук): 81.6% названий соответствуют хэшам 18.4% не соответствуют (например сообщения были отредактированы уже после того как сервер их посчитал) В новых ii/IDEC мессагах (20760 штук): 28.0% названий соответствует хэшам 0.4% соответствуют после приведения к нижнему регистру (значит была подмена на Z вместо z) 71.6% не соответствует (почему стало так много непонятно)
|
06 Oct 2024 02:27 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Первоначальный автор протокола ii (которому в марте этого года стукнуло 10 лет [протоколу стукнуло - не автору]) решил тряхнуть стариной и выкатил свой новый ii-сервер пропиарив его на лоре https://www.linux.org.ru/forum/general/17755587P.S. А лор похоже уже не торт...
|
11 Oct 2024 10:00 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Автор сети и протокола ii (теперь он ходит в сеть ii под ником iiii) воссоздал эху про старые компьютеры у себя на узле http://ii.blcat.ru, составив её из старых сообщений старых эх oldpc.51t.ru (2020) и old.pc (2022) - я держу копию эхи у себя: https://sprinternet.io/iii-web.php?echo=retro.talks
|
13 Oct 2024 21:31 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Автор зарелизил облегченный ii-сервер, в составе которого уже есть эха retro.talks на почитать
|
14 Oct 2024 18:51 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
| | | | Shaos wrote: Интересный способ идентификации сообщений выбран в ii (перекочевавший затем в IDEC и использующийся в двух самых старых серверах реализующих этот протокол - ii-php написанном на PHP и iing написанном на Python) - сервер формирует текст сообщения для сохранения добавляя к нему заголовки, а именно: - tags - теги (используются только для `repto` и для идентификатора `ii/ok`)
- echoarea - основная эхоконференция, в которую помещается сообщение
- date - число секунд от эпохи unix, в utc
- msgfrom - отправитель
- addr - адрес отправителя (практического смысла не имеет, служит для того, чтобы узнавать, с какой станции пришло сообщение)
- msgto - пользователь, которому предназначено сообщение (либо All)
- subj - тема сообщения
- пустая строка
- и далее - текст сообщения
Пример из документации: (в данном случае наличие ключевого слова repto в тегах означает, что это сообщение является ответом на сообщение с указанным ID - здесь IZXhLBKJx0rhx0lXYu3L) Далее по всему этому считается хэш SHA256 (32 байта), бинарное представление которого переводится в base64 (что даёт 43 символа), от которого берутся первые 20 символов (46.9% от всей строки), но т.к. base64 наряду с буквами A...Z a...z и цифрами 0...9 ещё имеет 2 дополнительных небуквоциферных символа + и / для пущей читабельности они заменяются на символы A и z (именно так - большая A и маленькая z) - уникальность хэша от этого немного портится (покрытие уменьшается в 1.88 раз с 64^20 до 62^20, что даёт 7e35 вариаций), но хэш становится "безопасным" для передачи как угодно. При передаче сообщения между сервером и клиентом также используется base64 (но только всего сообщения) - в виде base64url, в котором + заменяется на - а / заменяется на _ | | | | |
Для отправки сообщения от клиента к узлу ii/IDEC с самого начала применяется следующий формат: Пример: Это сообщение заворачивается в base64url и засылается на узел либо через метод GET: URL/u/point/PAUTH/B64STRINGлибо через метод POST: URL/u/point pauth=PAUTH&tmsg=B64STRINGгде PAUTH - строка авторизации для данного пользователя (поинта) - по сути пароль (который должен быть свой для каждого поинта). Как можно видеть тут прямым текстом в сеть передаётся пароль - даже в случае https:// если он идёт через GET, то он считай засвечен (а в случае http:// будет засвечен и через POST), поэтому я думаю можно сделать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC: RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authenticationhttps://datatracker.ietf.org/doc/html/rfc2104RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128https://datatracker.ietf.org/doc/html/rfc2286RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AHhttps://datatracker.ietf.org/doc/html/rfc2857Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8: URL/u/point2/koi7/B64AUTH/B64STRINGдля больших сообщений можно задействовать метод POST: URL/u/point2/koi7/B64AUTH TEXT
причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
|
28 Oct 2024 23:30 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
т.к. ii/IDEC передаёт сообщения в UTF-8, то там можно не только русский текст гнать, но и например emoji
|
01 Nov 2024 07:45 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Нашлась VK-шная копия пропавшей обзорной статьи про IDEC от сентября 2018: https://vk.com/@hatahack-ii-idec(копия датируется 2020 годом) P.S. Немного из истории создания IDEC (эха ii.14 ни у кого не сохранилась): https://web.archive.org/web/20170515203311/http://club.syscall.ru/:ii.14
|
06 Nov 2024 22:24 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
2 последних старожила IDEC отвалились - это hugeping.tk / club.hugeping.ru (нода ping) и idec.spline-online.ru (нода tavern) осталась относительно новая нода tgi - https://tgistation.ru (создана в 2021 году, но её сисоп не выходит на связь) и моя нода, которая недавно сменила название на spnet - https://sprinternet.io/iii/ а также уже месяц существует новый вебсайт-нода http://ii.blcat.ru от создателя ii (соответственно эта нода не поддерживает навороты IDEC)...
|
09 Nov 2024 23:45 |
|
|