В создании хэшей царит полная анархия я смотрю:

спек говорит заменять + и / на что-нибудь например 'A' и 'Z' (like A and Z for example)

ii-php заменяет на 'A' и 'z' (большинство старых сообщений сгенерировано так)

ii-go заменяет на 'A' и 'Z'

а вот iing имеет вот такой код

6d083914 (Andrew Lobanov 2017-06-05 11:21:48 +0500 52) def hsh(str):
438e377e (Andrew Lobanov 2017-06-05 12:35:50 +0500 53)     out = base64.urlsafe_b64encode(hashlib.sha256(str).digest()).decode("utf-8")
438e377e (Andrew Lobanov 2017-06-05 12:35:50 +0500 54)     return out.replace('-', '').replace('_', '')[:8].ljust(8,'A')

я не сильно флюент в пайтоне, но вроде это значит выкинуть - (используется вместо + в base64url) затем выкинуть _ (используется вместо / в base64url) потом взять 8 символов от начала и в конце сделать ljust(8,'A') который при данном раскладе не делает ничего?...

А понял - если вдруг получится, что в хэше была много _ и - (маловероятно, но возможно), то оно оставит огрызок короче 8 символо и их надо будет добить символами 'A', но почему 8? должно быть 20, не?

G7chqM52TiAQQAn4Yh7R

А не - то было для паролей поинтов, вот правильный код из iing для хэша мессаг:

^9e32587 (Andrew Lobanov 2017-04-10 17:31:49 +0500 184) def hsh(msg):
^9e32587 (Andrew Lobanov 2017-04-10 17:31:49 +0500 185)     ret = base64.urlsafe_b64encode(hashlib.sha256(msg.encode()).digest()).decode("utf-8").replace("-", "A").replace("_", "z")[:20]
^9e32587 (Andrew Lobanov 2017-04-10 17:31:49 +0500 186)     return ret

т.е. тоже 'A' и 'z' - получается надо бы спеку поправить? ;)

Lessmore тоже как и ii-go делал A и Z:

// b64replace +,/,-,_ with A and Z
func b64replace(s string) string {
	s = strings.Replace(s, "+", "A", -1)
	s = strings.Replace(s, "-", "A", -1)
	s = strings.Replace(s, "/", "Z", -1)
	s = strings.Replace(s, "_", "Z", -1)
	return s
}

Надо ещё поглядеть на что подменяет tgi…

shaos> Lessmore тоже как и ii-go делал A и Z:
shaos> ====
shaos> // b64replace +,/,-,_ with A and Z
shaos> func b64replace(s string) string {
shaos> s = strings.Replace(s, "+", "A", -1)
shaos> s = strings.Replace(s, "-", "A", -1)
shaos> s = strings.Replace(s, "/", "Z", -1)
shaos> s = strings.Replace(s, "_", "Z", -1)
shaos> return s
shaos> }
shaos> ====
shaos> Надо ещё поглядеть на что подменяет tgi…

Кстати, а куда делся Ordos и где код tgi?

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

shaos> я не сильно флюент в пайтоне, но вроде это значит выкинуть - (используется вместо + в base64url) затем выкинуть _ (используется вместо / в base64url) потом взять 8 символов от начала и в конце сделать ljust(8,'A') который при данном раскладе не делает ничего?...

Это какая-то дичь. Переписывать я её, конечно же, не буду :)

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

shaos> т.е. тоже 'A' и 'z' - получается надо бы спеку поправить? ;)

Смысла нет особого, так как это ни на что не влияет :)

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

shaos>> я не сильно флюент в пайтоне, но вроде это значит выкинуть - (используется вместо + в base64url) затем выкинуть _ (используется вместо / в base64url) потом взять 8 символов от начала и в конце сделать ljust(8,'A') который при данном раскладе не делает ничего?...
AL> Это какая-то дичь. Переписывать я её, конечно же, не буду :)

Переписывать всеравно надо. Кстати ты таверну на Python 2 держишь? Или просто рабочий код не на гх?

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

shaos>>> я не сильно флюент в пайтоне, но вроде это значит выкинуть - (используется вместо + в base64url) затем выкинуть _ (используется вместо / в base64url) потом взять 8 символов от начала и в конце сделать ljust(8,'A') который при данном раскладе не делает ничего?...
AL>> Это какая-то дичь. Переписывать я её, конечно же, не буду :)
doesnm> Переписывать всеравно надо. Кстати ты таверну на Python 2 держишь? Или просто рабочий код не на гх?

Ну кому надо, те перепишут. Таверна на третьем питоне. Рабочий код фиг знает где.

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

