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

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

И да, спасибо shaos за доступ, будем тестить в idec.test дальше.

Перепутал поля местами, бывает. С GUI-клиентом путать не буду.

А, да, так тоже задумано. Держу строку в пределах 80 символов. Не автоматом, вручную.

@>1C5< 87 3@0D8G5A:>3> :;85=B0 GB>-B> >B?@028BL

А щас?

Во, разобрался. Короче, перед base64 надо явно тиклю перегонять в UTF-8, даже если ввод уже в оном.

Пишу сам себе.
Ага.

Теперь, по идее, мой клиент уже должен светить агента tii/current.

А какие юзерагенты имеют другие клиенты вроде того же Caesium? Что-то своё или дефолт какой-нибудь?

Мигрировал клиента на sqlite, так что если будет ещё один большой фетч, не удивляйтесь.

Это для того, чтобы удобнее читалось в терминале на клиентах без reflow. Хотя, я так понимаю, таковых здесь нет, поэтому буду отказываться от своей гоферистской привычки. Ну и то, что GUI-клиент уже более-менее юзабелен, тоже этому способствует.

Во, вылезло ещё одно место, где trim не делался, щас должно быть нормально.

Умеют, но далеко-далеко не все, я вон раньше на баше вообще пилил со своим reflow...

Я на gopher://hoi.st обитаю, если что.

Насчёт tii/tiix, как и насчёт ii вообще, в понедельник свежий псто в гофер выкачу. Уже точно есть что сказать. В idec.talks тоже что-то длиннотекстовое на днях появится, думаю.

А так да, я давно уже свой софт в public domain выкладываю, мне ограничения ни с одной из сторон (как копирайта, так и копилефта) не импонируют. Ну и Tcl/Tk, особенно начиная с 8.6, настолько хорош, что позволяет в довольно ограниченные сроки пилить вещи типа tiix и BFG. На sqlite3 мигрировать, конечно, не хотелось, но пришлось: некоторые ноды отдают сообщения не по порядку их фактической публикации (видимо, смёржены позже), поэтому, чтоб не сортировать на лету, пришлось сортировать уже скулайтом при выводе.

> А потом с дальней станции прилетает сообщение полугодовой давности :)

Ну, ради такого можно добавить ещё одну галочку — сортировать не хронологически, а по внутреннему id в базе, который сохраняет именно порядок добавления туда. Делов-то...

Наверное, добавлю-таки. Но по дефолту всё равно оставлю хронологическую сортировку.

o_O А оно у тебя не в базу сохраняет? В моём случае оказалось, что ORDER BY при выводе сделать всё-таки проще.

/ ?

Вот это паранойя. Да, со старлинка, и что? Челобитных непонятно кому ради регистрации точно писать не буду.

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

Исходники будут, разумеется. И клиента, и станции.

Настолько дружеского, что действует презумпция виновности по IP?

Нет, блин, это страшный спамбот. Ну капец, секрет Полишинеля.

Ну я тоже вне его, но мыло уже засветили, так что валяй. И куда там коннектиться, на shaos.net или на sprinternet.io/iii?

Интересно, существуют вообще таковые или нет? И если да, то как их найти?

Проверил — у тебя эта фича есть и работает, а вот на tgi нет.

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

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

1. Да, я — любитель спутниковых каналов связи, тора, анонимности, анархии и всего того, что у вас здесь, видимо, принято относить ко списку смертных грехов, а по факту чуть ли не единственного залога комфортного существования в онлайне. Сеть ii меня заинтересовала как раз своим потенциалом превращения в антифидо: меньшая гэбнявость при тех же (или даже больших) распределённости и легковесности протокола. Добавить бы сюда только приватность на транспортном уровне (например, Gopher-узлы в .onion имеются, вполне можно сделать там же ii-станции) и будет вообще хорошо. А то, например, Tox и SimpleX тоже распределены, но легковесностью там и не пахнет из-за количества задействованной криптографии. Ну и они на реалтайм больше рассчитаны, а здесь наоборот.

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

