TGI station



Назад

idec.talks :: Полуневдимые эхи
==============================

subject: Полуневдимые эхи
24.10.2024 08:30
shaos (spnet, 2)  
 
Я знаю изначально была (и есть) возможность создавать скрытые эхи, которые не были видны через веб-интерфейс, не фигурировали в list.txt, но тем не менее их можно забирать по имени и даже добавлять вручную в свою конфигурацию веб-странички. А я вот у себя хочу запретить совсем скрытые эхи - типа всё должно быть перечислено в list.txt и видно программе клиенту, однако я думаю сделать некоторые эхи невидимыми через веб-интерфейс (пока юзер не залогинится своим паролем), но полностью видимыми через интерфейс поинта (и фетчинг) - в основном это для того, чтобы поисковики и всякие ай-боты их не читали (нынче мало кто обращает внимание на robots.txt поэтому если прятать, то надо прятать глубоко) - например тот же bot.slashdot и какие-то другие эхи построенные из RSS-фидов (а то мало ли что). Кому-то кроме меня это могло бы быть полезным?

Ещё один скользский момент - когда отцы-основатели добавляли RSS-эхи в ii/IDEC, то подразумевалось что эти эхи будут read-only или допускалось наличие возможности всенародного комментирования? В этом случае ведь нужен фетчинг в обе стороны...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 08:49
iiii (blackcat, 2) => 5t3RZZhcAiG8G3cqDRTp  
 
Да, я рассчитывал на комментарии прямо внутри сети. Вплоть до обратного постинга.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 09:55
hugeping (ping,1) => 5t3RZZhcAiG8G3cqDRTp  
 
В ii-go примерно так и сделано:

1. Только эхи которые есть в list.txt допустимы.

2. Есть скрытые эхи (начинаются с точки) но они используются для личных сообщений. На ii-go она одна. .private

3. В list.txt можно настроить:
- возможность писать сообщения в конкретную эху вообще (readonly);
- возможность писать в определенные эхи определенным поинтам и/или комментировать существующие записи.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 10:14
shaos (spnet, 2) => wHT9TikLKALslKp8Asfr  
 
И как в list.txt это будет выглядеть? Сейчас я смотрю list.txt вполне обычный у hugeping.tk
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 10:42
Andrew Lobanov (tavern,1) => 5t3RZZhcAiG8G3cqDRTp  
 
shaos> Я знаю изначально была (и есть) возможность создавать скрытые эхи, которые не были видны через веб-интерфейс, не фигурировали в list.txt, но тем не менее их можно забирать по имени и даже добавлять вручную в свою конфигурацию веб-странички. А я вот у себя хочу запретить совсем скрытые эхи - типа всё должно быть перечислено в list.txt и видно программе клиенту, однако я думаю сделать некоторые эхи невидимыми через веб-интерфейс (пока юзер не залогинится своим паролем), но полностью видимыми через интерфейс поинта (и фетчинг) - в основном это для того, чтобы поисковики и всякие ай-боты их не читали (нынче мало кто обращает внимание на robots.txt поэтому если прятать, то надо прятать глубоко) - например тот же bot.slashdot и какие-то другие эхи построенные из RSS-фидов (а то мало ли что). Кому-то кроме меня это могло бы быть полезным?

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

shaos> Ещё один скользский момент - когда отцы-основатели добавляли RSS-эхи в ii/IDEC, то подразумевалось что эти эхи будут read-only или допускалось наличие возможности всенародного комментирования? В этом случае ведь нужен фетчинг в обе стороны...

Всегда можно договориться с сисопом узла.

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

subject: Re: Полуневдимые эхи
24.10.2024 10:50
shaos (spnet, 2) => NXvMndC3LgnFN00rWBM3  
 
> Да, я рассчитывал на комментарии прямо внутри сети. Вплоть до обратного постинга.

Ну тогда вариант "комментировать существующие записи" очень даже имеет право на жизнь :)

Надо придумать простой способ указания прав доступа к эхам - типа
- кто может создавать сообщения (список поинтов либо все);
- кто может комментировать уже существующие сообщения (список поинтов либо все).
Возможно списки поинтов надо оформить в группы, чтобы у разных эх не поинтов перечислять, а группы (и типа будет группа any которая означает кто угодно и группа local включающая всех поинтов ноды).

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

subject: Re: Полуневдимые эхи
24.10.2024 10:57
hugeping (ping,1) => K3jBb0qUnuHp0ukSZsIY  
 
shaos> И как в list.txt это будет выглядеть? Сейчас я смотрю list.txt вполне обычный у hugeping.tk

Потому что наружу я показываю то, что соответствует стандарту. list.txt в данном случае это не файл, а ответ на get запрос.

А формат файла описан в доке на ii-go. На github.

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 11:02
shaos (spnet, 2) => NDelSpKzLBFPprh9zDYG  
 
> Фишка в том, что любой поинт может создать эху, просто отправив сообщение в несуществующую. Ты эту фичу хочешь убрать?

На своем узле - да, хочу чтобы этой фичи небыло (а она вообще на ii-php была?)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 11:08
shaos (spnet, 2) => TP1TybgHpdENTvCVJPhk  
 
> А формат файла описан в доке на ii-go. На github.

ок - почитаю
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 11:36
revoltech (spnet, 4) => SjgbnY9BzrMHOqfrehnk  
 
Проверил — у тебя эта фича есть и работает, а вот на tgi нет.

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

subject: Re: Полуневдимые эхи
24.10.2024 11:44
doesnm (ping,55) => fpkXJ8zy5ByC05ADlS17  
 
revoltech> Проверил — у тебя эта фича есть и работает, а вот на tgi нет.
revoltech> Зачем её убирать, в принципе? Всё равно скрытые эхи в общем списке не видны. Неплохая же блог-платформа выходит. И да, мне как раз эта идея в изначальной документации понравилась тоже.

Емнип блоги хоть и есть в IDEC (hugeping, tgi, difrex), но изначально они не задумывались ибо "ты подписываешься не на человека, а на контент"

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

subject: Re: Полуневдимые эхи
24.10.2024 11:51
hugeping (ping,1) => fpkXJ8zy5ByC05ADlS17  
 
revoltech> Зачем её убирать, в принципе? Всё равно скрытые эхи в общем списке не видны. Неплохая же блог-платформа выходит. И да, мне как раз эта идея в изначальной документации понравилась тоже.

Я могу сказать зачем я её убрал.

1) Легко атаковать. Генерится кучу сообщений с левыми эхами и забиваем базу. При этом админ этого не видит. А если видит, то получается "личные сообщения" перестают быть личными.

2) С точки зрения соблюдения законов. Я никогда не позиционировал свою ноду как "анархию". Ответственность за контент несёт админ. Если выясняется, что станция используется, например, для торговли в даркнете, то.... В общем, лучше пусть всё будет открыто и прозрачно. Фидо, кстати, тоже не было "анархией". Скорее наоборот.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 11:53
hugeping (ping,1) => vGdkpMAvcJjCkxilSKrw  
 
shaos> Надо придумать простой способ указания прав доступа к эхам - типа
shaos> - кто может создавать сообщения (список поинтов либо все);
shaos> - кто может комментировать уже существующие сообщения (список поинтов либо все).

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

subject: Re: Полуневдимые эхи
24.10.2024 12:03
hugeping (ping,1) => FNW0kfxJmCKCBqjfyjbQ  
 
doesnm> Емнип блоги хоть и есть в IDEC (hugeping, tgi, difrex), но изначально они не задумывались ибо "ты подписываешься не на человека, а на контент"

Да, именно. На самом деле станция ping скорее исключение. В первую очередь я решал свои "шкурные" интересы. Один источник данных для всей сетевой активности. И это в принципе получилось. С моей ноды идут сообщения в gemini, блог ( https://hugeping.ru ) и раньше шли ещё в твиттеры, телеграмм итд. При этом весь "контент" локализован одним текстовым файлом. Мне это нравится! То, что кроме всего этого можно обмениваться сообщениями - дополнительный профит. :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 13:51
Andrew Lobanov (tavern,1) => vGdkpMAvcJjCkxilSKrw  
 
>> Да, я рассчитывал на комментарии прямо внутри сети. Вплоть до обратного постинга.
shaos> Ну тогда вариант "комментировать существующие записи" очень даже имеет право на жизнь :)
shaos> Надо придумать простой способ указания прав доступа к эхам - типа
shaos> - кто может создавать сообщения (список поинтов либо все);
shaos> - кто может комментировать уже существующие сообщения (список поинтов либо все).
shaos> Возможно списки поинтов надо оформить в группы, чтобы у разных эх не поинтов перечислять, а группы (и типа будет группа any которая означает кто угодно и группа local включающая всех поинтов ноды).
shaos> Если какой-то старый узел пытается добавить сообщение (не ответ) в эху где кто угодно может только комментировать, то узел будет игнорировать такое сообщение. Возможно ещё надо будет явно запрещать отдавать локальные эхи - типа при попытке их зафетчить будет возвращаться пустота...

Может, вам проще взять phpbb? Зачем портить такую замечательную и простую вещь, как ii/idec?

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

subject: Re: Полуневдимые эхи
24.10.2024 13:54
tuple (ping,54) => sRH7l0CIjjAmIuLKonRa  
 
AL> Может, вам проще взять phpbb? Зачем портить такую замечательную и простую вещь, как ii/idec?

Вот-вот, куда усложнять маленький милый ii/idec? Он хорош таким, каким он есть.

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 13:59
hugeping (ping,1) => bw72vytSlpGyiD1qKBWc  
 
AL>> Может, вам проще взять phpbb? Зачем портить такую замечательную и простую вещь, как ii/idec?

tuple> Вот-вот, куда усложнять маленький милый ii/idec? Он хорош таким, каким он есть.

Вот! С моей точки зрения даже idec уже не настолько прост, как ii. И теряет часть его шарма.

Но я всё-таки довёл ii-go до текущего состояния не от хорошей жизни. Надеюсь, что больше не буду усложнять. )

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 14:11
doesnm (ping,55) => bw72vytSlpGyiD1qKBWc  
 
AL>> Может, вам проще взять phpbb? Зачем портить такую замечательную и простую вещь, как ii/idec?
tuple> Вот-вот, куда усложнять маленький милый ii/idec? Он хорош таким, каким он есть.

Усложнять сам протокол или его реализацию? Немного разные вещи

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

subject: Re: Полуневдимые эхи
24.10.2024 14:30
Andrew Lobanov (tavern,1) => SjgbnY9BzrMHOqfrehnk  
 
>> Фишка в том, что любой поинт может создать эху, просто отправив сообщение в несуществующую. Ты эту фичу хочешь убрать?
shaos> На своем узле - да, хочу чтобы этой фичи небыло (а она вообще на ii-php была?)

Никакой свободы :)

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

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

subject: Re: Полуневдимые эхи
24.10.2024 14:30
Andrew Lobanov (tavern,1) => UufknljegNKI9Rc3IA41  
 
revoltech>> Зачем её убирать, в принципе? Всё равно скрытые эхи в общем списке не видны. Неплохая же блог-платформа выходит. И да, мне как раз эта идея в изначальной документации понравилась тоже.
hugeping> Я могу сказать зачем я её убрал.
hugeping> 1) Легко атаковать. Генерится кучу сообщений с левыми эхами и забиваем базу. При этом админ этого не видит. А если видит, то получается "личные сообщения" перестают быть личными.

