> Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

0:0 у меня таки сработает как all
а вот -1:0 надо посмотреть...

> Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

2. сделал spnet.uplink

> Жесть. Ты теперь обязан жениться на u/e

Выходит что так :)

Всё равно наверное надо скажем раз в неделю делать полное забирание всего - чисто на всякий пожарный...

-1:0 не работает (точнее работает, но возвращает 0 хешей)
но я эту логику не трогал - видимо ii-php всегда так работал
исправлю

Проверил старый ii-point.php - он и по 0:0 возвращал 0 хешей :)
Так что я получается это уже частично исправил ;)
Осталось N:0 исправить...

> 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.

надо в iii-php фетчер под тебя подковырять, чтобы list.txt?h=1 спрашивал для понимания чего брать чего не брать - тогда буду почаще опрашивать

> Осталось N:0 исправить...

Исправил - заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения древнее сентября 2001 года)...

Заметил лишний пробел:

> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.

фактическу_ю

> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Может быть первое предложение подкорректировать?

Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Это не дата в заголовке сообщения, это дата когда сервер это сообщение принял либо по фетчу, либо по пушу, либо через поинтовый апи, либо путём копирования файлов извне (у меня сейчас - дата модификации файла сообщения). Ясно понятно, что 2001 год там быть не может. Да и в заголовке старая дата как бы не должна быть т.к. это timestamp проставляемый сервером при конвертировании ii сообщения из поинтового в сохранённое, чего никак не могло произойти раньше 2014 года...

И потом этот unixtime используется для отрезания сообщений в /u/e - типа дай мне всё что новее, а это обычно прям щас, не в прошлом

Тут ещё такой момент есть - ii-php со стародавних времён накладывает блеклистовый фильтр уже после того, как слайсы посчитаны и выходной список софрмирован, т.е. например если последнее сообщение в эхе заблеклисчено, то -1:1 вернёт ничего. По идее это решается административно путём принятия за правило никогда не блеклистить последнее сообщение в эхе - пусть оно немного "полежит" :)

А так надо быть готовым к тому, что запросив у меня скажем -10:10 можно получить в ответ только 9 сообщений...

Последний пункт написал doesnm

У меня статистика считается за сутки сразу после полуночи по тихоокеанскому времени - это 11 утра по Москве или 6 вечера по Владику, поэтому результат любого изменения лучше смотреть на следующий день.

И кстати у меня ведь теперь есть ii://spnet.uplink где можно это обсуждать :)

Сегодня статистика без таверны, которая похоже опять прилегла...

Echoareas
────────────────────────
idec.talks...........518 ██████████████████████████████████████████████████▒▒▒▒▒▒▒▒▒▒
bot.slashdot.........127 ██████████████████████████████████████████████████▒▒
lor.gold..............89 ██████████████████████████████████████████████████▒
lor.opennet...........39 ███████████████████████████████████████
bot.habr.rss..........29 █████████████████████████████
linux.14..............15 ███████████████
spnet.stats............7 ███████
blcat.local............6 ██████
idec.test..............4 ████
std.game...............3 ███
std.rein...............3 ███
im.24..................3 ███
iii.nizya..............2 ██
bot.antropogenezru.rss.2 ██
std.hugeping.micro.....2 ██
english.talks..........1 █
crypto.talks...........1 █
ii.stat................1 █
spnet.uplink...........1 █
────────────────────────
Total                853

Ну тут у тебя SQLite по ходу? Это читерство ;)
Настоящие пацаны БД на текстовых файлах держат ;)

> Да, он самый, как и на клиенте

Кстати SQLite расслабляет - лучше сразу на MySQL/MariaDB ориентироваться. Например в SQLite ключом можно чо угодно сделать (насколько я помню) и порядок записей всегда хронологический, а в MySQL если ты не сделал ORDER BY оно выльется как попало в зависимости от того как оно там внутри само заполнило дырки...

Ну я ж вчера ещё объяснил сей феномен - всё так, но при приёме сообщений никто не отбрасывает сообщения по несуществующему repto, т.к. оно может прийти позже (и приходит в некоторых случаях) или вообще может быть уже удалено - так всё норм. А фетчить всех со всех это надёжно. Вот сделаю себе адаптивный фетч и буду опрашивать всех чаще, чем раз в полчаса (кстати если бы с ноды blcat фетчил не только я, а и другие ноды, то сообщение на которой отвечал revoltech могло бы всплыть в сети и пораньше).

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

Да ну конечно - фидо в штатах же родилось и до сих пор как-то шевелится, хоть и по IP.
И левонеты кстати некоторые до сих пор существуют - я вопрос немного поизучал пару-тройку лет назад...

> жди моего ответа, когда хаос его польнет :)

шаос :)

это мой неизменный интернетовский ник с 1998 года...

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

В каком году это было? Всемирный пик фидо был в 1996 году, а потом пошёл спад

Я был немножко фидошником ещё когда жил в Екатеринбурге в 1997-1998 (всё как надо с модемом и т.д.)