> Разделитель для бандла - новая линия (LF, код 10).

Естественно, по аналогии с остальными легковесными протоколами я запостил тестовое сообщение с \r\n на концах строк. И естественно, получил отлуп и понял, что там только \n должно было быть. Но то, что у кого-то при этом что-то отвалилось на серверной части... Ребят, валидация входящих данных — это БАЗОВЫЙ принцип безопасности. Если у вас от непреднамеренной бинарщины валится сервер, это не проблемы отправителя этой бинарщины, а сугубо ваши, поскольку к преднамеренной такой сервер окажется совсем не готовым.

3. Надо бы как-то придумать, как оптимизировать фетчинг. С этими GET-запросами на /u/m я вот столкнулся с ограничением, что у каких-то нод и их долбаного нжинкса тело GET-строки не может превышать 256 символов. Соответственно, за один запрос можно выкачать бандл максимум из 12 сообщений. Крайне неэффективно выходит. Ну или я что-то не так понял в доках и всё-таки имеются способы пооптимальнее. Не говоря уж о том, что такой же фетчинг было бы неплохо организовать по тому же Gemini или Gopher/Finger/Nex, например. HTTP для данных целей — вообще оверхед. Достаточно одной строки запроса и погнал ответ. Тем более, что спецификация прямо говорит, что HTTP — лишь один из вариантов.

4. Веб-зеркалам, как по мне, не нужно придавать особого значения. Может, это здесь обсуждалось, но вроде бы фишка именно в распределённости: каждый выкачивает максимум контента. Если все начнут пассивно читать веб-зеркала, что от сети в итоге останется, если основные ноды выйдут покурить? Не знаю, может, в будущем размер станет иметь значение, но вот на данный момент у меня sqlite3-база с содержимым (публичных) эх из пяти станций занимает 104 мега. Это меньше любого из современных браузерных движков в распакованном виде. Не думаю, что единоразовое выкачивание данных такого объёма вызовет у кого-то проблему, особенно если решить вопрос пункта 3.

5. Shaos нашёл исходники моего ii-клиента tii/tiix, но это всё ещё в процессе допила. Как посчитаю действительно готовым, сделаю анонс со ссылками. Тогда и о новой станции можно будет поговорить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

shaos> Это да :)

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

shaos> ну и GET /list.txt?h=1 заодно тоже можно поддержать ;)

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

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

hugeping> Нет.

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

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

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

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

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

shaos> это тоже можно

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

shaos> гугол говорит 8192

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

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

shaos> Кстати вопрос про POST в /u/m периодически поднимался, например вот тут ii://w6o5S9CleUqqm4Lgc8O9 (декабрь 2021) что так ни к чему и не привело - вот полное обсуждение

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

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

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

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

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

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

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

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

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 что?

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

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

hugeping> Каких метаданных и почему куча соединений?

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

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

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

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

И да, спасибо shaos за доступ, будем тестить в idec.test дальше.

[forwarded from idec.test]

Перепутал поля местами, бывает. С GUI-клиентом путать не буду.

[forwarded from idec.test]

А, да, так тоже задумано. Держу строку в пределах 80 символов. Не автоматом, вручную.

[forwarded from idec.test]

@>1C5< 87 3@0D8G5A:>3> :;85=B0 GB>-B> >B?@028BL

[forwarded from idec.test]

А щас?

[forwarded from idec.test]

Во, разобрался. Короче, перед base64 надо явно тиклю перегонять в UTF-8, даже если ввод уже в оном.

[forwarded from idec.test]

Пишу сам себе.
Ага.

[forwarded from idec.test]

Теперь, по идее, мой клиент уже должен светить агента tii/current.

А какие юзерагенты имеют другие клиенты вроде того же Caesium? Что-то своё или дефолт какой-нибудь?

[forwarded from idec.test]

Мигрировал клиента на sqlite, так что если будет ещё один большой фетч, не удивляйтесь.

[forwarded from idec.test]