Это не личная переписка. Это эха, которой нет в списке. Админ должен видеть всё. Если же ты не видишь личную переписку, то как ты можешь гарантировать, что в ней не договариваются о продаже детей для работы на кокаиновых плантациях? А нагенерировать мусорного контента я тебе на баше и без скрытоэх могу гигабайты за несколько минут.

hugeping> 2) С точки зрения соблюдения законов. Я никогда не позиционировал свою ноду как "анархию". Ответственность за контент несёт админ. Если выясняется, что станция используется, например, для торговли в даркнете, то.... В общем, лучше пусть всё будет открыто и прозрачно. Фидо, кстати, тоже не было "анархией". Скорее наоборот.

Так это не анархия. Это свобода. Не надо путать одно с другим :)

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

subject: Re: Полуневдимые эхи
24.10.2024 14:30
Andrew Lobanov (tavern,1) => wFNW0kfxJmCKCBqjfyjbQ  
 
revoltech>> Проверил — у тебя эта фича есть и работает, а вот на tgi нет.
revoltech>> Зачем её убирать, в принципе? Всё равно скрытые эхи в общем списке не видны. Неплохая же блог-платформа выходит. И да, мне как раз эта идея в изначальной документации понравилась тоже.
doesnm> Емнип блоги хоть и есть в IDEC (hugeping, tgi, difrex), но изначально они не задумывались ибо "ты подписываешься не на человека, а на контент"

Да фиг с ними с блогами. Я пообщаться с кем-то хочу не в общем пространстве, например. Или по какой-то новой теме. Зачем каждый раз сисопа дёргать? Если вырастет во что-то приличное, можно открыть и даже обмен между узлами начать, если не вырастет, то и пофиг.

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

subject: Re: Полуневдимые эхи
24.10.2024 14:49
shaos (spnet, 2) => sRH7l0CIjjAmIuLKonRa  
 
Ну phpbb у меня есть с 2003 года :)

http://forum.nedopc.org

И оно сугубо централизованное, а мне нужно распределённое и многоузловое….

И потом не надо культивировать мнение, что IDEC такойr простой - он уже не такой простой как ii…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:00
shaos (spnet, 2) => bw72vytSlpGyiD1qKBWc  
 
Да не маленький он уже…

И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:07
revoltech (spnet, 4) => Rt3KAnpDeyVdWYqaFsOw  
 
shaos> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:11
shaos (spnet, 2) => fpkXJ8zy5ByC05ADlS17  
 
Надо будет фичу выпилить ;)

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

Ну и чисто административный момент - даже если сисоп временно потерял физический доступ к узлу (уехал в отпуск) у него должна оставаться возможность видеть что там происходит пользуясь открытыми апи (напрямую либо через ботов)…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:17
shaos (spnet, 2) => AzO2fTFa469vTFf7dtGM  
 
Ну это можно решить путём объединения эх в тематические группы (которые будут иметь смысл только на уровне узла и не будут задевать сам протокол) - например для временных или мелких эх может существовать тематическая группа unsorted…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:18
revoltech (spnet, 4) => 5yTXcZ6CAQ1EYYflfQ9E  
 
shaos> Объясню - по мне так должна быть возможность программно вытянуть весь контент узла любому кто не есть админ узла (причём через веб можно возможности и поурезать т.к. вебом не только люди пользуются), а со скрытыми эхами такой возможности нет.

Так, может, лучше тогда автоматизировать их добавление в list.txt, то есть сделать их НЕ скрытыми, вместо урезания полезной фичи?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:09
doesnm (ping,55) => Rt3KAnpDeyVdWYqaFsOw  
 
shaos> Да не маленький он уже…
shaos> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

А кто заставляет вас его использовать? ii и IDEC полностью совместимы
Хотя бесполезного трафика станет больше
Да и можно ли сравнить ii/IDEC с SMTP? Тоже простой протокол, но пришлось навешать кучу костылей начиная от авторизации и заканчивая всякими DKIM/DMARC/SPF

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

subject: Re: Полуневдимые эхи
24.10.2024 15:26
Reprise (tavern,18) => ls77RJxQgFFAcojCUiqJ  
 
shaos> Ну phpbb у меня есть с 2003 года :)
shaos> http://forum.nedopc.org
shaos> И оно сугубо централизованное, а мне нужно распределённое и многоузловое….
shaos> И потом не надо культивировать мнение, что IDEC такойr простой - он уже не такой простой как ii…

То, что он чуть сложнее ii, не значит, что нужно делать из него монстра с непонятными с точки зрения юзабилити фичами.

+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:26
Reprise (tavern,18) => Rt3KAnpDeyVdWYqaFsOw  
 
shaos> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

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

+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:44
shaos (spnet, 2) => jd7jrs6eWWHVHB7Uiza2  
 
При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:49
shaos (spnet, 2) => I4893ZLwuH1r4eL8H7Kg  
 
Это был риторический вопрос :)

Всё в этом мире должно развиваться и обрастать фичами ;)

Благо IDEC позволяет декларировать расширения узла через публичный список фич…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:50
shaos (spnet, 2) => X6WhBLlommGvRKug6YsU  
 
Тоже самое можно сказать и про IDEC сейчас :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 15:55
shaos (spnet, 2) => D8bkzPP9XjCfk7gvczHl  
 
Ну это издевательство над здравым смыслом когда одной рукой вы разрешаете декларировать поддерживаемые фичи через features, а другой запрещаете эти фичи расширять…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:03
shaos (spnet, 2) => QKXeihAnj54ZPtf5229t  
 
> Для того, чтобы её не было, нужно писать дополнительный код, который по идее вообще вредный, так как удобную фишку убирает….

Ну например можно выкинуть «вообще вредный» код файлэх, который сейчас чуть ли не половину всего кода ii-php занимает :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:18
hugeping (ping,1) => zsnW8Ac3wePhYQ6etgur  
 
shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)

revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

Там есть полезная вещь, возможность забирать не все сообщения, а только часть. Например, последние n сообщений. Это позволяет делать фетчинг который не гоняет по интернету всегда полный индекс. Очень сильно снижает количество трафика.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:35
shaos (spnet, 2) => qIm4tvobxJulwZOlnqfN  
 
> Очень сильно снижает количество трафика.

Это да :)

TOP10 VISITORS:

[1] 145.224.100.x point=136 web=31 up=53.3MB (45%) <--- 145.224.100.x (6/hr)
[2] Google point=8 web=1298 up=20.8MB (17%) <--- Google
[3] 176.109.111.x point=48 web=0 up=16.8MB (14%) <--- tavern (2/hr)
[4] 217.197.116.x point=142 web=0 up=12.1MB (10%) <--- blackcat (6/hr)
[5] 92.63.98.x point=72 web=0 up=5.2MB (4%) <--- tgi (3/hr)
[6] 95.165.9.x point=145 web=4 up=3.3MB (2%) <--- ping (6/hr)
[7] 185.220.101.x point=4 web=0 up=1.0MB (<1%) <--- 185.220.101.x
[8] 24.130.121.x point=3 web=62 up=0.8MB (<1%) <--- spnet
[9] Facebook point=0 web=51 up=0.5MB (<1%)
[10] 179.43.159.x point=1 web=0 up=0.4MB (<1%) <--- 179.43.159.x

TOTAL TRAFFIC: 116MB

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:37
revoltech (spnet, 4) => QB5IzBQrBHbyqbT6d5UK  
 
shaos> При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

Мой посыл состоял в том числе и в посыле веба нафиг. А вот карма и прочие соцрейтинги пусть там, в вебе, и остаются. Если мои сообщения из веб-зеркал видны не будут, я не сильно расстроюсь.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:41
revoltech (spnet, 4) => qIm4tvobxJulwZOlnqfN  
 
hugeping> Там есть полезная вещь, возможность забирать не все сообщения, а только часть. Например, последние n сообщений. Это позволяет делать фетчинг который не гоняет по интернету всегда полный индекс. Очень сильно снижает количество трафика.

Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает. Определить, какие айдишники ещё не сфетчены, можно и на клиенте. Погоду делает то, что этих самых айдишников в GET /u/m можно поместить всего 12 штук, а дальше твой (вроде бы, не помню уже) нжинкс начнёт ругаться на слишком длинную строку запроса.

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

Теперь понятнее?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:52
revoltech (spnet, 4) => 1ijV17WR1m02eK7ye033  
 
shaos> Это да :)

Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов по 12 айдишников из-за ограничений хттпшного гета на сервере, а чем-то более вменяемым? Или нет? В доках ничего, кроме GET /u/m, по этому поводу не нарыл.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 16:54
hugeping (ping,1) => z1DKjBvsvVcZ39NBdOm9  
 
revoltech> Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает.

Почему не делает? Если каждые 5 минут делать фетч из эх, которые содержат по 10 тысяч сообщений, то как раз делает. Конечно, по современным меркам ~60мб в сутки на 10000 сообщений это вроде бы мелочи, но... Как-то меня такое не вдохновляет. Допустим, сообщений на ноде не 10тыс а 100тыс... Почему нет?

revoltech> В результате при фетче с нуля приходится разбивать каждый список на группы по 12 и выгребать сообщения отдельными запросами. А это не оптимально ни разу.

revoltech> Теперь понятнее?

Мне то понятнее, поэтому я и говорю - посмотри как сделано в ii-go. Там быстрый многопоточный фетчер.

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
24.10.2024 17:08
hugeping (ping,1) => 47WbOWWFZL5IUuqXHVkQ  
 
revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов

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

subject: Re: Полуневдимые эхи
25.10.2024 02:02
iiii (blackcat, 2) => z1DKjBvsvVcZ39NBdOm9  
 
Расширения idec я не поддерживаю, но конкретно в моей реализации есть две минифичи, естественно это никакой не стандарт:

при запросе list.txt с ключом ?h=1, он вместо описаний эх показывает хэши файлов эх, чтобы можно было забирать только изменившиеся эхи.

при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного (если указанного в списке нет, выдаст все). но запрашивать так можно по одной эхе. это нигде и никогда не использовалась, но такая возможность в моей реализации есть, каждая заняла по 2 строчки кода в коде сервера, поэтому добавил.

ещё раньше была возможность задавать количество скачаного с помощью url, типа запрос /lim/200/u/e вместо /u/e отдавал только последние 200 хэшей из эхи - то есть, вообще не надо менять клиентский софт или фетчеры, просто менять строку в конфиге. в следующей версии nastene, когда я перепишу её на picnic, я её верну
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 02:27
shaos (spnet, 2) => zNxVGj877IRDiLtzMXAK  
 
Первые 2 фичи интересные, а по лимитам вроде у IDEC логичнее получается
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 02:14
iiii (blackcat, 2) => zsnW8Ac3wePhYQ6etgur  
 
> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

а что за расширение list.txt? не слышал. щас у себя посмотрел, el поддерживает ключи ?h=, ?n=, и ?el= :) сидел соображал. что к чему. не сообразил.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 02:45
iiii (blackcat, 2) => lxIyTY0be8AT7PlHMQP1  
 
Я не понимаю, как это работает, я не знаю как запросить последние n сообщений и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине. Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится. , в отличие от хэша. Я вообще при делании срезов не понимаю, что входит а что не входит. Поэтому у меня на станции нет постраничного вывода :)

