revoltech> Так, ладно, раз уж диалог завязался (и спасибо за такой тёплый, хоть и, хм, своеобразный приём), выскажу наконец свои основные мысли по поводу этого всего.

Насчёт приёма, не понимаю твоих намёков. Пиши конкретней. С моей стороны выглядит примерно так:

1) Сначала прислал мне пустое письмо (я решил, что автоматика). Весь анонимизированный.
2) Не ответил на мой вежливый вопрос письмом же (где я пояснил свой интерес тем, что на станцию совершались набеги в прошлом)
3) потом создал сообщение "/?" на tgstation.ru.
4) Я снял фетч и сообщил о своих подозрениях в эхе :)
5) Потом ты послал битые сообщения.

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

revoltech> 1. Да, я — любитель спутниковых каналов связи, тора, анонимности, анархии и всего того, что у вас здесь, видимо, принято относить ко списку смертных грехов

Пиши конкретней. Не у вас, а у тебя - hugeping. :) Да, я отрицательно отношусь к такому явлению, когда открытые проекты для связи типа тех же irc, jabber, gemini итд воспринимаются лишь с точки зрения анонимности и приватности и тем самым привлекают массу контингента который создают контент, который меня не интересует. Однако, это не влияет на мою политику по отношению к участникам сети, пока они не начинают "сорить" на моей станции.

revoltech> 2. Официальная документация ii/IDEC вроде и подробна, но написана так, что некоторые вещи либо неочевидны, либо их надо додумывать самостоятельно. Например, касательно разделителя строк. На момент написания мной этого поста в доках НИГДЕ не указано, что разделитель строк в теле сообщения — строго \n. Это явно указано только для формата бандла:

Согласен. Я даже в итоге не понял как лучше это "исправить". Сейчас я режу '\r' просто.

revoltech> Ребят, валидация входящих данных — это БАЗОВЫЙ принцип безопасности.

А с этим я не спорил. В плане именно безопасности проблемы не было, проблему больше доставили сообщения с битым repto -- они создали много топиков из одного сообщения. То-есть, это что то вроде дефейсинга. Так то, спасибо за тестинг. :)

revoltech> 3. Надо бы как-то придумать, как оптимизировать фетчинг.

Посмотри как сделан фетчинг в ii-go. Он адаптивный.

revoltech> Спасибо за внимание.

Заходи, если что. :)

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

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

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

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

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

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

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

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

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

AL>> Может, вам проще взять phpbb? Зачем портить такую замечательную и простую вещь, как ii/idec?
tuple> Вот-вот, куда усложнять маленький милый ii/idec? Он хорош таким, каким он есть.

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

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

> Точно был способ в документации. Посмотрите подробней.

Да уже всё перерыл, никак не нахожу, как именно клиентом выкачать все сообщения из указанных в /u/e за один HTTP-запрос.

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

Самым очевидным решением было бы, наверное, разрешить ещё и HTTP POST /u/m с тем же синтаксисом.

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

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

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

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

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

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

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

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

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

Ну phpbb у меня есть с 2003 года :)

http://forum.nedopc.org

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

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

Да не маленький он уже…

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

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

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

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

AL> Как минимум, существовали раньше. Как искать не знаю. Живы ли они тоже не знаю.

Понял, спасибо, бум искать.

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

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

Надо будет фичу выпилить ;)

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

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

Ну это можно решить путём объединения эх в тематические группы (которые будут иметь смысл только на уровне узла и не будут задевать сам протокол) - например для временных или мелких эх может существовать тематическая группа unsorted…

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

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

При наличии групп эх наверное можно таки дать возможность пользователям (с высокой кармой?) создавать новые публичные эхи в группе unsorted - эдакий crowd sourcing получится, но по умолчанию такие эхи должны будут быть скрыты от веба (хоть и будут перечислены в list.txt)..,

tuple> Приветствуем!
>> (и спасибо за такой тёплый, хоть и, хм, своеобразный приём)
tuple> Раз уж вы любитель тора, анонимности и подобного, то должны понимать, что данные технологии привлекают не только энтузиастов, но и вредителей, которых привлекает политическая позиция держателя таверны.

Интересно было бы услышать какая у меня политическая позиция :)

+++ Caesium/0.4 RC1

shaos> Ну phpbb у меня есть с 2003 года :)
shaos> http://forum.nedopc.org
shaos> И оно сугубо централизованное, а мне нужно распределённое и многоузловое….
shaos> И потом не надо культивировать мнение, что IDEC такойr простой - он уже не такой простой как ii…

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

+++ Caesium/0.4 RC1

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

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

+++ Caesium/0.4 RC1

Это был риторический вопрос :)

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

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

Тоже самое можно сказать и про IDEC сейчас :)

А может не будем про политику?…

Ну это издевательство над здравым смыслом когда одной рукой вы разрешаете декларировать поддерживаемые фичи через features, а другой запрещаете эти фичи расширять…

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

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

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

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

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

> Очень сильно снижает количество трафика.

Это да :)

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

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

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

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

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

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

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

revoltech> Длина ID сообщения — 21 байт (20 на сам ID и один на перевод строки). Это погоды не делает.

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

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

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

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

shaos> Это да :)

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

Reprise> Интересно было бы услышать какая у меня политическая позиция :)

Виноват. Спутал таверну с ping.

revoltech> Так всё-таки есть стандартный и поддерживаемый вариант, чтобы полный перефетч эхи делался не кучей мелких запросов

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

Фуф, а я уж думал выяснится, что Лобанов - квадробер :)

shaos> Фуф, а я уж думал выяснится, что Лобанов - квадробер :)

Так-так-так... С этого места поподробнее!

+++ отключает фетч с spline-online и настраивает iptables

А, это bosfor. С более развитым ip и прозрачным гейтом в ii, эхи там определялись не по точке, а по символу : спереди.

Не помню, был ли там список эх, но там была команда discover, показывающая все эхи на станции, скрытых эх нету. У меня, кстати, в gemini транслируются тоже все эхи, в том числе скрытые :)

Расширения idec я не поддерживаю, но конкретно в моей реализации есть две минифичи, естественно это никакой не стандарт:

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

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

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

Первые 2 фичи интересные, а по лимитам вроде у IDEC логичнее получается

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

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

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

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

Точнее наоборот, сообразил :)

Тока оно неверно работает, надо поменять

Но тем не менее - девочка та же :)

http://ii.blcat.ru/idec.talks

Ага, это Оля. Просто я когда возобновлял станцию, взял первую попавшуюся версию, а она с Олей, я и оставил. При переезде на picnic тоже оставлю.

Я думал, ты про аватарки девочек, которые были в 2014 году. Надо попробовать их на py3 портировать.

> а что за расширение list.txt?

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

GET /list.txt

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

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

> я не знаю как запросить последние n сообщений

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

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

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

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

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

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

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

По идее хеши можно было бы в IDEC протокол добавить для GET /x/c/echo.1/echo.2 которое сейчас возвращает количество сообщений (видимо предполагалось, что сообщения никогда не удаляются). Кто-то вообще пользуется /x/c/... сейчас? Ну или завести новый вызов /x/h/... для возврата списка с хешами списков хешей...

> при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного

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