shaos>>>> я не сильно флюент в пайтоне, но вроде это значит выкинуть - (используется вместо + в base64url) затем выкинуть _ (используется вместо / в base64url) потом взять 8 символов от начала и в конце сделать ljust(8,'A') который при данном раскладе не делает ничего?...
AL>>> Это какая-то дичь. Переписывать я её, конечно же, не буду :)
doesnm>> Переписывать всеравно надо. Кстати ты таверну на Python 2 держишь? Или просто рабочий код не на гх?
AL> Ну кому надо, те перепишут. Таверна на третьем питоне. Рабочий код фиг знает где.

Iing я не успел пощупать так что заинтересован только в tgi и ii-go (iing увидел мельком и что-то UI не особо заходит)
Ну и мб iissh если его нормально переписать

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

Ну будет 100% совместимая между всеми проверка целостности данных :)

А так то конечно можно оба варианта поддержать при проверке целостности - типа проверяю c Az, если не сошлось, то уменьшаю msgid и подсчитанный хэш до маленьких буков и сравниваю опять - если сошлось, то сообщение было неподменянное, а если нет - то рисую напротив такого сообщения красный треугольный знак с ! внутри - вобщем как-то так :)

P.S. Я знаю, что некоторые ноды позволяют редактировать сообщения без изменения их msgid - у меня такие сообщения будут маркироваться как подменянные...

а оно ещё и падает каждые N дней :)

или код таверны уже далеко убежал от опубликованного iing?

> то уменьшаю msgid и подсчитанный хэш до маленьких буков и сравниваю опять - если сошлось, то сообщение было неподменянное

точнее так - "с определённой степенью уверенности можно сказать, что сообщение было неподменянное"
т.е. такой случай тоже надо маркировать - например жёлтым значком, т.е.
- зелёный значок - хэш сошёлся сразу;
- жёлтый значок - хзш сошёлся только после приведение к маленьким буквам;
- красный значок - хэш совсем никак не сходится.

> ing я не успел пощупать так что заинтересован только в tgi и ii-go...

можешь ещё пощупать ii-php (или мой вариант iii-php, который пока недалеко ушёл от оригинала)

А мне кстати понравилось (после того как понял как оно работает) - вот так если бы сделали подсчёт хэшей для ii изначально, то было бы более сбалансированно нежели просто заменять 2 кода из 64х на уже использованные ранее (A и Z):

base64.urlsafe_b64encode(hashlib.sha256(msg).digest()).decode("utf-8").replace('-', '').replace('_', '')[:20].ljust(20,'A')

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

0 734
1 689
2 710
3 695
4 757
5 792
6 704
7 709
8 706
9 714
a 749
b 744
c 693
d 790
e 753
f 735
g 745
h 744
i 732
j 718
k 706
l 717
m 797
n 740
o 706
p 747
q 766
r 673
s 764
t 718
u 746
v 733
w 676
x 746
y 717
z 1354
A 1392
B 726
C 713
D 729
E 789
F 707
G 708
H 712
I 711
J 726
K 772
L 709
M 804
N 759
O 730
P 701
Q 721
R 677
S 659
T 746
U 734
V 709
W 734
X 680
Y 761
Z 753

т.е. z и A сильно выбиваются вперёд...

>> ing я не успел пощупать так что заинтересован только в tgi и ii-go...
shaos> можешь ещё пощупать ii-php (или мой вариант iii-php, который пока недалеко ушёл от оригинала)

А, и еще ii-php, да
Его я щупал первым на тестовой ноде (которой больше нет ибо кое где сломали php)

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

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

Встаром ii архиве (46481 штук):

81.6% названий соответствуют хэшам
18.4% не соответствуют

В новых ii/IDEC мессагах (20760 штук):

28.0% названий соответствует хэшам
0.4% соответствуют после приведения к нижнему регистру (значит была подмена на Z вместо z)
71.6% не соответствует

Совместил вместа архивы старых и новых мессаг (получилось более 67 тысяч сообщений) и прогнал новый возможный алгоритм хеширования с отбрасыванием 2 нецифробуквенных символов вместо замены (и с добиванием хвоста нулями, если вдруг надо будет):

base64.urlsafe_b64encode(hashlib.sha256(msg).digest()).decode("utf-8").replace('-', '').replace('_', '')[:20].ljust(20,'0')

В итоге распределение букв в сформированном таким образом msgid стало плюс-минус равномерным:

0 1072
1 1110
2 1064
3 1026
4 1117
5 1139
6 1049
7 1084
8 1055
9 1075
a 1108
b 1081
c 1093
d 1108
e 1089
f 1052
g 1104
h 1111
i 1076
j 1124
k 1094
l 1090
m 1151
n 1083
o 1047
p 1116
q 1132
r 1029
s 1117
t 1090
u 1073
v 1061
w 1061
x 1129
y 1096
z 1103
A 1002
B 1024
C 1016
D 1089
E 1144
F 1061
G 1045
H 1081
I 1090
J 1107
K 1113
L 1065
M 1122
N 1141
O 1050
P 1019
Q 1125
R 1063
S 1031
T 1115
U 1122
V 1076
W 1121
X 1020
Y 1113
Z 1077