А lim совместим со всем, хоть с ii txt 0.1, меняется только строка в конфиге.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 02:46
iiii (blackcat, 2) => TezUbF3zzvUElUBLRODJ  
 
Точнее наоборот, сообразил :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 02:46
iiii (blackcat, 2) => mErVbEzmt2V5kOtNjyQf  
 
Тока оно неверно работает, надо поменять
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 07:08
shaos (spnet, 2) => TezUbF3zzvUElUBLRODJ  
 
> а что за расширение list.txt?

Видимо имелось ввиду что

GET /list.txt

появился только в IDEC - спецификация перечисляет это в расширениях

или оно в ранних версиях ii тоже было?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 07:21
shaos (spnet, 2) => FkvDFVK566lgIFEfnspG  
 
> я не знаю как запросить последние n сообщений

допустим надо взять последние 5 хешей из retro.talks:

/u/e/retro.talks/-5:5

в данном случае смещение отрицательное - значит считаем с конца ну и после двоеточия количество

> и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине.

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

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

по идее "жобавляется" всегда в конец, а из середины только удаляется (блеклистается) и если брать частями, то наверное надо брать с перехлёстом на 1, чтобы точно ничего не удалилось на границах блоков пока ты их вычитываешь...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 07:31
shaos (spnet, 2) => zNxVGj877IRDiLtzMXAK  
 
По идее хеши можно было бы в IDEC протокол добавить для GET /x/c/echo.1/echo.2 которое сейчас возвращает количество сообщений (видимо предполагалось, что сообщения никогда не удаляются). Кто-то вообще пользуется /x/c/... сейчас? Ну или завести новый вызов /x/h/... для возврата списка с хешами списков хешей...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 07:40
shaos (spnet, 2) => zNxVGj877IRDiLtzMXAK  
 
> при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного

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

subject: Re: Полуневдимые эхи
25.10.2024 07:27
ahamai (blackcat, 2) => RHL8N4NrnAYvC0TzZecV  
 
Это всегда было
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 07:57
ahamai (blackcat, 2) => Zk4mNNnqCDRtcwnWJgC2  
 
в этом случае ничего не будет правильно. естественно, для каждой станции должно быть свой счётчик, в том числе и счётчик сообщений, потому что это ненадёжный параметр. И хэш на каждой станции для каждой эхи отслеживается свой, счётчик тут ещё более ненадёжный, потому что в конкретный момент на разных станциях разное количество сообщений. Впрочем я уже говорил, что счётчик это параметр которому нельзя доверять.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:22
shaos (spnet, 2) => fFY68RpO8bmLm7gZLVft  
 
Действительно:
====
a45cdfa3 (user 2014-04-01 19:19:03 +1100 9) @route('/list.txt')
a45cdfa3 (user 2014-04-01 19:19:03 +1100 10) def list_txt():
a45cdfa3 (user 2014-04-01 19:19:03 +1100 11) response.set_header ('content-type','text/plain; charset=utf-8')
08c516db (user 2014-04-06 00:06:51 +1100 12) lst = api.load_echo(False)[1:]
08c516db (user 2014-04-06 00:06:51 +1100 13) if request.query.n:
08c516db (user 2014-04-06 00:06:51 +1100 14) return '\n'.join([t[0] for t in lst])
08c516db (user 2014-04-06 00:06:51 +1100 15) else:
08c516db (user 2014-04-06 00:06:51 +1100 16) return '\n'.join(['%s:%s:%s' % t for t in lst])
08c516db (user 2014-04-06 00:06:51 +1100 17)
====
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:30
shaos (spnet, 2) => bCUznGgsK3kn7KiBi9ix  
 
да - хэш надёжнее, но действительно придётся хранить хеши для каждого узла

вобчем я наверное сделаю у себя вызов GET /x/h/echo.1/echo.2 по аналогии с GET /x/c/echo.1/echo.2

ну и GET /list.txt?h=1 заодно тоже можно поддержать ;)
====
idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
====
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:04
ahamai (blackcat, 2) => aCdkdLtyJNJBVbmJABOR  
 
> например для ретроклиентов, которые по собственной ограниченности не могут принять многомегабайтный список хешей в один присест - идём кусочками от начала до конца

Вообще не понимаю, можно какой-то конкретный пример. Зачем брать кусками список? И мегабайт хэшей - это 49000 сообщений. Вообще не могу представить юзкейс.

> допустим надо взять последние 5 хешей из retro.talks:
> /u/e/retro.talks/-5:5
> в данном случае смещение отрицательное - значит считаем с конца ну и после двоеточия количество

я всё равно не могу понять, зачем это может быть нужно кроме юзкейса "запросить n последних сообщений". Я в слайсах не разбираюсь, там вечно массив 20 может быть или 19, или 20, или 21, у меня и постраничного вида нет, потому что у меня и реверс и разбирать это я с ума сойду. Вот это я сделать не смогу, мне слишком нудно разбираться. Достаточно было одного крайнего случая "н последних сообщений", это гораздо проще кодить и на клиенте, и на сервере. Мой lim прозрачен для вообще любых клиентов, какие существовали в истории, если кто-то не хочет тянуть 49000 файлов. А по факту в txt клиенте у меня уже ограничение на запрос только 100 последних мессаг. Средств для больших эх никогда не задумывалось потому что изначально, и это была часть концепции, не должно было быть больших эх.

> по идее "жобавляется" всегда в конец, а из середины только удаляется (блеклистается) и если брать частями, то наверное надо брать с перехлёстом на 1, чтобы точно ничего не удалилось на границах блоков пока ты их вычитываешь...

ну если бы я делал фетчер, я бы ещё штук 5 сверху проверял, на всякий случай. и раз в день полная проверка списка.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:08
ahamai (blackcat, 2) => 90NVGjKxIILe7gGeoIII  
 
в протокол ничё добавлять не надо, но если волнует трафик можешь сделать это в любом виде, хоть как у меня через list.txt, хоть как угодно иначе - я приспособлю фетчер, чтобы хабры и опеннеты зря не гонять лишний раз (выборки никакие юзать не буду, просто не дёргать эху если она не изменилась)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:09
ahamai (blackcat, 2) => 90NVGjKxIILe7gGeoIII  
 
у меня это так было сделано

https://github.com/gk11-ru/ii-elp/blob/master/run.py#L24
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:57
revoltech (spnet, 4) => 7aROsEH4ibAxMLly0i6u  
 
shaos> ну и GET /list.txt?h=1 заодно тоже можно поддержать ;)

Эх, лучше бы поддержали POST /u/m, тогда не пришлось бы по куче мелких запросов при перефетче делать.

А то тут предложили многопоточность, но я ориентируюсь в том числе и на одноядерное железо. И, конечно, вопроса оптимизации (а оптимизация ≠ скорость) многопоточность при выгребании сообщений не решает — всё равно при полном перефетче будет гоняться куча метаданных и создаваться куча TCP-соединений неизвестно с какой целью.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 08:59
shaos (spnet, 2) => KqmUkCPNDfp2Yh2zZzCt  
 
> Вообще не понимаю, можно какой-то конкретный пример.

Например ZX Spectrum с сетевой карточкой Spectranet - у этого компа 48КБ ОЗУ только, но т.к. Spectranet использует бейсик (который в ПЗУ прошит в первых 16КБ) у которого есть свои переменные и ещё экран занимает 6912 байт ОЗУ т.е. под буфера останется 32КБ или даже меньше...

> у меня и постраничного вида нет

ну может у кого-то есть, ну или будет ;)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:01
shaos (spnet, 2) => 2p1RnDLBgYMtLW21FVlB  
 
> Эх, лучше бы поддержали POST /u/m, тогда не пришлось бы по куче мелких запросов при перефетче делать.

это тоже можно
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:02
shaos (spnet, 2) => 7IJgBKR2xnGggkmouhkq  
 
ok - попробую для начала list.txt?h=1
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:11
revoltech (spnet, 4) => 0yANY6jgZShU0PZYb6Wv  
 
hugeping> Нет.

Вполне достаточный ответ.

hugeping> А слайсы решают проблему больших индексов.

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

Мой юзкейс — зашёл утром, запустил tiifetch.tcl или нажал на кнопочку Fetch all echos в tiix, клиент докачает изменения всех эх за ночь и в течение дня дофетчиваю только новое содержимое конкретно интересующих эх, вручную жмякая на Fetch this echo при необходимости. За это время в них может собраться куда больше 100 сообщений, и в случае слайсинга ещё на серверной части до клиента они уже не дойдут никогда.

Поэтому придерживаться базового протокола мне пока кажется более разумным, только вот с выгребанием по /u/m надо что-то решать. 12 айдишников на запрос — слишком мало, а многопоточность всё равно не решает проблему с кучей TCP-соединений и HTTP-метаданных.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:14
shaos (spnet, 2) => w1w2MvlGnXkxv7LAbAyC  
 
кстати у меня апач - у него тоже ограничение на 256 символов в урле?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:18
revoltech (spnet, 4) => eIrJj4IeOBajqdX9xfM0  
 
shaos> это тоже можно

Это было бы здорово. С любым ударением на этом слове.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:25
shaos (spnet, 2) => cSAum5C4Ec8lzH8AFAn6  
 
гугол говорит 8192
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:17
ahamai (blackcat, 2) => AzrimykLm3pNu1sO0f8y  
 
> Например ZX Spectrum с сетевой карточкой Spectranet - у этого компа 48КБ ОЗУ только, но т.к. Spectranet использует бейсик (который в ПЗУ прошит в первых 16КБ) у которого есть свои переменные и ещё экран занимает 6912 байт ОЗУ т.е. под буфера останется 32КБ или даже меньше...

зачем тебе там список сообщений, если ты там и одно сообщение не отобразишь? :)

для таких вещей вообще абсолютно кастомные гейты надо делать, а не стандартные средства

ps. блин, опять потерялся текст про спектрум в коробке из под обуви, интересно в какую эху я его запульнул в итоге... в рухуморе14 нет
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:33
revoltech (spnet, 4) => AtV4a5eXlm2rA6J5JGb8  
 
shaos> гугол говорит 8192

Да, в теории 389 айдишников туда поместятся. Всё равно маловато, но лучше, чем по 12 группировать.

Может, сделаю в stations.txt напротив каждой урлы поле, которое указывает максимальное количество адишников. Мол, если не знаем, ставим 12.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:40
shaos (spnet, 2) => namIvkTPiqS4Liy6ghT7  
 
> зачем тебе там список сообщений, если ты там и одно сообщение не отобразишь? :)

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

> для таких вещей вообще абсолютно кастомные гейты надо делать, а не стандартные средства

если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?...

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:58
shaos (spnet, 2) => yeUHAZqZ3D0uBfglozIm  
 
Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение:

https://tgistation.ru/echo/subj/8/%D0%9F%D1%80%D0%B5%D0%B4%D0%BB%D0%B…

А куда делся ake кстати? Его сайт http://gears.headake.win/idec/ui2/ тоже пропал где-то в 2022 году:

https://web.archive.org/web/20220120232845/http://gears.headake.win/i…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:56
ahamai (blackcat, 2) => bcGCVvE4u8eAdrnIugmV  
 
> если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?..

Без гейта ты нормально не отобразишь ничего ни на zx spectrum ни на msdos, ни на atari st. Сначала научи их utf8 :)

Хочется хоть одно реальное применение слайсов, кроме "забрать последние сообщения"
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:57
ahamai (blackcat, 2) => w1w2MvlGnXkxv7LAbAyC  
 
