У меня вообще в ноде на парсере нет регулярных выражений :)

Кстати я ошибся мой код ломает

Вечером напишу

ahamai> Складывается впечатление, что idec это пример плохого проектирования.

На это я пытался намекнуть чуть ли не с первого дня появления здесь.

ahamai> MSGID? по логике вроде бы да.

Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.

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

Я ещё могу понять, почему всё через / — это проще парсить, чем отдельно компоненты пути и компоненты HTTP query, особенно учитывая, что от HTTP в общем случае можно (и нужно) отходить. Но я не могу понять, почему бы не сделать в запросе такую же железобетонную структуру ключ-значение, как и в тегах бандла ii/ok/repto/blabla:

/u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10

Этот формат (после удаления первого слэша) однозначно парсится в ключ-значение, на тикле он вообще одним сплитом преобразуется в список, читающийся через dict. И тогда и дополнительных проверок на то, где название эхи, а где диапазон, делать не нужно. Первый ключ — u со значением e, второй ключ — echo.1 со значением all и так далее. А сейчас всё как-то дико контекстозависимо получается, потенциал допустить ошибку куда выше.

Я про это тоже собирался вечером написать. Это было в bosfor

revoltech> /u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10

И да, в моём варианте вместо диапазона легко подставить msgid, и так же легко на стороне сервера проверить, что именно там стоит. Если диапазон, берём диапазон, если msgid, берём от этого msgid.

Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):

/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10

А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.

AL> И это ломает поддержку стандарта.

Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?

revoltech> А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.

Сейчас у меня в фетчере это значение по умолчанию равно 12, пока явно не указано обратное. Было бы неплохо, если бы станция сообщала эту информацию клиенту для оптимального выкачивания мессаг.

ahamai> Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе.

Какие-то количества сообщений придумал. Нет их уже, считай. Легаси, который в скором времени выставим на мороз.

> Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)

Как количество сообщений влияет на работу срезов? Out of range невозможен.

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

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

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

ahamai> Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.
ahamai> Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи.

Читай документацию внимательнее. Там не только эхи перечисляются.

ahamai> Почему не использовать что-то типа ?s=-100:100 или любой другой способ?

Мы и используем один из любых других способов.

ahamai> Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения.

Почему у тебя фетчер считает имя эхи хэшем сообщения? Это явно что-то не так в ii 0.3. Зачем с аплинком на ii использовать то, что ii не умеет?

ahamai> Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

Никакой неоднозначности нет. Не может быть двоеточия в имени эхи. Если софт такое допускает, значит софт надо исправлять.

ahamai> Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез.

Зачем?

ahamai> Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных?

1. Ты тоже в максималисты подался? Затем, что лишних несколько сотен байт на фоне нескольких сотен килобайт это экономия трафика.

2. Ненужные сообщения не тянутся. Только новые. u/e, если ты забыл, даёт только индекс, но не сообщения.

ahamai> А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться

И этот человек защищал кучу маленьких бандлов вместо всего в одном запросе.

ahamai> Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно.

Однопоточный фетчер на срезах на перле, который тянет индекс по одной эхе и использует бандлы по 40 сообщений, утягивает клуб за 3 минуты. На медленном канале.

Он же, но с парой десятков сообщений новых сообщений работает 3-5 секунд.

Без новых сообщений он отрабатывает за 3-4 секунды.

ВНИМАНИЕ! Вопрос: куда ты так спешишь, что у тебя каждая секунда на счету?

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

>> Можно передавать уровни сокобана в plaintext-формате (.sok).
ahamai> это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость

Многие НРИ годятся для такого занятия. Всей гурьбой, увлекательно, разнообразно.

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

ahamai> - если сообщений в базе мало
ahamai> + если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
ahamai> 111
ahamai> Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

Оверхед меньше килобайта в подавляющем большинстве случаев. Это даже на 9600 бод можно не считать оверхедом. При этом ты предлагаешь более сложный и неработающий в части случаев вариант.

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

tuple> Ещё есть вариант найти мастера, сыграть в D&D.

В общем случае неудобно. Карту надо и токены.

tuple> P.S. Чур я бард-человек.

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

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

За сим считаю, что обсуждение стандарта с тобой можно завершать. Какие счётчики? Какое скачивание лишних сообщений? Если ты не читал то, что я сюда приносил как черновик, то открой хотя бы исходники своего ii-0.3. Почитай на досуге. Сразу увидишь где ты неправ в своих претензиях. Ну а если не увидишь, то обсуждать с тобой дизайн, стандарт и реализацию тем более нет смысла.

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

ahamai> смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?

У нас нет бона.

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

