Пишу с самописного клиента tii

тест ответа 2

ВоÑ, теперь всё работает.
Интересное кинцо, однако...

--- Revoltech ---

Это ты у меня второй после гугла получился за предыдущие сутки? ;)

TOP10 VISITORS:

[1] Google point=10 web=1096 up=43.2MB (32%) <--- Google
[2] 145.224.100.x point=116 web=10 up=41.8MB (31%) <--- 145.224.100.x (5/hr) <<<<<<<<<<<<<<
[3] 176.109.111.x point=47 web=0 up=16.3MB (12%) <--- tavern (2/hr)
[4] 217.197.116.x point=142 web=0 up=12.0MB (9%) <--- blackcat (6/hr)
[5] Facebook point=0 web=401 up=7.6MB (5%)
[6] 92.63.98.x point=69 web=0 up=4.9MB (3%) <--- tgi (3/hr)
[7] 95.165.9.x point=125 web=2 up=3.1MB (2%) <--- ping (5/hr)
[8] 24.130.121.x point=37 web=9 up=3.0MB (2%) <--- spnet (2/hr)
[9] DataForSeoBot point=1 web=16 up=0.4MB (<1%) <--- DataForSeoBot
[10] 104.128.67.x point=0 web=3 up=0.1MB (<1%)

TOTAL TRAFFIC: 133MB

Нода на Tcl? ;)

...
145.224.100.164 - - [21/Oct/2024:05:27:24 -0700] "GET /iii/u/m/HaYwRbvCz0HDMhN2IrOU HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:24 -0700] "GET /iii/u/m/ymc21433dohplAzblytS HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:25 -0700] "GET /iii/u/m/bGF8asq7me3B7nMzrKRq HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:25 -0700] "GET /iii/u/m/XrdTe37AHd3m1aY3Oaw6 HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:25 -0700] "GET /iii/u/m/AhS5Q6mYGHzZzNdx9Lf3 HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
...

видо-видо :)

Надо наверное ii://idec.test в обязательном порядке протянуть на все ноды, чтобы народ тестовые сообщения в ii://idec.talks не слал...

revoltech> тест ответа

Привет! Для тестовых сообщений лучше пользоваться эхой ii://idec.test.

+++ Caesium/0.4 RC1

> Для тестовых сообщений лучше пользоваться эхой ii://idec.test.

Она не везде есть - на ping и tgi например её нету...

По идее на нодах со свободной регистрацией это должна быть единственная эха куда можно писать новичку, пока он не пройдёт проверку по полной программе ;)

Надо будет себе пометку на полях сделать...

Да, фетчер на Tcl. Пардон за трафик, тестировал туда-сюда.

Да вообще неплохо бы протянуть. Я ещё гуй на тикле хочу сделать, консольные вещи уже вроде отлажены.

> Пардон за трафик, тестировал туда-сюда.

Ну гугл тебе обогнать всё равно не удалось, так что ок ;)

С удовольствием, как только с tgi можно будет туда постить.

Кстати формат ответа неправильный:

ii/ok/repto/test
idec.talks
1729606618
revoltech
tgi,15
All
test

тест ответа

тут вместо repto/test надо писать repto/msgid где msgid является идентификатором сообщения на которое отвечаем...

Первоначальное сообщение было вот это: ii://xXufIMsKzDC1FFJ0Dh1g

Второй тест ответа вроде ок

revoltech> С удовольствием, как только с tgi можно будет туда постить.

Не уверен что эта возможность вообще будет. Судя по всему сисоп забил на сеть. Подумываю сменить, но лень

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

Сделал фетчер, учитывающи

й x/h.

у меня blcat.test, я не вижу смысла делать две тестовые эхи, а тем более их гонять :) тестовые обычно локальные эхи

shaos> А где /x/features ?

Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.

> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.

проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали

http://ii.blcat.ru/u/e/idec.talks/-100:100

idec.talks
nQi82oyWBVG04BKEAssb
[... cut ...]
vw94xxAktnhjmcpvvp7F
hua5b4LxCs1t9kF9HsTs
-100:100

А как тогда проверить, что оно нормально фетчится между нодами? ;)

а почему оно /u/e а не /x/e какое-нибудь. надо или делать ?s=X:X или /x/e, потому что запрос один, а реакции разные

Там же точки нету - там двоеточие
Значит проверку на соответствие имени эхи оно пройти не должно ;)

ahamai> проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает.

Это в каких таких эхах есть двоеточия в названии?

shaos> Там же точки нету - там двоеточие
shaos> Значит проверку на соответствие имени эхи оно пройти не должно ;)

Вот именно. Тоже хотел добавить.

Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?

Речь о том, как на это реагирует референсная реализация. Хреново :)

А поправить референсную реализацию? ;)

Стал забирать с тебя retro.talks

ну, во-первых, это единственные существующие реализации в сети, хранятся на github, моя нигде кроме этого сайта не хранится и начинать, наверное, надо, именно с них. не знаю, что будут делать клиенты с эхой -100:100 :)

А существующие реализации в сети не 100% IDEC уже? ;)

Ну я показал как моя станция на это реагирует

shaos> А где /x/features ?

А зачем она, если не будет расширений? Расширения были ошибкой.

shaos> Может их в виде /features.txt организовать? Всё равно это по сути статический текст…

Можно что угодно вертеть, но в стандарте этому не место.

+++ Caesium/0.4 RC1

>> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.
ahamai> проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали

В тмени эхи не может быть двоеточия. Так что не выглядит. Ну и просто будет пустой индекс невалидной эхи в ответе. Это ничему не навредит.

+++ Caesium/0.4 RC1

ahamai> а почему оно /u/e а не /x/e какое-нибудь. надо или делать ?s=X:X или /x/e, потому что запрос один, а реакции разные

Делай как угодно. Стандарт есть стандарт. Большинство его соблюдает вполне успешно даже сейчас.

+++ Caesium/0.4 RC1

shaos> Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?

Надо на таверне проверить. Старше сейчас, вроде, ничего нет.

+++ Caesium/0.4 RC1

ahamai> Речь о том, как на это реагирует референсная реализация. Хреново :)

А у нас пока нет референсной реализации. Стало быть никак не отреагирует.

+++ Caesium/0.4 RC1

shaos> А существующие реализации в сети не 100% IDEC уже? ;)

У Ромы никогда не было IDEC-ноды. Блин. Научить фетчер работать без слайсов с некоторыми аплинками - задача на 2-3 лишние строки кода. Проблема высосана из пальца.

Если бы IDEC был ii, то он бы назывался ii.

+++ Caesium/0.4 RC1

ahamai> Ну я показал как моя станция на это реагирует

Реакция твоего узла странная, но ни к каким последствиям не приводит.

+++ Caesium/0.4 RC1

это как так? перечисляемые расширения были основной фишкой IDEC :(

вот например мой /x/features прямо сейчас:

u/e
u/push
list.txt
list.txt?h=1
listhsh.txt
blacklist.txt
x/c
x/h
x/file
x/filelist
node.json

Ну у него эхи без цифр, значит уже наполовину IDEC ;)

AL> Словарик будет отдельным документом.

Лучше в самом документе словарик иметь.

shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(

Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.

revoltech> три из них являются частью стандарта

Пардон, /u/push не увидел. В таком варианте — даже четыре.

А как же делать кастомные расширения теперь?...

shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(

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

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

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)

Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)

Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись 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 Authentication
https://datatracker.ietf.org/doc/html/rfc2104

RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286

RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://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)

Обсуждаем? :)