У меня в фетчере то ли по 20 то ли по 40. Вся текущая сеть выкачивается довольно быстро.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 09:57
ahamai (blackcat, 2) => kMtg0MnDczwCpxhrlBKe  
 
На мобильном интернете
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:02
ahamai (blackcat, 2) => TUUvfJeMW1R6fYMOMqbP  
 
Операция атомарна, поэтому надо чтобы в случае чего она была проведена без сбоев, а то заново придётся качать

За 10 лет не помню проблем с текущим фетчем
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:05
revoltech (spnet, 4) => cLd6zJShbslmqzDuXRW9  
 
shaos> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение

И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных, т.к. владельцы станций ограничивают длину GET-запросов, либо сознательно, либо оставляя дефолт на веб-сервере. С POST запрос будет всегда одним в идеале.

С тем же успехом можно на Gemini/Spartan перелезть полностью — там длина запроса 2048 символами ограничивается, если не ошибаюсь. В Nex и такого ограничения нет.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:06
shaos (spnet, 2) => cLd6zJShbslmqzDuXRW9  
 
Там у него была историческая эха ii.14 которой похоже больше нигде нету :(

https://web.archive.org/web/20211023211000/http://gears.headake.win/i…
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:09
shaos (spnet, 2) => eQvqj5jfN7G6lRd0vRrt  
 
> Сначала научи их utf8 :)

А я уже - ещё в декабре 2021 :)

https://www.youtube.com/live/p20rd0bqZTs
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:15
ahamai (blackcat, 2) => 4KgeB013AkJL02bQKBtC  
 
Кросспостинг был изначально, но я от него сразу отказался, он создаёт больше проблем, чем решает. Он тут не нужен
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:22
ahamai (blackcat, 2) => 4KgeB013AkJL02bQKBtC  
 
Один запрос на тысячи сообщений. И если что то не докачается, качай всё заново. Поэтому секциями и качается.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:24
ahamai (blackcat, 2) => 4KgeB013AkJL02bQKBtC  
 
7 пункт используется в elp. Жалею что не включил сразу.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:25
ahamai (blackcat, 2) => vzWy8xbgxFCMsg2YXB7g  
 
Она же есть в аликорновских архивах вроде?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:29
ahamai (blackcat, 2) => 4KgeB013AkJL02bQKBtC  
 
> С тем же успехом можно на Gemini/Spartan перелезть полностью — там длина запроса 2048 символами ограничивается, если не ошибаюсь. В Nex и такого ограничения нет.

По хттп можно качать хоть с дискеты и вообще отовсюду, он есть везде.

Сегментирование запросов было введено специально. И я не вижу проблемы, я щас всю rulinux14 скачал за несколько секунд.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:38
shaos (spnet, 2) => Ke1DwWEcxrl0CcRhv6Qy  
 
неа
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 10:46
revoltech (spnet, 4) => Fb8hAHmhc0nX3XG5meXu  
 
ahamai> По хттп можно качать хоть с дискеты и вообще отовсюду, он есть везде.

А для некса с гофером вообще ничего, кроме нетката/телнета (голого TCP), не нужно.

ahamai> Сегментирование запросов было введено специально.

Чтобы создать новым поинтам затруднения с первым выкачиванием эх (а-ля блокчейн монеро)?

ahamai> И я не вижу проблемы, я щас всю rulinux14 скачал за несколько секунд.

Сколько сообщений можно выкачать за один запрос у тебя на станции?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 11:11
ahamai (blackcat, 2) => 6O5fDJerPx6ccS2TeO5n  
 
Надо найти хоть кого то у кого есть архивы
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 11:12
ahamai (blackcat, 2) => 0DvckNPFCWVoFbnfbtE8  
 
Я кликнул difrex a на лоре но он не ответил
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 11:20
ahamai (blackcat, 2) => Noq1smMikVpR41kRGZrU  
 
Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Лимит на get у меня вроде тоже 8 кб
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 12:03
revoltech (spnet, 4) => 1o2JLNyKQ5YarktJ2rOz  
 
ahamai> Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Намёк был на то, что есть транспорты ещё проще, чем HTTP. Например, Nex/NPS можно вообще описать парой коротких предложений:

1. Скачивание (Nex): отправляем путь и LF на TCP-порт 1900, забираем данные.
2. Постинг (NPS): отправляем путь и LF, опционально строку авторизации и LF, сами данные, LF, точку (.) и LF на TCP-порт 1915, забираем ответ.

Всё, это оба протокола. Дальше в Nex расписано, что рекомендуется делать на клиенте, если путь заканчивается на /, но к ii это уже можно не применять. Вместо LF можно использовать CRLF, как минимум существующие сервера это понимают.

Суть именно в простоте, даже на оф.сайте указано сверху, как через nc выгрести Nex-ресурс:

echo nps/info/form.txt | nc nightfall.city 1900 | less

С гофером, кстати, точно так же, только порт по умолчанию 70. Но нет, давайте городить огород с ненужными для ii HTTP-хедерами, лимитами на гет-запросы и контент-тайпами.

Если что, не осуждаю существующие подходы, просто не понимаю, почему бы опционально не сделать ещё проще.

ahamai> Лимит на get у меня вроде тоже 8 кб

Это типа «640 кб хватит всем»? :D Ну ладно, поставил тоже 389 на запрос. Как-нибудь попробую перефетч. А у остальных как? У пинга понятно, нжинкс и 12 сообщений на запрос максимум. А у spline-online и tgistation что?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 12:26
hugeping (ping,1) => 4KgeB013AkJL02bQKBtC  
 
revoltech> И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных

Каких метаданных и почему куча соединений? Если ты работаешь последовательно - то это несколько подряд идущих get запросов, а не куча параллельных соединений. Если же ты хочешь скорости, то да - потоки. Но это вообще говоря две независимые вещи. Например, запуск отдельных фетчеров на каждый узел. И да, многопоточность не связана с наличием свободных процессоров. Там нагрузки практически нет, вопрос не в утилизации мощности вычислительной, а в "съедании" времени ожидания TCP.

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 12:28
hugeping (ping,1) => SO0bBc8HQl1TRwIHR5iP  
 
revoltech> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 12:46
revoltech (spnet, 4) => z5oeWQYodL5C28ZLveS3  
 
hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

А, значит, с tgi перепутал. Пардон. Изначально тестил на обоих.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 12:54
revoltech (spnet, 4) => 8sAzucCYUiggVTlJ60AG  
 
hugeping> Каких метаданных и почему куча соединений?

Даже если отбросить всю низкоуровневую тряхомудию с установкой TLS-соединения и проверкой сертификатов при HTTPS, каждый HTTP-запрос — это статусы, заголовки Accept, Content-Type, Content-Encoding и т.д. Тут, как ни крути, оверхед будет существенным при большом количестве мелких запросов. Поэтому тело запроса укрупнять смысл имеет в любом случае.

P.S. Да, ещё раз пардон, перепроверил — то у tgi только 12 сообщений за раз можно выгрести. У остальных 389, у тебя вообще лимит 10000 вроде хавает без проблем. Правда, spline-online не тестил, он и так еле живой сейчас.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 12:44
hugeping (ping,1) => zDTrsh3ACUb6K7l0CbBO  
 
revoltech>> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

hugeping> У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.

В общем, откуда инфа про 12? Запрос ввёл сейчас раза в два больше - не вижу ограничений. Или это опять, поэтическое преувеличение?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 13:10
hugeping (ping,1) => 8moYNFWCPUWaM1NzWgyp  
 
revoltech> P.S. Да, ещё раз пардон, перепроверил — то у tgi только 12 сообщений за раз можно выгрести. У остальных 389, у тебя вообще лимит 10000 вроде хавает без проблем. Правда, spline-online не тестил, он и так еле живой сейчас.

Кстати, это соответствует "рекомендованному" буферу в 8к. Как раз ~380 id-шников. 12 сообщений это, конечно, маловато даже по меркам "обычного" веба.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 13:18
ahamai (blackcat, 2) => SO0bBc8HQl1TRwIHR5iP  
 
Это понятно, но меня http полностью устраивает по ресурсоёмкости, распространённости везде и для всего, веб-фреймворков для него.

Ну и есть всякие плюшки типа минимальной гарантии доставки (content-len, или если что-то пошло не так, брякнулись с ошибкой и клиент понял что ошибка). Плюс опциональное gzip сжатие, существующее с лохматых годов. Правда, сейчас py3 фетчер не поддерживает gzip сжатие, py2 и ii-txt на py2 поддерживают. Сейчас глянул, у меня на сервере не включён gzip для text/plain, включил.

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

subject: Re: Полуневдимые эхи
25.10.2024 13:26
ahamai (blackcat, 2) => 80dk509hGoUBKRFxW0SI  
 
увеличил буферы в nginx. скормил url на 89 кбайт - сожрало
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 13:49
revoltech (spnet, 4) => pfhpzpZrqxZcAVR2yRwV  
 
ahamai> Ну и есть всякие плюшки типа минимальной гарантии доставки

А TCP для чего вообще создавался, если не для минимальной гарантии доставки? Зачем дублировать то же самое на уровень выше, но с обязательными метаданными?

ahamai> Для меня простота - это возможность в несколько строк написать фетчер хоть на python, хоть на busybox, поэтому я буду поддерживать реализацию только через http. Но всегда интересно посмотреть на сторонние проекты.

Мысль понял, никого не заставляю, но nc и awk имеются и в busybox (как, впрочем, и декодер base64).
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 13:51
revoltech (spnet, 4) => W5jWm8sODTA0QTTcdJcA  
 
ahamai> увеличил буферы в nginx. скормил url на 89 кбайт - сожрало

Так и оставил? Я могу быть уверенным, что выгребу 4238 сообщений за один запрос?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 13:58
Andrew Lobanov (tavern,1) => GHtyyaAHCsvmAwAlMmoV  
 
>> Для того, чтобы её не было, нужно писать дополнительный код, который по идее вообще вредный, так как удобную фишку убирает….
shaos> Ну например можно выкинуть «вообще вредный» код файлэх, который сейчас чуть ли не половину всего кода ii-php занимает :)

Можно. Но вред файлэх в чём? Вред твоей идеи понятен -- ты хочешь ограничивать своих пользователей в фичах и свободе общения.

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

subject: Re: Полуневдимые эхи
25.10.2024 13:58
Andrew Lobanov (tavern,1) => 5yTXcZ6CAQ1EYYflfQ9E  
 
shaos> Надо будет фичу выпилить ;)
shaos> Объясню - по мне так должна быть возможность программно вытянуть весь контент узла любому кто не есть админ узла (причём через веб можно возможности и поурезать т.к. вебом не только люди пользуются), а со скрытыми эхами такой возможности нет.

Никуда не девается эта возможность. Скрытые эхи работают точно так же, как и те, что в list.txt.

shaos> Ну и чисто административный момент - даже если сисоп временно потерял физический доступ к узлу (уехал в отпуск) у него должна оставаться возможность видеть что там происходит пользуясь открытыми апи (напрямую либо через ботов)…

Навернуть расширение для себя было бы лучше, чем ломать удобные фичи.

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

subject: Re: Полуневдимые эхи
25.10.2024 13:59
Andrew Lobanov (tavern,1) => hWeoLLI4iWFdNJZB2m2v  
 