shaos> Не надо драматизировать :)
shaos> Индексы тоже пару строк кода добавляют (ну может чуть больше)
shaos> Для разнообразия можно множественные "слайсы" тоже сделать, типа
shaos> /u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4
shaos> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

И это ломает поддержку стандарта.

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

ahamai> кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?

Из стандарта выкидывается то, что по факту никому не нужно. Стандарты полностью совместимы с ii. Так что не понимаю твоего бухчения. Ты можешь взять хоть свой горячо любимый ii-0.3 и работать в сети полноценно.

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

>> кто будет переписывать цезий или фетчеры под замену стандартов?
shaos> никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!

Ну просто всё несовместимое снимается с фетча. Зачем нам поломанные узлы?

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

shaos> Блин как эти ==== в этом ii-php работают?

Это знает только автор. И то вряд ли вспомнит.

shaos> Ненавижу регулярные выражения...

Что может быть проще? Грамматики? Конечные автоматы?

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

ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)

Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её

shaos> чем плохо то? ;)

Это не ко мне вопрос.

> Это знает только автор. И то вряд ли вспомнит.

Да там всё в коде - читай нехочу, но только без поллитры в этих регекспах не разрбраться (мне):

        for ($i = 0; $i < count ($string); ++$i) {
                $string[$i] = preg_replace("/([^\w\/])(www\.[a-z0-9\-]+\.[a-z0-9\-]+)/i", "$1http://$2",$string[$i]);
                $string[$i] = preg_replace("/([\w]+:\/\/[\w\-?&;%#~=\.\/\@]+[\w\/])/i","<a target=\"_blank\" href=\"$1\">$1</a>",$string[$i]);
                $string[$i] = preg_replace("/([\w\-?&;#~=\.\/]+\@(\[?)[a-zA-Z0-9\-\.]+\.([a-zA-Z]{2,3}|[0-9]{1,3})(\]?))/i","<a href=\"mailto:$1\">$1</a>",$string[$i]);
                $echo_check = preg_replace("/(.*)\<a target=\"_blank\" href=\"ii:\/\/(.+?)\"\>(.+?)\<\/a\>(.*)/", "$2", $string[$i]);
                if ($access->checkEcho($echo_check)) {
                        $string[$i] = preg_replace("/target=\"_blank\" href=\"ii:\/\/(.+?)\"/s", "class=\"iilink\" href=\"?echo=$1\"", $string[$i]);
                } else {
                        $string[$i] = preg_replace("/target=\"_blank\" href=\"ii:\/\/(.+?)\"/s", "class=\"iilink\" href=\"?msgid=$1\"", $string[$i]);
                }
                if (preg_match("/^====$/", $string[$i])) {
                        if (!$pre_flag) {
                                $pre_flag = true;
                                $string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
                        } else {
                                $pre_flag = false;
                                $string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
                        }
                }
                if(!$pre_flag && preg_match("/^\s?[a-zA-Zа-яА-Я0-9_\-]{0,20}(&gt;)+.+$/i", $string[$i])) {
                        $string[$i]="<span class='quote'>".$string[$i]."</span>";
                }

                if(!$pre_flag) {
                        $string[$i]=preg_replace("/(^|\s+)(PS|P\.S|ЗЫ|З\.Ы|\/\/|#).+$/i", "<span class='comment'>\\0</span>", $string[$i]);
                }
        }
        if ($pre_flag) $string[count($string) - 1] .= "</pre>";

ну разве что если /x/e/...

ahamai> Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?

Проблему длинных индексов. Всё максимально прозрачно и понятно. Использование разных по смыслу значений в роутерах это нормальная практика. Посмотри хоть на ii. У тебя /u/e -- часть пути, которая определяет функционал. А параметры у неё что? Тоже часть пути. Зачем ты сделал эту неоднозначность?

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

ahamai>> Складывается впечатление, что idec это пример плохого проектирования.
revoltech> На это я пытался намекнуть чуть ли не с первого дня появления здесь.

Но ты всё ещё здесь. В интернете кто-т неправ? Или что?

ahamai>> MSGID? по логике вроде бы да.
revoltech> Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.

ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.

revoltech> Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.

Ну да. Вместо выкачивания сотен килобайт мы выкачиваем сотни байт. Никакой экономии!

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

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

shaos> ну разве что если /x/e/...

Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.

> Что может быть проще? Грамматики? Конечные автоматы?

Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...

насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать

shaos> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать

Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.

> Но её админ должен об этом знать.

Ну я например не знал пока не загуглил :)

Потом пришлось свой анализатор логов переписывать, чтобы строки длинне 8К принимал ;)

> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.

В бандле только эхи и msgid. Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй

Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
Но сдерживаться мне всё тяжелее конечно...

Понимаю, что меня не воспримут, всё-таки напишу.

