Всем привет кто ещё тут!
Какое-то время назад в эхе idec.talks прилетело ко мне сообщение не в тему (причём со старой датой):
http://shaos.net:8085/IDEC-dup.png
А сегодня я обнаружил, что хэш этого сообщения упоминается в двух эхах:
idec.talks:v2gj6Qx0JJmoNlcjcJlg
lor-opennet.17:v2gj6Qx0JJmoNlcjcJlg
Получается в idec.talks пришло сообщение, которое по хэшу совпало со старым сообщением от сентября 2019 года в lor-opennet.17?

Shaos

Похоже от этого же сообщения также поплохело эхе lor-opennet.17 на Таверне:

http://idec.spline-online.ru/v2gj6Qx0JJmoNlcjcJlg

Она как бы застряла на нём как на последнем, однако оно вовсе даже старое...

shaos> Какое-то время назад в эхе idec.talks прилетело ко мне сообщение не в тему (причём со старой датой):
shaos> А сегодня я обнаружил, что хэш этого сообщения упоминается в двух эхах:
shaos> idec.talks:v2gj6Qx0JJmoNlcjcJlg
shaos> lor-opennet.17:v2gj6Qx0JJmoNlcjcJlg
shaos> Получается в idec.talks пришло сообщение, которое по хэшу совпало со старым сообщением от сентября 2019 года в lor-opennet.17?

Дождались коллизий, похоже. Возможно, придётся менять хеш-функцию как-то. Но это потом. За 10+ лет это первый случай, вроде. Так что маловероятно, что он повторится в ближайшее время.

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

Наверное текущие хэши всё также ок - просто надо чтобы IDEC сервера (и наверное клиенты) были готовы к возмжным коллизиям - а то сейчас получилось, что новое сообщение пропало, а на его месте в idec.talks показывается старое сообщение из lor-opennet.17 с тем же кодом - по идее надо в idec.talks показывать новое сообщение, а запись о старом c тем же кодом в lor-opennet.17 по хорошему наверное надо бы удалить, заслав куда-то системный алерт о коллизии с подробным описанием того что куда добавилось и что откуда удалилось - вобщем как-то так...

AL> Дождались коллизий, похоже. Возможно, придётся менять хеш-функцию как-то. Но это потом. За 10+ лет это первый случай, вроде. Так что маловероятно, что он повторится в ближайшее время.

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

Ох, нифига-себе!

Предлагаю этот раздвоенный msgid включить всем в blacklist.txt т.к. он вызывает проблемы на разных нодах:

v2gj6Qx0JJmoNlcjcJlg

P.S. Также обнаружил у себя в списках несколько старых сообщений у которых длина хеша была 19 символов вместо 20 - все удалил т.к. один из узлов продолжал их у меня спрашивать (вместе с вышеупомянутым раздвоенным)...

shaos> Предлагаю этот раздвоенный msgid включить всем в blacklist.txt т.к. он вызывает проблемы на разных нодах:
shaos> v2gj6Qx0JJmoNlcjcJlg

Можно, конечно.

shaos> P.S. Также обнаружил у себя в списках несколько старых сообщений у которых длина хеша была 19 символов вместо 20 - все удалил т.к. один из узлов продолжал их у меня спрашивать (вместе с вышеупомянутым раздвоенным)...

И это неправильно. Длина хеша может быть потенциально любой.

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

Список коротких хэшей:

3rkSne5R2FI1QXrlJkF
bi36U9W4Zu86wagsE8X
Hi7AzJtfBZKKb96awMP
SZ7KQTwMhch9gSIJ1Q3
APcbWI1obBZ3nr5uZgt
8BqXV3KGYEqIwnPaKsB
MmBCteS6yMnC2LZLbRC
JDKVlOwszVbKpMvjwN8

> И это неправильно. Длина хеша может быть потенциально любой.

Ну тогда тебе надо поглядеть в свой код т.к. именно твой узел продолжал у меня их спрашивать каждые 10 минут :)