shaos> Ну это можно решить путём объединения эх в тематические группы (которые будут иметь смысл только на уровне узла и не будут задевать сам протокол) - например для временных или мелких эх может существовать тематическая группа unsorted…

Опять какие-то костыли :)

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

subject: Re: Полуневдимые эхи
25.10.2024 13:59
Andrew Lobanov (tavern,1) => jd7jrs6eWWHVHB7Uiza2  
 
shaos>> Объясню - по мне так должна быть возможность программно вытянуть весь контент узла любому кто не есть админ узла (причём через веб можно возможности и поурезать т.к. вебом не только люди пользуются), а со скрытыми эхами такой возможности нет.
revoltech> Так, может, лучше тогда автоматизировать их добавление в list.txt, то есть сделать их НЕ скрытыми, вместо урезания полезной фичи?

Вот. Товарищ дело говорит!

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

subject: Re: Полуневдимые эхи
25.10.2024 13:59
Andrew Lobanov (tavern,1) => QB5IzBQrBHbyqbT6d5UK  
 
shaos> При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

Божечки! Уже и карма. Куда катецо федо!

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

subject: Re: Полуневдимые эхи
25.10.2024 13:59
Andrew Lobanov (tavern,1) => pQftmi2ZxgC5f8BneYXN  
 
shaos> Ну это издевательство над здравым смыслом когда одной рукой вы разрешаете декларировать поддерживаемые фичи через features, а другой запрещаете эти фичи расширять…

Я ничего никому не запрещаю и не разрешаю. Просто считаю отламывание фундаментальных фич вредительством.

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

subject: Re: Полуневдимые эхи
25.10.2024 13:59
Andrew Lobanov (tavern,1) => 47WbOWWFZL5IUuqXHVkQ  
 
shaos>> Это да :)
revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов по 12 айдишников из-за ограничений хттпшного гета на сервере, а чем-то более вменяемым? Или нет? В доках ничего, кроме GET /u/m, по этому поводу не нарыл.

Потому что только GET и есть.

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

subject: Re: Полуневдимые эхи
25.10.2024 13:59
Andrew Lobanov (tavern,1) => FkvDFVK566lgIFEfnspG  
 
iiii> Я не понимаю, как это работает, я не знаю как запросить последние n сообщений и я не понимаю, зачем мне запрашивать кусок эхи не до конца, а посредине. Количество сообщений я считаю ненадёжным источником, можно удалить 1 и жобавить 1 и эха вроде не изменится. , в отличие от хэша. Я вообще при делании срезов не понимаю, что входит а что не входит. Поэтому у меня на станции нет постраничного вывода :)

====
/u/e/idec.talks/-100:100
====

заберёт последние 100 сообщений.

iiii> А lim совместим со всем, хоть с ii txt 0.1, меняется только строка в конфиге.

При этом будет работать и /lim/200/u/m и /lim/200/u/point?

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

subject: Re: Полуневдимые эхи
25.10.2024 14:20
Andrew Lobanov (tavern,1) => w1w2MvlGnXkxv7LAbAyC  
 
hugeping>> А слайсы решают проблему больших индексов.
revoltech> Слайсы на сервере позволяют пропустить сообщения, только если действительно не гонять их каждые пять минут. А это действительно увеличит трафик и без того.

Только если узел, внезапно, пишет в середину индекса, а не только в конец.

revoltech> Мой юзкейс — зашёл утром, запустил tiifetch.tcl или нажал на кнопочку Fetch all echos в tiix, клиент докачает изменения всех эх за ночь и в течение дня дофетчиваю только новое содержимое конкретно интересующих эх, вручную жмякая на Fetch this echo при необходимости. За это время в них может собраться куда больше 100 сообщений, и в случае слайсинга ещё на серверной части до клиента они уже не дойдут никогда.

Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?

revoltech> Поэтому придерживаться базового протокола мне пока кажется более разумным, только вот с выгребанием по /u/m надо что-то решать. 12 айдишников на запрос — слишком мало, а многопоточность всё равно не решает проблему с кучей TCP-соединений и HTTP-метаданных.

У тебя соединения платные или что?

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

subject: Re: Полуневдимые эхи
25.10.2024 14:12
ahamai (blackcat, 2) => YxUZjS9AQM0DYR2qipzS  
 
я не понимаю, зачем. если что-то где-то сглючит, качать придётся всё заново. поэтому и сделали разбивку на мелкие секции, скачал/записал, скачал/записал. но попробуй, я понятия не имею.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 14:20
Andrew Lobanov (tavern,1) => cLd6zJShbslmqzDuXRW9  
 
shaos> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение:

Потому что это не решает никаких реальных проблем на самом деле. Можно, и было бы даже красиво, отказаться от HTTP, гонять всё через сокеты прямо и вот это вот всё. Отказаться от мелких пакетов и гонять сразу многомегабайтные бандлы. Добавить аватарки, карму, модераторство и бэкдоры для товарища майора. Только зачем?

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

subject: Re: Полуневдимые эхи
25.10.2024 14:20
Andrew Lobanov (tavern,1) => eQvqj5jfN7G6lRd0vRrt  
 
>> если IDEC уже имеет все средства как часть стандарта, то зачем для него городить кастомные гейты?..
ahamai> Без гейта ты нормально не отобразишь ничего ни на zx spectrum ни на msdos, ни на atari st. Сначала научи их utf8 :)

Тоже мне бином Ньютона, utf8 оттранслировать.

ahamai> Хочется хоть одно реальное применение слайсов, кроме "забрать последние сообщения"

Например, пагинация индекса в условиях малого объёма оперативной памяти.

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

subject: Re: Полуневдимые эхи
25.10.2024 14:20
Andrew Lobanov (tavern,1) => 4KgeB013AkJL02bQKBtC  
 
shaos>> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение
revoltech> И там AL написал, что POST /u/m не решает ни одной проблемы. Как же не решает, если решает? Вот вам проблема: куча лишних соединений и метаданных, т.к. владельцы станций ограничивают длину GET-запросов, либо сознательно, либо оставляя дефолт на веб-сервере. С POST запрос будет всегда одним в идеале.

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

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

subject: Re: Полуневдимые эхи
25.10.2024 14:20
Andrew Lobanov (tavern,1) => Noq1smMikVpR41kRGZrU  
 
ahamai>> Сегментирование запросов было введено специально.
revoltech> Чтобы создать новым поинтам затруднения с первым выкачиванием эх (а-ля блокчейн монеро)?

Новый поинт нажал кнопку "скачать" и скачал. Какие у него могут быть проблемы с первым выкачиванием эх? Или это у старлинка платное открытие нового соединения?

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

subject: Re: Полуневдимые эхи
25.10.2024 14:46
revoltech (spnet, 4) => iGflWA2ge7c86lvaWPCJ  
 
AL> Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?

Наверное, мы о разных вещах говорим.

1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
2. За ночь в эхе появляется 103 сообщения.
3. Фетчер по server-side слайсу качает 100 последних сообщений утром.

Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

AL> У тебя соединения платные или что?

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

subject: Re: Полуневдимые эхи
25.10.2024 14:55
hugeping (ping,1) => tT8kgfglr4CcyJzBAong  
 
revoltech> 1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
revoltech> 2. За ночь в эхе появляется 103 сообщения.
revoltech> 3. Фетчер по server-side слайсу качает 100 последних сообщений утром.
revoltech> Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

Я тебе советовал посмотреть как написан фетчер в ii-go. У тебя есть своё понимание, но оно не соответствует тому, как работает адаптивный фетч. Сил объяснять у меня нет. Скажу только, что забор индексов идёт "бинарно" (по одному id) начиная с 1 (2, 4, 8, 16, ...) пока не обнаружим те сообщения, которых у нас нет и тогда мы их все забираем. Ну или если мы дошли до какого-то лимита-ограничения, тогда переходим к старой схеме - забрать все.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 15:13
revoltech (spnet, 4) => iGflWA2ge7c86lvaWPCJ  
 
AL> Только если узел, внезапно, пишет в середину индекса, а не только в конец.

В общем, я понял, какой алгоритм до меня пытаются донести:

1. Делаем GET /x/features, чтобы проверить на предмет x/c и u/e. Если они имеются, то выполняем следующие пункты, если нет, скачиваем все айдишники через GET /u/e/имя.эхи и слайсим только на клиенте.
2. Делаем GET /x/c/имя.эхи, чтобы сравнить количество сообщений с локальным. Пишем разницу между полученным и локальным в diff.
3. Потом делаем GET /u/e/имя.эхи/-diff:diff и получаем список новых айдишников.

Так, что ли?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 15:53
hugeping (ping,1) => BpI3kuAlAq5Kw9QLzWkR  
 
AL>> Только если узел, внезапно, пишет в середину индекса, а не только в конец.
revoltech> В общем, я понял, какой алгоритм до меня пытаются донести:

Алгоритм ii-go:

1) если есть поддержка слайсов то используем её. иначе - полный синк
2) n = 1
3) берем /u/e/эха/-n:1
4) это сообщение есть в базе? да - не нужен синк (goto 7)
5) n = n * 2
6) идём на 3
7) забираем сообщения от -n:n

Возможны гонки, например когда сообщение успеет добавиться (в конец) пока мы забираем текущее. Но на следующем fetch мы должны будем это заметить.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:00
hugeping (ping,1) => qTsdxMdcGanQeCmsUs7p  
 
hugeping> 2) n = 1

Да, только вот этот шаг настраивается. То-есть там не 1 в реальности, а параметр limit. У меня это что то-вроде 15.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:26
revoltech (spnet, 4) => qTsdxMdcGanQeCmsUs7p  
 
hugeping> Алгоритм ii-go:
hugeping>
hugeping> 1) если есть поддержка слайсов то используем её. иначе - полный синк
hugeping> 2) n = 1
hugeping> 3) берем /u/e/эха/-n:1
hugeping> 4) это сообщение есть в базе? да - не нужен синк (goto 7)
hugeping> 5) n = n * 2
hugeping> 6) идём на 3
hugeping> 7) забираем сообщения от -n:n

А зачем так сложно? Если нода умеет слайсы, то она, по идее, умеет и /x/c, который неубываемый. Тогда мы, сравнивая с количеством уже скачанных локально сообщений, знаем, сколько надо ещё запросить.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:32
revoltech (spnet, 4) => qTsdxMdcGanQeCmsUs7p  
 
hugeping> Алгоритм ii-go:
hugeping>
hugeping> 1) если есть поддержка слайсов то используем её. иначе - полный синк
hugeping> 2) n = 1
hugeping> 3) берем /u/e/эха/-n:1
hugeping> 4) это сообщение есть в базе? да - не нужен синк (goto 7)
hugeping> 5) n = n * 2
hugeping> 6) идём на 3
hugeping> 7) забираем сообщения от -n:n
hugeping>

А почему бы просто не сравнить результат /x/c с тем количеством, что уже локально скачано?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:53
shaos (spnet, 2) => oB0fthd2AmBEdTdPftAs  
 
Номер может остаться тот же когда скажем добавили 1 сообщение, но в то же время заблеклистили 1 из середины - поэтому идея с хешами списков хешей мне кажется более работоспособной
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:57
shaos (spnet, 2) => O6QqXlnY9BZVpBUS4vS4  
 
Количество в общем случае не показатель - сообщения могут не только добавляться, но и удаляться
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:48
hugeping (ping,1) => O6QqXlnY9BZVpBUS4vS4  
 