Коллизий не обнаружилось (зато нашлись несколько одинаковых сообщений у которых были разные msgid) и по итогу около трети сообщений сохранили свой старый msgid (т.е. там небыло этих двух символов на замену, которые в этом алгоритме просто отбрасываются)

Это я думаю а не поменять ли алгоритм хеширования на своей ноде, раз уж и так кто как делает...

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

Мне пока непонятно почему в 70% новых сообщений не сходится хэш - возможно новые генерилки RSS-новостей идут «мимо» стандартного пути посылки мессаг через апи поинта…

shaos> Мне пока непонятно почему в 70% новых сообщений не сходится хэш - возможно новые генерилки RSS-новостей идут «мимо» стандартного пути посылки мессаг через апи поинта…

Насколько это плохо? И точно ли там новый код?

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

> Насколько это плохо?

Ну пока хэши уникальны и коллизий нет, то наверное норм

> И точно ли там новый код?

Надо смотреть…

shaos> Мне пока непонятно почему в 70% новых сообщений не сходится хэш - возможно новые генерилки RSS-новостей идут «мимо» стандартного пути посылки мессаг через апи поинта…

А у кого новые гейты из RSS стоят? Я думал, я один такой, но у меня этот гейт мхом уже порос.

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

Ну как же - у меня bot.slashdot уже третью неделю бегает :)
Правда он стандартный из ii-php - там вроде всё как надо (я проверил)
Проверил также lor.opennet и bot.habr.rss (вроде как относительно новый бот) - там вроде тоже всё ок
Расширил свою питоновскую проверялку чтобы печатала первые строчки мессаги в ряд (чтобы грепать можно было с результатом сверки хеша):

#!/usr/bin/python3
import base64,hashlib,sys;
for s in sys.argv:
    if '.py' in s:
        continue
    filename = s
    f = open(filename, "rb")
    msg = f.read()
    hash = base64.urlsafe_b64encode(hashlib.sha256(msg).digest()).decode("utf-8").replace('-', 'A').replace('_', 'z')[:20]
    res = 'BAD'
    if filename==hash :
        res = 'GOOD'
    elif filename.casefold()==hash.casefold():
        res = 'KINDA'
    print(filename,"-->",hash,res,msg.decode("utf-8")[:80].replace('\n','|'));

(запускать в директории msg с аргументом *)

И что же мы теперь видим? Все оригинальные (от бота) сообщения в lor-opennet.17 (14225 штук) имеют несовпадающий хэш - это 2/3 от всех "новых" сообщений!

00b33VZpAzycmjYgAYE2 --> 6cH9LED7U3mmWYkmqjGe BAD ii/ok|lor-opennet.17|1626642001|Новостной_робот|mira, 1|All|Релиз систем сборки 
00gY2d9Z3RhS7Ce7AJ7y --> phhYJRbKiehrg9sSfaU1 BAD ii/ok|lor-opennet.17|1542643204|Новостной_робот|mira, 1|All|Выпуск видеоредактор
00n38C6X6Hj7wVLDGXl2 --> VQMe0BdXWP2ghg3rBDjJ BAD ii/ok|lor-opennet.17|1603209602|Новостной_робот|mira, 1|All|Kaitai Struct 0.9|| 
...

Для примера вот как показываются сообщения из моей эхи bot.slashdot (которая по идее должна на том же движке работать?):

00mqjZAp22bXQxsTUMnl --> 00mqjZAp22bXQxsTUMnl GOOD ii/ok|bot.slashdot|1727583781|robot|shaos, 1|All|Can AI Developers Be Held Liabl
039DRyKs6KYiZFnBrIXW --> 039DRyKs6KYiZFnBrIXW GOOD ii/ok|bot.slashdot|1727389381|Новостной_робот|shaos, 1|All|US Justice Department
0oaUYvbZZCQvqBYV6Gjf --> 0oaUYvbZZCQvqBYV6Gjf GOOD ii/ok|bot.slashdot|1727472181|robot|shaos, 1|All|If 23andMe Is Up for Sale, So I
...

(я впоследствии заменил Новостной_робот на посто robot, но старые сообщения трогать не стал)

Поглядел в старые ботоэхи:

lor-opennet.2014 - почти все сообщения GOOD
lor-opennet.15 - порядка 60% GOOD и 40% BAD (после 1456319240 включительно)
habra.14 и habra.15 от difrex - все GOOD

P.S. Момент времени 1456319240 это "Wed Feb 24 2016 13:07:20 GMT+0000" начиная с которого в lor-opennet.* всё стало плохо...