Подумайте, что за задачи вы решаете?

Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?

Потом, Рома трясёт своим ?sf=hash - как замену слайсов. На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим) и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку. Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.

Потом постоянные намёки на то, что нам нужно обязательно забрать всё одним запросом. Причём, неявно подразумевается что это благая цель которую все разделяют... ЗАЧЕМ?? У меня фетчер вообще забирает по 12 кажется msgid за раз, но он, наверное, самый быстрый из всех реализаций что я видел. Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.

Про ограничение на запрос. В лучшем случае в стандарт можно добавить рекомендацию про 8кб "стандарт" запроса, который в большинстве случаев совпадает с фактическим положением дел. Но расширение, которое будет показывать этот параметр, который вообще говоря доступен только веб серверу? Сами же простоту и элегантность хотите, нет? По 16 msgid забирать чистоплюство не позволяет? Значит, страдайте! :)

В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.

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

AL>> И это ломает поддержку стандарта.
revoltech> Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?

Ненужная вещь.

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

>> Это знает только автор. И то вряд ли вспомнит.

Да там всё в коде - читай нехочу, но только без поллитры в этих регекспах не разрбраться (мне):

                if (preg_match("/^====$/", $string[$i])) {
                        if (!$pre_flag) {
                                $pre_flag = true;
                                $string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
                        } else {
                                $pre_flag = false;
                                $string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
                        }
                }

А что тут разбираться? Может, кто-то пихает пробелы после ====? Ну так надо просто им напихать в панамку за это.

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

>> Что может быть проще? Грамматики? Конечные автоматы?
shaos> Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...

Как только начинаем писать что-то сложнее поиска подстроки, код на Си превращается в чан доширака. Регулярки надо осилить один раз и потом кратко и лаконично описывать желаемое.

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

revoltech> Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
revoltech> /u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10

Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.

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

shaos> ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)

Тем, что не решает никаких проблем :)

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

shaos>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.

Не вижу в нём смысла.

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

ahamai> Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её

Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?

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

shaos>> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
revoltech> Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.

А зачем?

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

Ну проблему нелогичности решает, на которую некоторые указывают :)

Нету пробелов после ====

Он просто иногда работает, но чаще не работает

    here?

Вот почему в предыдущем сообщении оно только на последний ==== среагировало? Пустую строку надо до?

    again?

Неа - опять не сработало…

AL> Не вижу в нём смысла.

Как клиенту понять, сколько сообщений максимум можно забрать за один запрос?

AL> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.

Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.

shaos> Неа - опять не сработало…

Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )

Только можно тестировать это в другой теме, пожалуйста? :)
P.S. Edited: 2024-10-31 08:53:11

hugeping> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Чтобы не качать лишнее.

hugeping> Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?

В реальности — точно так же, как и твой адаптивный фетч сейчас это делает, только без необходимости предварительно мурыжить каждую эху отдельно.

hugeping> По 16 msgid забирать чистоплюство не позволяет?

Накладные расходы не позволяют. Когда станция тормозит, это особо заметно.

Сейчас у меня в stations.txt напротив каждой ноды стоит число. Если непонятно, сколько сообщений нода позволяет забрать за раз, ставлю 12, ибо это случай с tgi и его ограничением 256 символов на гет. Андрей не озвучивал ограничение spline-online, поэтому там тоже стоит 12, и делать полный перефетч — это боль с такой-то скоростью отдачи. А бывает, что надо. Например, когда я внутренний формат базы поменял, добавив поле.

hugeping> Моё мнение -- надо замораживать вариант драфта Андрея.

Я-то не против, просто предлагаю вещи, которые облегчат жизнь, пока не поздно.

hugeping> Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.

Активного участия в дискуссиях не принимал, но решил попробовать:

$ time ./ii-tool fetch https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Start fetcher(s) for https://club.hugeping.ru
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/pipe.2032
INFO: 2024/10/31 12:20:50 Get https://club.hugeping.ru/u/e/std.rein
...

real	0m30,322s
user	0m9,286s
sys	0m4,117s

При фетче были ошибки на некоторые сообщения, у которых обнаружили "wrong repto format":
- ii://z8W283Fkra8J96OrKQCC
- ii://TKcKYfkzLXg3YU3iMQrS
- ii://nXdcHnk0Y4UunGNNUIwi
- ii://VJPNtsUz2RhjJUXPAqZs
- ii://GInGJYvgNySpTJGHmk8U
- ii://8vRmig2SXkHzCmgqFHOI
- ii://XLMzTeZG3uvc9kJIjUpU
- ii://2xsAUpSzT1kmFLiAP7TN
- ii://OANneaKiLh1Ft7Gx0NEP

Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?

tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?

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