revoltech> А почему бы просто не сравнить результат /x/c с тем количеством, что уже локально скачано?

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

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 16:50
hugeping (ping,1) => ANSxKPlJX4E2nYSrXQJ9  
 
hugeping> Ну и другие ситуации, которые можно придумать. А хеши - надёжно.

Чуть лучше, хранить счётчик на диске для конкретной станции - свой счётчик. Но тоже ненадёжно.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:05
revoltech (spnet, 4) => dCQnBc3TU0XMbLc4Rf0P  
 
shaos> Количество в общем случае не показатель - сообщения могут не только добавляться, но и удаляться

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

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

subject: Re: Полуневдимые эхи
25.10.2024 17:10
shaos (spnet, 2) => gEsO5nk3AhbXQA8bpQzk  
 
> На этот счёт спецификация явно говорит, что счётчик может только увеличиваться.

Но на практике у всех разные номера для тех же самых эх...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:21
revoltech (spnet, 4) => ANSxKPlJX4E2nYSrXQJ9  
 
hugeping> Потому что в разных нодах могут быть особенности. Например блеклист - учитывается или нет в счётчиках? Нода может не хранить все сообщения, а только часть (последние 10000).

Если верить документации с гитхаба idec-net, то всё это не должно уменьшать счётчик. Сообщение добавилось — инкрементировали. Сообщение удалилось — счётчик не трогаем.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:22
shaos (spnet, 2) => knVHGTYBADFb7ijPL80h  
 
> Но вред файлэх в чём?

1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать
2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?
3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:24
shaos (spnet, 2) => JlBBQwkwmOLXBPrvYisN  
 
Сообщение можно не только заблеклистить, но и удалить
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:28
revoltech (spnet, 4) => vkA1lkXVgohBUd9J9U6V  
 
shaos> Сообщение можно не только заблеклистить, но и удалить

Да пожалуйста, но счётчик при этом трогаться не должен.

Из https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Важно: параметр неубывающий. Если в эхе удалили сообщения, то возвращаемое число не должно уменьшаться.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:37
shaos (spnet, 2) => Z4xUDkexfcJP2o7aMmV1  
 
в ii-php уменьшается

технически это немножко сложно его неуменьшать

это если хранить по простому в файлах

а если в SQL то там можно просто max(index) выдавать и он всегда будет расти (но фактически сообщений будет меньше)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:49
revoltech (spnet, 4) => ZqsaqQxiMlGMEMhLwXmE  
 
shaos> в ii-php уменьшается

Ну, это печально. Получается, спецификации оно не соблюдает. Соответственно, в клиентах вся завязанная на счётчики логика тоже идёт лесом.

Придётся и у себя откатить. Или перепилить на нечто подобное алгоритму из ii-go, посчитав накладные расходы.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:55
shaos (spnet, 2) => cLd6zJShbslmqzDuXRW9  
 
Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 17:58
shaos (spnet, 2) => ZqsaqQxiMlGMEMhLwXmE  
 
хотя не - max(index) не будет работать т.к. индекс общий на все эхи
видимо надо запрещать удалять сообщения физически...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:00
hugeping (ping,1) => Ho2oXFE6W3gKgFicgSef  
 
shaos>> в ii-php уменьшается

revoltech> Ну, это печально. Получается, спецификации оно не соблюдает. Соответственно, в клиентах вся завязанная на счётчики логика тоже идёт лесом.

У меня тоже, наверное, не соблюдается в полной мере. И когда делал свою реализацию понял, что затачиваться на счётчики - потенциальная стрельба в ногу. К сожалению. На мой взгляд пример непродуманного элемента стандарта. Например, упал винт и ставишь всё заново. Откуда брать счётчик? Если у нас все базы данных зеркальные копии - то, вероятно, можно взять его у "соседа". Но рассинхронизация этих счётчиков между узлами с одинаковой эхой может произойти очень легко. К тому же, та другая нода скорее всего хранит последнее состояние моего счётчик у себя для проверки изменений при фетче. Короче, малейшие отличия в реализации и всё... А счётчик оказывается и не счётчиком сообщений и не счётчиком изменений...

Но! Главная мысль в другом. Даже если бы эта штука работала у всех одинаково и хорошо, она не решает ничего. Она просто позволяет сказать - стоит ли делать фетч или нет. Эту же вещь дают и слайсы, но надёжным способом. Важнее другая фича. А именно - да, нужно фетчить но фетчить не всё. Потому что в обычной ситуации в эхе всегда будут новые сообщения. Эту проблему тоже решают слайсы но только в режиме адаптивного фетча. Мне кажется адаптивный фетч - это вообще мое изобретение к которому я пришёл вынужденно. Все другие способы имели свои проблемы и нюансы. Но вот это "двоичное" сканирование истории - даёт хороший результат. Но.... сложно!

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

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:03
hugeping (ping,1) => O6IMrmM85toO3SAaUeIj  
 
shaos> хотя не - max(index) не будет работать т.к. индекс общий на все эхи
shaos> видимо надо запрещать удалять сообщения физически...

Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы. Тогда ничего не надо городить и счётчик - полное число сообщений эхи, включая блеклист. Вот меня тоже давно грызёт мысль что нужно что-то упрощать. Но я боюсь что то менять. :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:09
doesnm (ping,55) => pfB3MopPQ4BYtmOJ1mTE  
 
shaos>> хотя не - max(index) не будет работать т.к. индекс общий на все эхи
shaos>> видимо надо запрещать удалять сообщения физически...
hugeping> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы. Тогда ничего не надо городить и счётчик - полное число сообщений эхи, включая блеклист. Вот меня тоже давно грызёт мысль что нужно что-то упрощать. Но я боюсь что то менять. :)

Работает - не трогай?

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

subject: Re: Полуневдимые эхи
25.10.2024 18:17
hugeping (ping,1) => DEyAN5grKULhNMSazoT1  
 
doesnm> Работает - не трогай?

Тут скорее боязнь конфликтов и войны "стандартов". Всё-таки, стандартны - вторичны. Первичны - люди. Так то, по мне, нужен откат к идеям ii но с опытом полученным в idec.

И центральный вопрос, конечно, это стандартизованный способ фетча, без необходимости полного сливания индексов и без адаптивного фетча. Но для того чтобы начать думать, предлагать решения и обсуждать их -- нужно желание и осознание "проблемы". А я не уверен, что это случилось. В целом, меня устраивает как всё работает. :)

Ну и не всё так однозначно. Например, нужны слайсы или нет, если проблема фетча будет решена без них? Я бы сказал - не нужны! Но ведь действительно, бездисковый клиент мог бы пользоваться слайсами для "браузинга" сообщений! Так что рубить с плеча не стоит.
P.S. Edited: 2024-10-25 16:18:07

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:32
hugeping (ping,1) => YUlVA5jnMgPHZ5WE4Ote  
 
Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

2) Вариант с хешом эхи как индикатором изменений - не решает проблему забирать не всё, а только часть. Да и предполагает хранить на диске или в базе последний хеш;

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

4) Вариант возвращать список id в обратном порядке. Идея в том что если я получаю список в обратном порядке я могу закрыть соединение в тот момент когда мне уже больше не надо. :) Но, как-то на хак похоже. А как вам? Не знаю... Нет красоты.

Получается, ничего проще слайсов и не сделать? :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:34
hugeping (ping,1) => fNjAY152bfO3xjrcvLAH  
 
hugeping> Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

hugeping> 1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

Хотя, сработает. Если брать с разумным "запасом" на самом деле... Правда опять вопросы с блеклистами и удалениями могут быть.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 19:12
Andrew Lobanov (tavern,1) => zsnW8Ac3wePhYQ6etgur  
 
shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

Это было в ii.

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

subject: Re: Полуневдимые эхи
25.10.2024 19:26
Andrew Lobanov (tavern,1) => tT8kgfglr4CcyJzBAong  
 
AL>> Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?
revoltech> Наверное, мы о разных вещах говорим.
revoltech> 1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
revoltech> 2. За ночь в эхе появляется 103 сообщения.
revoltech> 3. Фетчер по server-side слайсу качает 100 последних сообщений утром.
revoltech> Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

Зачем брать сто, а не то, чего у тебя нет?

AL>> У тебя соединения платные или что?
revoltech> У меня идеология не тратить вычислительные ресурсы там, где их можно не тратить. Пермакомпьютинг так называемый.

Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

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

subject: Re: Полуневдимые эхи
25.10.2024 19:26
Andrew Lobanov (tavern,1) => vO6MWJXd4qZSRHtTmCuK  
 
>> Но вред файлэх в чём?
shaos> 1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать

Постоянно работаю с файлами в терминале.

shaos> 2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?

Транспорт может быть любым.

shaos> 3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

Не подписывайся. Вопрос был концептуальный, а не по конкретным фехам.

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

subject: Re: Полуневдимые эхи
25.10.2024 19:55
revoltech (spnet, 4) => EYA51RAaqhF7eoxP12Xg  
 
AL> Это было в ii.

А почему документация описывает это как IDEC-расширение?

AL> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 20:10
shaos (spnet, 2) => ZXh7UkdnjGvvcABpXuWD  
 
> Это было в ii.

А почему тогда list.txt и blacklist.txt перечисляется в /x/features?
====
curl -XGET http://idec.spline-online.ru/x/features
u/e
list.txt
blacklist.txt
x/file
x/small-echolist
x/caesium
x/c
====
О - кстати, а что такое x/small-echolist?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 14:37
ahamai (blackcat, 2) => vQTtqxAZL08BAAxZsXGn  
 
> При этом будет работать и /lim/200/u/m и /lim/200/u/point?

да, естественно, просто url сдвигается. lim, в отличие от хэшей, я использовал реально в конфигах клиентов. хотя щас у меня две ветки, 0.6 на фандейшне (активная) и 0.7 на пикнике (недоделанная), и я не перенёс эту фичу с 0.7 в 0.6, надо будет не забыть
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 14:40
ahamai (blackcat, 2) => ChsQAHHzwSCldnRTpiYE  
 
> Вот. Товарищ дело говорит!

те или иные варианты discover, типа автодобавления, вроде были всегда, у меня вроде и серверы и клиенты с такой фичей были.

но тогда, если останется автосоздание эх другими, в интерфейсе будет бардак. можно просто принять какой-нибудь протокол типа /x/discover, который будет делать элементарное os.listdir('e'), у меня сейчас так gemini-сайт работает.

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

subject: Re: Полуневдимые эхи
25.10.2024 15:28
ahamai (blackcat, 2) => BpI3kuAlAq5Kw9QLzWkR  
 
Капец там запросов, оверхед.

x/features вообще должна кешироваться, сервер не меняет серверное по каждый день, чтобы это постоянно запрашивать

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

subject: Re: Полуневдимые эхи
25.10.2024 15:59
ahamai (blackcat, 2) => qTsdxMdcGanQeCmsUs7p  
 
Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела). Почему не делать шаги типа 1, 16, ещё чёнить, всё, то есть более частые юзкейсы. или даже сразу начинать с 16. запрос вообще вещь дорогая, и их лучше минимизировать
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:23
ahamai (blackcat, 2) => kWcgW1NZH0mM32yINI24  
 
> Конечно, сейчас хочется сказать - а давайте вернёмся и придумаем что-то более простое и надёжное и сделаем что-то среднее между ii и idec... Но боюсь, лишние потрясения нам не к чему.