62.109.31.95 - - [29/Sep/2024:23:30:08 -0700] "GET /ii-point.php?q=/u/m/3rkSne5R2FI1QXrlJkF/bi36U9W4Zu86wagsE8X/Hi7AzJtfBZKKb96awMP/v2gj6Qx0JJmoNlcjcJlg/SZ7KQTwMhch9gSIJ1Q3/APcbWI1obBZ3nr5uZgt/8BqXV3KGYEqIwnPaKsB/MmBCteS6yMnC2LZLbRC/JDKVlOwszVbKpMvjwN8 HTTP/1.1" 200 10517 "-" "Python-urllib/3.11"
62.109.31.95 - - [29/Sep/2024:23:40:09 -0700] "GET /ii-point.php?q=/u/m/3rkSne5R2FI1QXrlJkF/bi36U9W4Zu86wagsE8X/Hi7AzJtfBZKKb96awMP/v2gj6Qx0JJmoNlcjcJlg/SZ7KQTwMhch9gSIJ1Q3/APcbWI1obBZ3nr5uZgt/8BqXV3KGYEqIwnPaKsB/MmBCteS6yMnC2LZLbRC/JDKVlOwszVbKpMvjwN8 HTTP/1.1" 200 10517 "-" "Python-urllib/3.11"
62.109.31.95 - - [29/Sep/2024:23:50:08 -0700] "GET /ii-point.php?q=/u/m/3rkSne5R2FI1QXrlJkF/bi36U9W4Zu86wagsE8X/Hi7AzJtfBZKKb96awMP/v2gj6Qx0JJmoNlcjcJlg/SZ7KQTwMhch9gSIJ1Q3/APcbWI1obBZ3nr5uZgt/8BqXV3KGYEqIwnPaKsB/MmBCteS6yMnC2LZLbRC/JDKVlOwszVbKpMvjwN8 HTTP/1.1" 200 10517 "-" "Python-urllib/3.11"

и ii-php честно их каждый раз отдавал...

Ну вот же :)

def debundle(bundle):
    for msg in bundle:
        if msg:
            m = msg.split(":")
            msgid = m[0]
            if len(msgid) == 20 and m[1]:
                msg = base64.b64decode(m[1].encode("ascii")).decode("utf8").split("\n")
                c.execute("INSERT INTO msg (msgid, tags, echoarea, time, fr, addr, t, subject, body) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?);", (msgid, msg[0], msg[1], msg[2], msg[3], msg[4], msg[5], msg[6], "\n".join(msg[8:])))
    con.commit()

в iing стоит проверка на равенство длины числу 20 :)

shaos> Предлагаю этот раздвоенный msgid включить всем в blacklist.txt т.к. он вызывает проблемы на разных нодах:
shaos> v2gj6Qx0JJmoNlcjcJlg

Гм, у меня нет такого сообщения в базах... Наверное я не фетчу эти эхи.

shaos> Ну вот же :)

shaos> ====
shaos> if len(msgid) == 20 and m[1]:
shaos> ====

shaos> в iing стоит проверка на равенство длины числу 20 :)

У меня тоже судя по коду стоит проверка на 20. Это точно не в стандарте?

Наверное если только одна эха есть из этих двух то ок:

idec.talks:v2gj6Qx0JJmoNlcjcJlg
lor-opennet.17:v2gj6Qx0JJmoNlcjcJlg

shaos> Наверное если только одна эха есть из этих двух то ок:

shaos> idec.talks:v2gj6Qx0JJmoNlcjcJlg

idec.talks у меня есть, но сообщения этого нет. Это странно. Может всё-таки у кого-то сбойнуло что-то? Проверяли по коду - хеш действительно совпадает если его перерассчитать?

Я не вижу нового сообщения - ii-php показывает в idec.talks старую новость из lor-opennet, а таверна глючит в lor-opennet застряв на том сообщении, но перезапомнив дату как будто оно самое новое и при попытке перемотать ленту до конца оно снова перескакивает на него

shaos> Я не вижу нового сообщения - ii-php показывает в idec.talks старую новость из lor-opennet, а таверна глючит в lor-opennet застряв на том сообщении, но перезапомнив дату как будто оно самое новое и при попытке перемотать ленту до конца оно снова перескакивает на него

Откуда вообще столько шума из-за мёртвой эхи? Актуальная это ii://lor.opennet же.

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

Ну архив тоже типа эха - или когда создали новую, то старую удалили и забыли? ;)
Я вот поиск хочу нагородить по всем эхам, что у меня есть - включая архивные :)

shaos> Ну архив тоже типа эха - или когда создали новую, то старую удалили и забыли? ;)

Я просто не могу себе представить пользу от архива новостей ЛОРа и опеннета. Оно полезно в моменте.