Потом немножко левонетчиком (ZXNet в начале нулевых) - мне не понравилось т.к. там был трешак...

Это я в том смысле, что по ex-USSR оно с запозданием прошлось, когда во всём остальном мире уже был спад...

Ну в начале нулевых наверное

Ну так как FidoNet родилось в Сан-Франциско, то наверное в Калифорнии можно найти тех, кто помнит :)
Да даже тех кто до сих пор там сидит тоже можно найти ;)

> И кстати у меня ведь теперь есть ii://spnet.uplink где можно это обсуждать :)

Чото похоже ты у меня не забираешь обратно spnet.uplink т.к. у тебя всё ещё там 2 сообщения...

А что с таверной? Лежит уже дня 3:

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Apache/2.4.62 (Debian) Server at idec.spline-online.ru Port 80

Это значит мне надо опрашивать blcat чаще чем раз в 5 минут чтобы эстетическую красоту соблюсти :)

> Или проверять что поинт тебе шлёт сообщение с repto на отсутствующее сообщение. Не нода! Поинт.

И где я это отсутствующее сообщение буду искать? Ломиться всех опрашивать на всякий случай?

Вобщем покa сделал забирание blcat каждые 10 минут - 3,13,23,33,43,53

> а ещё там был Квиток :) распределённая регистрация, где со своим квитком можно было ходить по любым станциям, на которых есть этот публичный ключ.

А можно про эти самые "Квитки" поподробнее? Как предполагалось привязывать ключ к пользователю? Что если на какой-то левой станции появится другой ключ с привязкой к тому же имени пользователя?

Вот я тут в декабре 2021 года свои мысли излагал применительно к IDEC

ii://FvAoTezksrljZy6PtSQ2

Нельзя запрещать сообщения с неизвестным repto т.к. невозможно обеспечить 100% надёжную когерентность баз данных в этой сети - где-то всегда будут неувязки (какие-то временные, какие-то навсегда)

А idec.local чья?

Да кто его знает - опять наверное психанул? ;)

лучше

Все существующие IDEC-клиенты позволяют забирать эхи из разных источников (даже там, где пользователь не является поинтом). Так что это не только не запрещено, а вовсе даже наоборот - приветствуется! Поэтому не надо выдумать бессмысленные ограничения и ненужные правила на пустом месте. Поинт это по сути уже «полунода» ;)

К тому же в pipe.2032 в этом 2024 году было ровно одно сообщение

P.S. Извини, братан, но твоё следующее сообщение я заблеклистю из-за мата ибо сюда в том числе и дети ходют…

Вот что бывает, когда слишком часто опрашиваешь другие ноды - у меня это сообщение исчезло через пару минут после того как появилось…

Сорян, пришлось подредактировать…

Я за эксперименты с целью выяснить что летает лучше, что удобнее, что логичнее и т.д.

А topicid это msgid самого первого сообщения? С одной стороны его всегда можно вычислить по цепочке, однако если у нас появятся длинные темы на тысячи вхождений, то тогда по цепочке будет долго и потом цепочка может внезапно оборваться. Ну и с другой стороны чему оно может помешать? Так, что я могу поддержать у себя - да :)

P.S. Мои дети не матерятся (ни по русски, ни по американски), а им идёт уже 15-й и 20-й годок…

> ставим topicd этого сообщения

Не - само на себя сообщение не может указывать - мы же по контенту хеш считаем уже после того как заголовки готовы :)

> у меня детям 20, 19, 14 и 4 :) они не матерятся, наверное ;)

А они ii-эхи читают? ;)

Ну т.е. первое сообщение всегда без repto и topicid, следующее с одинаковыми repto и topicid, указывающими на предыдущее, а далее уже с тем же самым topicid, но меняющимися repto, так? А старые цепочки не трогаем?

Если отвечают на сообщение где только repto, ну или с «классической» IDEC-ноды оно пришло?

Ну так как я это себе и представлял

Понял

А т.е. это не глобально включать? Только для отдельных эх?

> будет отдельно стоящая станция с моими эхами без взаимного фетча.

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

tuple (ping,54)
doesnm (ping,55)
btimofeev (ping,6)

Ну скажем doesnm может вернуться в tgi:

doesnm(tgi,8)

А остальные - фсё?...

а вдруг какие клиенты/ноды поперхнутся от лишних тегов?
я точно знаю, что idec.spline-online.ru будет норм, т.к. я проверил его через ii://idec.test, послав туда сообщение с вручную расширенными тегами какое-то время назад:

ii://P3r4mlQ5ynJf6VpmMn8j

Кстааааати - из-за того, что все фетчат всех - даже если узел hugeping.tk станет сам по себе, евойные поинты смогут подкачивать апдейты ii://idec.talks из других мест, а отвечать всё также ТОЛЬКО на hugeping.tk , а другие ноды их ответы постепенно подтянут в сеть т.к. они всё также продолжают фетчить всех - в итоге hugeping останется с ответами без вопросов и беспорядок (там) ещё более усугубится :)