если shaos введёт ?h=1, то я при его запросах буду действовать по следующей стратегии, сначала смотреть хэши эх, потом дёргать изменившиеся, полностью, крохоборить и выбирать кусочки списков я не буду. думаю, это сократит трафик. потребует минимальных изменений фетчера. и сама фича в моей ноде есть сто лет в обед, только никогда не использовалась.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 18:24
ahamai (blackcat, 2) => pfB3MopPQ4BYtmOJ1mTE  
 
> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы.

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

subject: Re: Полуневдимые эхи
25.10.2024 18:26
ahamai (blackcat, 2) => TIzq6TPXBFMK7D4R643y  
 
> Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...

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

subject: Re: Полуневдимые эхи
25.10.2024 18:34
ahamai (blackcat, 2) => NXYQkMwMmlcjH2tVK85P  
 
у меня фетчер, оказывается, вообще без поддержки blacklist :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 20:21
ahamai (blackcat, 2) => jNCPgIuLDsfL1aNAjQfG  
 
u/e тут тоже есть :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 20:47
hugeping (ping,1) => XDk3eFfMSyAjdZYgwaHf  
 
ahamai> Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела).

Напиши конкретный алгоритм, я не понял твоё предложение.
Начинаю я с -16:1 - я там выше написал что лимит это параметр. В описании алгоритма я для понятности задал его в 1, но в быту мы начинаем не с 1. И обычно, если сообщений < 16 новых это единственный запрос. Если нет, будет -32:1, потом -64:1....


--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 21:26
shaos (spnet, 2) => NXYQkMwMmlcjH2tVK85P  
 
Мне нравится идея, что у каждого свой суверенный блеклист :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 21:14
ahamai (blackcat, 2) => 87tzFwvkAWEuPuPZerFj  
 
ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 21:33
ahamai (blackcat, 2) => IAiRGxSeJm12AudcOMBc  
 
> Мне нравится идея, что у каждого свой суверенный блеклист :)

ну сейчас - да, и в принципе это норм
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
25.10.2024 23:06
Andrew Lobanov (tavern,1) => R89fbL1Ht1Z8xjJKEGyA  
 
AL>> Это было в ii.
revoltech> А почему документация описывает это как IDEC-расширение?

Потому что документация описывает IDEC.

AL>> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?
revoltech> К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

Слишком много оверхеда.

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

subject: Re: Полуневдимые эхи
26.10.2024 08:48
revoltech (spnet, 4) => GuQtx2mX7tnRY3dpgDtU  
 
AL> Потому что документация описывает IDEC.

Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.

И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

AL> Слишком много оверхеда.

Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 09:03
revoltech (spnet, 4) => J27tU3T3W2jGFQLz7aDl  
 
ahamai> ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

Сделал у себя с шагом кратности 12 (потом 24, 48 и т.д.), чтобы в самом распространённом случае можно было даже с tgi и подобных за один запрос стянуть.

ahamai> стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

Ну в том алгоритме главная идея состоит в экономии трафика, полагаю. Сначала пробный запрос с -16:1, а потом, если в базе есть сообщение, то можно и -16:16.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 12:39
tuple (ping,54) => I5hIe1yhsQYUqm6TiHyw  
 
revoltech> жирный HTTP

Почему жирный-то? Почти натуральный plaintext. Куда меньше?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 14:06
revoltech (tgi,15) => qAiKYTp1DhhepJlCT0I4  
 
tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

Ничего, кроме нетката, телнета или подобного, в основе не требуется.

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

P.S. Что-то не смог запостить на sprinternet, переслал на tgi.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 14:09
revoltech (spnet, 4) => qAiKYTp1DhhepJlCT0I4  
 
tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

Ничего, кроме нетката, телнета или подобного, в основе не требуется.

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 14:46
shaos (spnet, 2) => qAiKYTp1DhhepJlCT0I4  
 
Меньше это Gopher или Nex овер телнет :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 14:56
revoltech (spnet, 4) => sU4DKwuTPNRJ7ogWfGr6  
 
shaos> Меньше это Gopher или Nex овер телнет :)

Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 17:35
doesnm (ping,55) => GpJfTKAeVn4jLKxCkzSu  
 
shaos>> Меньше это Gopher или Nex овер телнет :)
revoltech> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...

Го дропнем base64

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

subject: Re: Полуневдимые эхи
26.10.2024 17:46
ahamai (blackcat, 2) => k2ZkiFXdGm71nnrkKzkP  
 
> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

остаётся вопрос в том, как узнать, докачалось ли всё или оборвалось. всё равно нужен con-len или какие-то флаги. кстати я изначально хотел добавить, чтобы любой бандл начинался и заканчивался конкретным тегом, чтобы проверять валидность бандла. но банально забыл. но вроде с http ничё так получилось, от этого не страдаем. а новой технологии придётся показывать себя на практике - ждём реализации :)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 18:19
revoltech (spnet, 4) => t0cAH8h0d554MosgcAdA  
 
doesnm> Го дропнем base64

Для /u/m не получится без глубинного перелопачивания самого формата бандла, а вот для /u/point, в принципе, легко.

Кто-нибудь скажет, какие проблемы решает base64 именно при постинге, каких не решает тот же самый x-www-form-urlencoded, в который сообщение по итогу всё равно заворачивается?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 18:30
revoltech (spnet, 4) => P2Ra1N6bsWpnsuFOpctU  
 
ahamai> остаётся вопрос в том, как узнать, докачалось ли всё или оборвалось.

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

Для эх: сравнить количество айдишников с тем, которое мы запрашиваем, и удостовериться в том, что все скачанные айдишники имеют 20 символов.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 18:27
ahamai (blackcat, 2) => dsUaUR0Cm96g9PlHu68M  
 
> Кто-нибудь скажет, какие проблемы решает base64 именно при постинге, каких не решает тот же самый x-www-form-urlencoded, в который сообщение по итогу всё равно заворачивается?

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

subject: Re: Полуневдимые эхи
26.10.2024 18:46
ahamai (blackcat, 2) => gIQZO1bqzNJzlH7q3G6r  
 
> Для сообщений: посчитать хэш, преобразовать в айдишник по алгоритму и сравнить с тем айдишником, который в начале строки в бандле.
> Для эх: сравнить количество айдишников с тем, которое мы запрашиваем, и удостовериться в том, что все скачанные айдишники имеют 20 символов.

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

subject: Re: Полуневдимые эхи
26.10.2024 20:16
revoltech (spnet, 4) => 2sTZ8UrJR16maEJ6gLdc  
 
ahamai> ну тогда это оверхед в коде. когда я делал, сравнить мне было не с чем, просто сделал на ровном месте, но по http оно работает ровно так, как было сделано в первой версии (хотя я много что забыл, но всё равно как-то работает). поэтому мой вариант естественно не оптимален и не идеален, и если кто-то сделает гораздо красивее, я с радостью перейду на этот формат.

Ну вот, кстати, я начал просто отслеживать хэши сообщений вместе с айдишниками, и после перефетча (со всего, кроме spline-online) из 17614 сообщений 14067 оказались с корректными айдишниками (сравнивал по функции LOWER() в базе, так что нюансы с A-z не важны), а вот 3547 сообщений имеют айдишники, которые вообще описанному в доках хэшу не соответствуют. Вопрос: был/имеется ещё какой-то алгоритм хэширования или что за фигня там происходит? А потом коллизиям удивляются.

Статистика сообщений с левыми ID по эхам (не считая spline):

sqlite> SELECT DISTINCT `echoname`, COUNT(`id`) FROM `msg` WHERE LOWER(`msgid`) != LOWER(`content_id`) GROUP BY `echoname`;
blcat.local|1
develop.16|17
game.rogue.14|39
idec.talks|322
idec.test|13
ii.stat|7
linux.14|341
lit.14|4
lor-opennet.17|1
lor.gold|31
music.14|34
ping.local|4
pipe.2032|1123
plan.9|2
python.15|8
retro.talks|27
ru.humor.14|35
spnet.stats|1
std.club|1241
std.favorites|2
std.game|139
std.hugeping|68
std.hugeping.micro|2
std.prog|36
std.rein|1
std.tech|47
zx.spectrum|1
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 22:53
shaos (spnet, 2) => HQNRufP8SjoxJlRv2OzL  
 
Я три недели назад уже всё посчитал ii://TfXUY2nZ1vmjAsQhgfsK

Многие узлы допускают редактирование сообщений без изменения хеша и возможно какие-то изначально неправильно хеш реализовывали (т.к. в спеке небыло эталонных сообщений для сверки как это обычно принято) и потом некоторые ботоэхи с какого-то момента стали сломанные: ii://6kCluOlO0AG8aOvgvRPr

Основные stakeholders (текущий мейнтейнер стандарта с одной стороны и первоначальный создатель с другой) в один голос говорят, что сам алгоритм не важен - главное чтобы msgid был уникальным, поэтому я и отпочковал от ii/IDEC свой strengthened вариант iii т.к. мне для будущих экспериментов важно, чтобы хэш сходился всегда :)

ii://iii.nizya

А вообще было бы сильно прикольнее, если бы история хеширования в ii пошла по другому пути ;)

ii://vTYmGKHeCyvLZ3BV2NoP

Потому что как оказалось сам Создатель упоминал такой способ в комментах на лоре на этапе создания технологии ;)

[линк с пруфом пока не могут отыскать]
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 22:57
shaos (spnet, 2) => t0cAH8h0d554MosgcAdA  
 
не - base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 22:58
shaos (spnet, 2) => P2Ra1N6bsWpnsuFOpctU  
 
ну оборвалось и оборвалось - в следующий раз дозаберётся, не?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
26.10.2024 22:59
shaos (spnet, 2) => dsUaUR0Cm96g9PlHu68M  
 
Я для себя хочу попробовать новый вызов /u/n с ascii85+ вместо base64 - будет покомпактнее чуток
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 00:34
ahamai (blackcat, 2) => HQNRufP8SjoxJlRv2OzL  
 
> вот 3547 сообщений имеют айдишники, которые вообще описанному в доках хэшу не соответствуют. Вопрос: был/имеется ещё какой-то алгоритм хэширования или что за фигня там происходит? А потом коллизиям удивляются.

во всяких босфорах и улиссах длина хэша была где 8, где 12 символов, поэтому для гейтования в ii до 20 добавлялось что-то типа "bosforbosfor" (а в гейтованых месагах вроде где-то полный хэш был, не помню уже, как это всё между сетями летало, но летало успешно.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 00:35
ahamai (blackcat, 2) => VzAIz4SzKzb4mOtvwUkE  
 
как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то. хотя, конечно, сейчас просто упадёт декодер с base64 из-за неккоректного ююка, но теоретически может и нет. я не знаю, я просто размышляю.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 00:46
ahamai (blackcat, 2) => zrKOsHiS7bZQqUFgxjzo  
 
вообще, в отношениях станция-станция не важно, как они обмениваются - можно хоть в общий git сливать, а индекс эхи перегенирировать по timestamp, это всё равно будет "обмен в духе ii", разве что вклинивающиеся старые сообщения не так ii-шно, но в принципе так можно.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 06:48
shaos (spnet, 2) => F8qxdxiRjdKEJ6uph5nJ  
 
О - нашёл!!!

https://www.linux.org.ru/forum/talks/10258332?cid=10258568

> return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-',").replace('_',")[:20]
> мощно я задвинул? внушает? :)
> feofil (06.03.14 09:41:46 PST) автор топика