shaos> Я вот поиск хочу нагородить по всем эхам, что у меня есть - включая архивные :)

Бывает :)

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

> Я просто не могу себе представить пользу от архива новостей ЛОРа и опеннета. Оно полезно в моменте.

Ну вот сидит человек скажем за Спринтером или за ZX-спектрумом и через сетевушку читает ii/IDEC эхи - захотел окнутуся так сказать в историю ну или поиск организовал по ключевому слову - скажем Knoppix и смотрит чего там когда оно упоминалось - круто же? ;)

> У меня тоже судя по коду стоит проверка на 20. Это точно не в стандарте?

интересно, что как минимум 7 из проблемных 8 сообщений (у которых длина хэша 19 вместо 20) были созданы с помощью idec.el/0.1 пользователем Difrex (dynamic,1):

+++ idec.el/0.1
+++ idec.el/0.1
+++ At work. idec.el/0.1
+++ idec.el/0.1
+++ idec.el/0.1
+++ idec.el/0.1
+++ Картошки хватит на всех

и хэши там совсем неправильно посчитаны были т.к. реальные хеши ничего общего с названиями этих сообщений не имеют:

SZ7KQTwMhch9gSIJ1Q3
--> vY11CNkWXWstRfHyD8EQ
APcbWI1obBZ3nr5uZgt
--> BDZIZkGNsacszWnRTEDA
8BqXV3KGYEqIwnPaKsB
--> 9Fz0f71LTxinLyAA26jc
MmBCteS6yMnC2LZLbRC
--> aDDfVncYTkdhSITwY2VB
JDKVlOwszVbKpMvjwN8
--> aagoTsW9vjv61Hsb0UBO
3rkSne5R2FI1QXrlJkF
--> R7mIPIRysuoKAchosrZX
bi36U9W4Zu86wagsE8X
--> H3E9knwnOOTSwBmwaLF7
Hi7AzJtfBZKKb96awMP
--> GPIigM4r30CcSK8tjRzd

По идее можно вернуть эти сообщения в оборот просто добавив 0 в конце ихних хэшей и поправив несколько других сообщений, которые на них ссылаются:

vHtkzHXiAYL0a7zSFS0P:> Так и не понял чем тебе мой вариант не подошёл, который я тут показывал ii://APcbWI1obBZ3nr5uZgt :)
vu94FtaImMH7E9AlDg8d:Так и не понял чем тебе мой вариант не подошёл, который я тут показывал ii://APcbWI1obBZ3nr5uZgt :)
TKcKYfkzLXg3YU3iMQrS:ii/ok/repto/8BqXV3KGYEqIwnPaKsB
sBF0YZDFAAJY9ZXGeTvw:Вот https://dynamic.lessmore.pw/msg/MmBCteS6yMnC2LZLbRC
nXdcHnk0Y4UunGNNUIwi:ii/ok/repto/3rkSne5R2FI1QXrlJkF
z8W283Fkra8J96OrKQCC:ii/ok/repto/bi36U9W4Zu86wagsE8X

>> У меня тоже судя по коду стоит проверка на 20. Это точно не в стандарте?
shaos> интересно, что как минимум 7 из проблемных 8 сообщений (у которых длина хэша 19 вместо 20) были созданы с помощью idec.el/0.1 пользователем Difrex (dynamic,1):

Проблема была не в idec.el, а в dynamic. Хеши считает нода, а не клиент.

shaos> и хэши там совсем неправильно посчитаны были т.к. реальные хеши ничего общего с названиями этих сообщений не имеют:

Реальные хеши это придуманное что-то. Они могут быть какие угодно, лишь бы не было коллизий.

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

> Реальные хеши это придуманное что-то. Они могут быть какие угодно, лишь бы не было коллизий.

Ну ваш "стандарт" описывает вполне конкретно как msgid должен формироваться :)

Разве что чётко не прописано, что заменять надо на A (большую) и z (маленькую) ;)

Это невозможно практически. Хеши точно по сообщениям одинаковые? Я больше склоняюсь к глюку софта, генерирующего хэш. На таком малом количестве сообщений это невозможно.

Я раз в несколько месяцев/лет перечитываю архив новостей и их комментов с лора 90-х / 00-х. Круто, что там это можно удобно делать.

Так то теоретически возможно, но вероятность сего должна быть пренебрежима мала (но тем не менее она не нулевая)