Мне интересно в какой момент в реплейсах появились 'A' и 'z'? ;)

Если верить гиту, то 1 апреля 2014 года (в момент создания репы):

a45cdfa3 (user 2014-04-01 19:19:03 +1100 16) def hsh(s):
a45cdfa3 (user 2014-04-01 19:19:03 +1100 17) return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-','A').replace('_','z')[:20]

Но я знаю, что первый релиз ii был в начале мерта 2014 года...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 06:52
shaos (spnet, 2) => UtYlIUg5dba68YU1jpmu  
 
в старой "болталке с девочками" hc.51 почти все хеши вида 7lwguohJulissiiuliss и mPJSJAI3ulissiiuliss а в других местах видимо просто отредактированные сообщения без изменения msgid...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 06:55
shaos (spnet, 2) => xxG7VesobAdvGy9WO4IY  
 
вот поэтому и нужны железобетонные хеши в качестве msgid - если хеш не сошёлся, то мессага битая или подменянная - т.е. одновременно проверяем и целостоность данных, и подлинность, причём не добавляя никаких лишних сущностей!
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 07:32
revoltech (spnet, 4) => F8qxdxiRjdKEJ6uph5nJ  
 
shaos> Многие узлы допускают редактирование сообщений без изменения хеша

Что есть маразм by design. Хэш — он на то и хэш, чтобы отражать изменения в содержимом, иначе на... зачем он нужен?

shaos> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)

Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

В почте это сделано просто ради кучи легаси-софта из 1980-х, а первая версия ii появилась в 2014 году, когда весь нормальный мир давно перешёл на UTF-8. Для реальных семибитных каналов есть вполне себе другие решения, которые любой восьмибитный трафик через себя туннелируют. Но для 99% населения, умеющего и желающего общаться только по TCP/IP, это реальный оверхед.

И да, ранее описанный подход мог бы применяться и к POST /u/point:

POST /u/point
Content-Type: text/plain; charset=utf-8

[auth_str]
[message]
.

shaos> Я для себя хочу попробовать новый вызов /u/n с ascii85+ вместо base64 - будет покомпактнее чуток

Вот это уж точно не упростит жизнь никому. Всем придётся пилить свою реализацию этого.

shaos> > мощно я задвинул? внушает? :)

Спасибо, с изначальным подходом к проектированию ii всё ясно.

shaos> в старой "болталке с девочками" hc.51 почти все хеши вида 7lwguohJulissiiuliss и mPJSJAI3ulissiiuliss а в других местах видимо просто отредактированные сообщения без изменения msgid...

И с реализациями тоже.

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

Полностью согласен.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 07:48
shaos (spnet, 2) => 193D2sN60V8V75pfXogE  
 
Если хочешь ознакомиться с процессом проектирования и реализации ii в более широком смысле, то можно прочитать следующие статьи на лоре (и комментарии к ним):

- https://www.linux.org.ru/forum/general/10247460
- https://www.linux.org.ru/forum/talks/10258332
- https://www.linux.org.ru/forum/talks/10267735
- https://www.linux.org.ru/news/opensource/10319264
- https://www.linux.org.ru/news/opensource/10534550
- https://www.linux.org.ru/forum/general/10532800

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

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

subject: Re: Полуневдимые эхи
27.10.2024 07:59
revoltech (spnet, 4) => xxG7VesobAdvGy9WO4IY  
 
ahamai> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то

В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 08:15
shaos (spnet, 2) => 193D2sN60V8V75pfXogE  
 
> Что есть маразм by design. Хэш — он на то и хэш

с одной стороны редактирование мессаджей это местная самодеятельность (типа ой, я тут запятую забыл поставить, дай ка побырому исправлю пока мессага не зафетчилась другими узлами) т.е. by design таки подразумевалось, что мессаги не редактируются

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

P.S. хеш с подменой двух небуквоциферных символов в хеше на A и z по идее можно и оставить как рудимент прошлого т.к. оно даёт возможность по статистическому анализу букв используемых среди N хешей со 100% уверенностью сказать, что они пришли из ii/IDEC-сетей ;)

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 08:28
revoltech (spnet, 4) => htwiRzmp434HPoWm5KBU  
 
В сухом остатке _на данный момент_ имеем следующее:

* айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
* длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
* на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 08:53
shaos (spnet, 2) => BG1YzQwaizkvDAFNFtvg  
 
> айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);

ну почему не может? может

просто на новых узлах можно завести специальный атрибут у некоторых эх типа принимать только валидные сообщения ( там где это будет действительно нужно - типа idec.coin ; )

а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...

--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 09:28
shaos (spnet, 2) => BG1YzQwaizkvDAFNFtvg  
 
> длина файла с айдишниками эхи не настолько велика

не будем забывать про слабые ретроплатформы где память 64КБ и меньше

например список хешей lor-openned.17 весит 299КБ и они точно не влезут в память ретрокомпьютера целиком

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

subject: Re: Полуневдимые эхи
27.10.2024 10:52
revoltech (spnet, 4) => ySmtlAIO9ijgwFxxOEhK  
 
shaos> не будем забывать про слабые ретроплатформы где память 64КБ и меньше

А на такие платформы уже портировали Tcl 8.6, sqlite3 и прочее? Я же конкретно насчёт своего клиента/фетчера говорю. Там-то понятное дело, что другие подходы ко всему нужны.

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

Да я не против того, чтобы в стандарте они оставались.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 10:54
revoltech (spnet, 4) => kUxuXZMvANx2tPgIOvWK  
 
shaos> а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...

Ну я у себя теперь просто делаю приписку (ID hash mismatch!) рядом с айдишником у таких сообщений.
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 11:16
shaos (spnet, 2) => rR85z7Jb6rEotstE3lX8  
 
А ну если ты только про своего клиента, то ок

Главное если надумаешь делать свой узел, чтобы он умел слайсы ;)
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 12:09
Andrew Lobanov (tavern,1) => I5hIe1yhsQYUqm6TiHyw  
 
AL>> Потому что документация описывает IDEC.
revoltech> Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

И даже писал.

revoltech> Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:
>> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.
revoltech> И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

Бывает.

revoltech> То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Зачем?

revoltech> Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

Молодец.

AL>> Слишком много оверхеда.
revoltech> Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).

Ну то, как Вы позиционируете протокол, мы узнали только что. Сидим вот, думаем что дальше с этим делать.

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

subject: Re: Полуневдимые эхи
27.10.2024 12:09
Andrew Lobanov (tavern,1) => WTbH8A0kuUsdxaH602IE  
 
tuple>> Почему жирный-то? Почти натуральный plaintext. Куда меньше?
revoltech> Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.
revoltech> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900
revoltech> Ничего, кроме нетката, телнета или подобного, в основе не требуется.
revoltech> Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:
revoltech> cat <<EOF | nc station.domain 1915
revoltech> /u/point
revoltech> [auth_string]
revoltech> [base64_message]
revoltech> .
revoltech> EOF
revoltech> Вот тут уж действительно меньше некуда.

Ну так пиши транспорт какой тебе больше нравится. Стандарт не завязан на HTTP как таковой. Был опыт обмена и по FTP. Просто HTTP всех устраивает, так как дёшево и просто с точки зрения использования и уже так сложилось.

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

subject: Re: Полуневдимые эхи
27.10.2024 12:09
Andrew Lobanov (tavern,1) => t0cAH8h0d554MosgcAdA  
 
shaos>>> Меньше это Gopher или Nex овер телнет :)
revoltech>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm> Го дропнем base64

Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

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

subject: Re: Полуневдимые эхи
27.10.2024 12:10
Andrew Lobanov (tavern,1) => 193D2sN60V8V75pfXogE  
 
shaos>> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)
revoltech> Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

Мы и определились и отказались от максимализма.

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

subject: Re: Полуневдимые эхи
27.10.2024 12:10
Andrew Lobanov (tavern,1) => HIp0R0Lbw7wtik6lpKgB  
 
ahamai>> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
revoltech> В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.

Почему?
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 12:10
Andrew Lobanov (tavern,1) => BG1YzQwaizkvDAFNFtvg  
 
revoltech> * длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);

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

revoltech> * на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.

Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.

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

subject: Re: Полуневдимые эхи
27.10.2024 13:34
doesnm (ping,55) => t8bZVspZfbRu1GawzaYD  
 
shaos>>>> Меньше это Gopher или Nex овер телнет :)
revoltech>>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm>> Го дропнем base64
AL> Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

Поддерживаю

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

subject: Re: Полуневдимые эхи
27.10.2024 13:34
doesnm (ping,55) => 367LiUQAXz1NAs7CA7BM  
 
AL> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.

У моего мобильного оператора бывают такие потери что даже к ирке не подключается
об HTTP и даже IDEC речи уже не идет

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

subject: Re: Полуневдимые эхи
27.10.2024 14:33
shaos (spnet, 2) => 41Cmc27l7m1mA24W2NlA  
 
Да чо уж там - давайте распечатывать эхи на листах A4 и рассылать бумажной почтой...
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 14:22
Andrew Lobanov (tavern,1) => 41Cmc27l7m1mA24W2NlA  
 
doesnm>>> Го дропнем base64
AL>> Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.
doesnm> Поддерживаю

FTN у нас уже есть.

+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 14:50
doesnm (ping,55) => 3CCVikmos0wT8N2ocOVK  
 
AL> FTN у нас уже есть.

Сделать гейт в FTN

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

subject: Re: Полуневдимые эхи
27.10.2024 15:50
shaos (spnet, 2) => 7aROsEH4ibAxMLly0i6u  
 
Всё сделал - проверяй :)
/list.txt остался как был
/list.txt?h=1 подставляет hsh/хэш вместо дескрипшинов и имеет "алиас" /listhsh.txt
ну и /x/h/echo.1/echo.2 по аналогии с /x/c/echo.1/echo.2 сдедал, например
====
> curl https://sprinternet.io/iii/x/h/retro.talks/idec.talks
retro.talks:mWbHlTgoAaE1IaEoubCR
idec.talks:4dBW6db3TdOmYzbdZAg5
====
тут без префикса hsh/
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 15:52
shaos (spnet, 2) => gnGnZaS1sMVCHkguSCh5  
 
> ну и /x/h/echo.1/echo.2 по аналогии с /x/c/echo.1/echo.2 сдедал, например
> ====
> > curl https://sprinternet.io/iii/x/h/retro.talks/idec.talks
> retro.talks:mWbHlTgoAaE1IaEoubCR
> idec.talks:4dBW6db3TdOmYzbdZAg5
> ====

После того как предыдущее сообщение добавилось стало так :)
====
retro.talks:mWbHlTgoAaE1IaEoubCR
idec.talks:KCAVqaCJCot0ByQVlWg5
====
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
27.10.2024 19:53
Andrew Lobanov (tavern,1) => SGmPOF2mEoZHcHO7E0eG  
 
AL>> FTN у нас уже есть.
doesnm> Сделать гейт в FTN

Смысла нет :)

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

subject: Re: Полуневдимые эхи
29.10.2024 00:13
ahamai (blackcat, 2) => gnGnZaS1sMVCHkguSCh5  
 
Сделал фетчер, учитывающи
--------------------------------------------------------------------------------

subject: Re: Полуневдимые эхи
29.10.2024 00:13
ahamai (blackcat, 2) => E4pT6tHIOZIjh2resorW  
 
й x/h.
--------------------------------------------------------------------------------