> Так то теоретически возможно, но вероятность сего должна быть пренебрежима мала (но тем не менее она не нулевая)

Блин, клиент сожрал моё сообщение и не подавился :(

Там даже первые 6 цифр на 87 сообщений никогда не совпадали. У меня были шортлинки на 6 первых символов.

+++ написано в ii-txt-0.9 (ii://K3FDA6fNzoeWmcA3p41x)

> Там даже первые 6 цифр на 87 сообщений никогда не совпадали. У меня были шортлинки на 6 первых символов.

на 87 тыщ сообщений (о, в таглайне линки не рендерятся, а так?)


+ написано в ii-txt-0.9 (ii://K3FDA6fNzoeWmcA3p41x)

>> Реальные хеши это придуманное что-то. Они могут быть какие угодно, лишь бы не было коллизий.
shaos> Ну ваш "стандарт" описывает вполне конкретно как msgid должен формироваться :)

Наш стандарт весь просто условность и немного договорённостей.

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

>> Там даже первые 6 цифр на 87 сообщений никогда не совпадали. У меня были шортлинки на 6 первых символов.
iiii> на 87 тыщ сообщений (о, в таглайне линки не рендерятся, а так?)

Так и не должны по идее, но это дело несложное.

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

Значится так - первое упоминание этого msgid (v2gj6Qx0JJmoNlcjcJlg) у меня в логах появилось Sun Dec 19 12:16:49 PST 2021 когда я впервые стянул некоторые эхи с таверны на свою ноду (на тот момент это был неизменённый ii-php):

lor-opennet.17
fetch http://idec.spline-online.ml/u/m/UTCMFH1UP4bIqmAsfKpI/W5MAAlryHwKN8JULaVRp/XcXgSAAM5Lmvh2xOCEvq/z7iYfI4atYDtGthgTCFA/z9D05BUbcAzIQflFYnzG/z9Yff5M5XNJGXAbMlikb/VV5LZpf7U9HbZqD7EloC/FREYgvbDp8JUs0mDfQPj/UcXyqV4Wr9MwC7N6UbzC/v2gj6Qx0JJmoNlcjcJlg/9zrVs589o3goy25DHkxY/DeKrvjOA4Enw1iA8Gn0q/eTdc6GplkNMTuJSJk6HS/NNrA0wTBk38XVYZzh2Sh/TFJuhrx2vnh526yhRWxP/xcUP2HgvHuWS7CZb3yl5/034KH4ajtBdWpI8GPaf4/HasPCfoV1NQLfDLUeAdy/wGz7KQv3AwrZMSR4i5pk/XczrIJymRAM0BHA5l6B9

Тогда всё было ок - уникальный msgid обозначала некое старое сообщение в эхе lor-opennet.17

Второй раз этот хэш у меня в логах проскочил в январе этого года:

Sun Jan 7 17:27:01 PST 2024
fetch http://idec.spline-online.ru/u/e/idec.talks/idec.test/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum/silicon.valley.local
idec.talks
fetch http://idec.spline-online.ru/u/m/v2gj6Qx0JJmoNlcjcJlg
message saved: ok
lor-opennet.17
fetch http://idec.spline-online.ru/u/m/e3FfHqImRAIj20s4qnzO
invalid message: e3FfHqImRAIj20s4qnzO
error saving e3FfHqImRAIj20s4qnzO

Тут уже этот хэш как бы пришёл из idec.talks (с таверны) и следом за ним пришло какое-то невалидное сообщение для lor-opennet.17 (интересно, что с таким кодом сообщения нет нигде) - могло ли что-то сломаться в тот момент в таверне? Возможно...

Кстати в таверне чото точно сглючило - если кликнуть во второй фетч линк, то там будет вот такое:

...
pOlv1zvAI8G0xaf2fQmt
xIy7luAQzK1ClWMjlAGx
B1mM6Q6NWQ5MuY96FeL3
koYbiZY3ibMe3N87eqTD
D5EpnqqclAcoLamAaUHd
vduRDOaNtRCrndkMs5S4
pxNaNgXcsZJvD8t2fLQX
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
v2gj6Qx0JJmoNlcjcJlg
...

т.е. это проблемное сообщение начинает размножаться...

> Так и не должны по идее, но это дело несложное.

Я конкретно про hugeping.tk. Фиг с ним.


+ написано в ii-txt-0.9 (ii://K3FDA6fNzoeWmcA3p41x)

Так кто-нибудь скажет, какой алгоритм использовать для хеширования? :)
У меня сейчас что-то такое. Где наш "стандарт" вообще почитать сейчас?

func MsgId(msg string) string {
        h := sha256.Sum256([]byte(msg))
        id := base64.StdEncoding.EncodeToString(h[:])
        id = strings.Replace(id, "+", "A", -1)
        id = strings.Replace(id, "/", "Z", -1)
        return id[0:20]
}

у меня точно ничё не было

а где вообще можно что-то почитать сейчас? список ббс-ок, спецификации?

Если исправить Z на z, то будет как в оригинальном ii

Вроде все доки тут:

https://github.com/idec-net/new-docs

Я вот тут описывал свои изыскания: ii://oZon0mICyntTZHaFJO0o

A и Z:
- ii-go
- lessmore
- tgi

A и z:
- оригинальный ii (судя по архивным мессагам)
- ii-php
- iing

shaos> Вроде все доки тут:
shaos> https://github.com/idec-net/new-docs

Спасибо. Цитата:
> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.

Собственно, поэтому я так и сделал! Видимо, "стандарт" писался не очень аккуратно! Давайте зафиксируем всё-таки. Z или z? :)

shaos>> Вроде все доки тут:
shaos>> https://github.com/idec-net/new-docs
hugeping> Спасибо. Цитата:
>> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.
hugeping> Собственно, поэтому я так и сделал! Видимо, "стандарт" писался не очень аккуратно! Давайте зафиксируем всё-таки. Z или z? :)

Но есть ли в этом смысл, если с некоторых станций идут сообщения, у которых msgid совсем не соответствует содержимому? :)

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

> Видимо, "стандарт" писался не очень аккуратно! Давайте зафиксируем всё-таки. Z или z? :)

В английском варианте протокола написано более обтекаемо:

> msgID is a unique 20-symbol piece of base64-encoded sha256 hash. Special base64 symbols like + and / must be replaced by readable letters (like A and Z for example).

https://github.com/idec-net/new-docs/blob/master/protocol-en.md

Был сайт, да помер:

https://ii-net.tk/idec-doc/?p=main

(вебархив тоже похоже помер после недавнего хака)

Я ещё в декабре 2021 года предлагал доку поправить на A и z :)

ii://02tzzmoYvnkIfFNR8KNL

shaos> Был сайт, да помер:
shaos> https://ii-net.tk/idec-doc/?p=main
shaos> (вебархив тоже похоже помер после недавнего хака)

На Github Pages поднимите раз там стандарт держите
Будет url типа https://idec-net.github.io или https://idec-net.githuh.io/new-docs

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

Это к Andrew Lobanov

А так там доке в маркдауне ведь - для веба их преобразовывать надо

Маркдаун проще прям на гитхабе и смотреть...

tuple> Кстати, про этот самый стандарт. Он выглядит сейчас не слишком презентабельно. Даже README нет в репозитории, описания концепций раскиданы по разным файлам без особой системности - выглядит как черновик.
tuple> Может форкнуть его и сделать красивым статическим сайтом на каком-нибудь hugo/jekyll?

Может, хотя бы Markdown, а не сайт? Потом уж и MD во что угодно гнать не проблема.

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

shaos> Это к Andrew Lobanov

Чего это?

shaos> А так там доке в маркдауне ведь - для веба их преобразовывать надо

Вызвать pandoc недолго.

shaos> Маркдаун проще прям на гитхабе и смотреть...

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

shaos> Это к Andrew Lobanov
shaos> А так там доке в маркдауне ведь - для веба их преобразовывать надо
shaos> Маркдаун проще прям на гитхабе и смотреть...

Не проблема. В том же GitHub Pages из коробки есть Jekyll

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

Вот-вот, я не писал, что нужно markdown переписывать в html. Jekyll автоматом это всё конвертирует в html-страницы. Исходники лежат в репозитории в виде markdown, а сборка уже улетает на Github Pages.

AL> Но есть ли в этом смысл, если с некоторых станций идут сообщения, у которых msgid совсем не соответствует содержимому? :)

В данном вопросе я рассуждаю просто. Меня интересует мой код. :) Что творят другие -- не моя зона ответственности. Если будут коллизии, я не забираю просто сообщение.