vit01> Сисоп у нас вообще понятие фиктивное. Почему? Потому что хостинг нынче можно приобрести за 100 рублей в месяц, а то и вообще бесплатно. Поднять свою станцию новичок может за час, не больше (а старожилы вроде меня и тебя справятся с этим за 15 минут). Принципиально разница между мной и Борисом, например, лишь в том, что я здесь с 2014 года сижу, вот и всё.

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

vit01> Нет, не совсем. Взять, к примеру, социальные сети. Там люди часто публикуют настоящую информацию, иногда с точностью даже до дома. Но, думаю, мало у кого возникнет вообще желание общаться вживую со своими сетевыми знакомыми, пусть даже вы живёте на соседних улицах.

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

vit01> Моя позиция кратко: либо свои города записывают все поголовно, либо вообще никто. В наших реалиях сисоп и поинт по сути своей не отличаются.

А вот это я хотел предложить следом =) Вести поинт-листы.

Хотя по сути мы сеть анархическая. Без чёткой структуры и обвеса кучи правил. И это прекрасно.

AL> Хотя по сути мы сеть анархическая. Без чёткой структуры и обвеса кучи правил. И это прекрасно.
AL> Вести поинт-листы.

Давай тогда формат для поинтлистов
Предлагаю что-то вроде образца about.users.51, например:

{
"point": "Vasyan42",
"primary_address": "station13, 12309",
"realname": "Vasiliy Pupkin",
"stations": ["mira", "tavern", "station13"],
"birth_year": 0000,
"location": "Moscow",
"contact": ["tel:1234567890", "mailto:example@domain.com", "https://github.com/XXX", "https://example.com"],
"activities": "Programmer, office worker, artist",
"ideology": "communist",
"religion": "GNU/Linux",
"additional": "Разбираюсь в systemd и девочках на уровне специалиста; не против посещать поинтовки и выходить на контакт; поклонник Emacs и KDE"
}

Если пункт отсутствует, то просто ставить false.

AL>> поинтлист станции вряд ли должен иметь информацию о другой станции. Во всяком случае, так это вижу я. Но можем и пообсуждать =)
vit01> Окей, логично. Можно сделать скрипт, компилирующий поинтлисты по параметру realname. Для одинаковых полей realname объединять юзеров в одного и приписывать
vit01> ====
vit01> "stations": [["mira", "12309"], ["tavern", "55"]],
vit01> ====

Рилнейм не стоит использовать в качестве идентификатора пользователя. Да и указание в поинт-листе AKA несколько портит виртуалов =)

Дейстивтельно ли является проблемой дублирование нескольких десятков байт?

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

AL> Да и указание в поинт-листе AKA несколько портит виртуалов =)
Виртуалов можно не указывать. Если сильно хочется, то можно ставить в realname какого-нибудь Наполеона Бонапарта :)

Ладно, хрен с этим всем. Слепил файлик, записал туда себя

https://ii-net.tk/ii/ii-point.php?q=/x/file/pointlist.json

AL> Много лишней информации.

Ладно, пусть будет без "лишней".

AL> поинтлист от ноды поинткиперу, а он уже компилирует.
AL> То есть сделлать что-то вроде
AL> ...
AL> и потом компилировать это добро уже в глобальный поинтлист.

Минус в том, что один и тот же человек может пользоваться разными станциями одновременно.
Вот я, к примеру, на четырёх нодах поинтов имею. Дублировать теперь все данные?

В таверне сабж. Это лента главной страницы http://ifhub.club/ созданная по просьбе администратора сего ресурса. Сайт посвящён интерактивной литературе и содержит разнообразные статьи и заметки по теме. Иногда попадаются занятные размышления и даже небольшие рассказы.

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

btimofeev> У меня какой-то странный баг случился. В один прекрасный момент клиент просто перестал скачивать сообщения. В логе писал одну строку fetch ..., затем одну строку removed pipe.2032 и потом сразу получено сообщений 0. Хотя при этом приходили уведомления, что есть новые сообщения. Так продолжалось пару дней.

Баг исправлен, обновите все клиент по прежней ссылке.

Проблема была в том, что если человек подписался на новую эху, то алгоритм /x/c пытался найти её в локальном кэше, но найти не мог и ронял весь фетчер при попытке присвоить null целочисленной переменной.

AL>> поинтлист от ноды поинткиперу, а он уже компилирует.
AL>> То есть сделлать что-то вроде
AL>> ...
AL>> и потом компилировать это добро уже в глобальный поинтлист.
vit01> Минус в том, что один и тот же человек может пользоваться разными станциями одновременно.
vit01> Вот я, к примеру, на четырёх нодах поинтов имею. Дублировать теперь все данные?

Да. Потому что поинтлист станции вряд ли должен иметь информацию о другой станции. Во всяком случае, так это вижу я. Но можем и пообсуждать =)

AL> поинтлист станции вряд ли должен иметь информацию о другой станции. Во всяком случае, так это вижу я. Но можем и пообсуждать =)

Окей, логично. Можно сделать скрипт, компилирующий поинтлисты по параметру realname. Для одинаковых полей realname объединять юзеров в одного и приписывать

"stations": [["mira", "12309"], ["tavern", "55"]],

Давно я не говорил о сабже.

Итак, от последнего сообщения, датируемого 18-м ноябрём прошлого года, сделано мало, но оно сделано =)

* Исправлен баг вызова фетчера, приводивший к падению клиента в случае забора почты без указания authstr в конфиге.
* Исправлен баг, приводивший к несовместимости мейлера с ii.
* В api добавлена функция remove_echoarea(echoarea), ужаляющая конференцию из базы.
* Исправлен баг клонирования в мейлере, приводивший к невозможности клонировать уже существующую конференцию.
* Актуализирован файл keys_android.py.
* Изменён способ отображения курсора. Теперь оно не вызывает перевода строки.
* Добавлена возможность просмотра списка сообщений в конференции для быстрой навигации. По-умолчанию он вызывается клавишей "L" ("T" для андроида). Открывается в режиме чтения.
* Исправлены некоторые баги. В том числе баг, приводивший к падению про нажатии G в режиме чтения пустой эхи.
* Исправлены ошибки некорректного перечитывания конфига после редактирования с помощью клавиши s_config.
* Исправлен баг, приводивший к падению при отображении списка конференций без описаний. Спасибо j-maks.
* При редактировании конфига с помощью клавиши E на экране выбора конференции, теперь перечитывается тема оформления.
* Цветовая схема norton переработана под более приятные для глаза цвета.

Фиксировать новую версию пока всё же рановато, как по мне. Лучше подождать новых багов и поправить их.

ЗЫЖ Работы над iing так же не прекращаются. В ближайших планах перевести таверну на ait-базу, например.

Gpg + скрытоэха 100% рабочий вариант. Но, помню раньше некоторые были против.

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

AL>> Если попробовать это протолкнуть через расширение протокола (авторизованный доступ к эхе прилепить, например), то нода будет знать кто запрашивает нетмейл и отдавать только те сообщения, которые предназначены конкретному пользователю. Небольшую доработку только сделать, чтобы нетмейл не кореллировал с e/, m/, u/e и u/m.
gl00my> В принципе, да. Но нетмыл между нодами ходит целиком, как любая другая эха. Что не требует никакой маршрутизации. По крайней мере на первоначальном этапе. А конкретный узел может знать открытые ключи своих абонентов и отдавать почту выборочно. Но я так понял, что основной вопрос это как раз обмен мешками почтой между узлами. В этом смысле -- пусть ходит вся эха целиком. Тем более, что объемы там вряд ли будут большими.

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

Как выдернуть последние 50 сообщений из эхи?

Что в offset и в limit нужно указать?

vvb> Без возможности отправлять личные сообщения мы имеем сильное отсутствие
vvb> возможностей данной технологии.
vvb> возможно ли как-то допилить ii чтобы возможность посылки личных сообщений
vvb> появилась? в фидо это было.

gl00my предложил такой вариант.

"Здравствуйте All!

Тут при общении в одной jabber конференции, один из участников с удивлением узнал, что в ii нет личных сообщений (чем был удручен).
Идеологически, как я понял, данная фича плохо вписывается в архитектуру ii.

В качестве тупой (но рабочей) идеи хотел предложить следующее:
Все личные сообщения забираются с ноды целиком -- и свои и не свои. Но разграничение доступа осуществляется сугубо
криптографически (например, pgp). То-есть, человек сообщает свой открытый ключ, если хочет, чтобы к нему ходила почта.
Потом забирает целиком все сообщения (все личные сообщения) -- но расшифрует он только те, которые сможет (зашифрованные на его
открытом ключе).
Это, на самом деле, можно делать даже сейчас, просто выделив эху netmail. Но хорошо бы встроить некие средства повышающие
удобство в цезий, например. Детали нужно продумывать, но общая идея такая."

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

Если попробовать это протолкнуть через расширение протокола (авторизованный доступ к эхе прилепить, например), то нода будет знать кто запрашивает нетмейл и отдавать только те сообщения, которые предназначены конкретному пользователю. Небольшую доработку только сделать, чтобы нетмейл не кореллировал с e/, m/, u/e и u/m.

2vit01&Difrex: что думаете по теме?

PS: Тему нетмейла я поднимал ещё весной 2014, но тогда Рома был сильно против усложнения технологии, а на базе того, что было, оно не прилеплялось.

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

Есть два 100% рабочих варианта сейчас:

1. Обмениваемся ключами, шлём зашифрованное сообщение товарищу: "пошли болтать в эху такую-то". Если надо прокидывать, то пишем шифрованное сначала сисопу (открытый ключ которого по умолчанию известен всем).
2. Пишем товарищу обычное сообщение: "пошли болтать в эху такую-то". В этой эхе вы спокойно обмениваетесь ключами и общаетесь полностью с шифрованием. Если эху надо прокидывать, то говорим об этом сисопу прямым текстом.

С GPG нынче справится даже домохозяйка, честное слово. Если в консоль не хочется, посоветую тулзу kgpg из состава Кед. Очень удобная, в пару кликов всё делается.

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

AL> Если попробовать это протолкнуть через расширение протокола (авторизованный доступ к эхе прилепить, например), то нода будет знать кто запрашивает нетмейл и отдавать только те сообщения, которые предназначены конкретному пользователю. Небольшую доработку только сделать, чтобы нетмейл не кореллировал с e/, m/, u/e и u/m.

В принципе, да. Но нетмыл между нодами ходит целиком, как любая другая эха. Что не требует никакой маршрутизации. По крайней мере на первоначальном этапе. А конкретный узел может знать открытые ключи своих абонентов и отдавать почту выборочно. Но я так понял, что основной вопрос это как раз обмен мешками почтой между узлами. В этом смысле -- пусть ходит вся эха целиком. Тем более, что объемы там вряд ли будут большими.

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

v.v.b.

offset - это смещение с начала эхи
limit - количество запрашиваемых

Выдернуть последние 50 можно через отрицательный offset
То есть запросом /u/e/echoarea1/echoarea2/-50:50

Виртуальный "курсор" как бы отходит с конца 50 и делает срез вперёд на 50.

btimofeev> Можешь добавить, что бы фетчер при отсутствии интернета сообщал об этом. Сейчас он просто пишет получено ноль сообщений.

У меня на компе с андроид студией процессор сгорел. Поэтому добавлю минимум на следующей неделе.

ЗЫ: могу еще всяких графиков нарисовать. Скажите кому какая статистика интересна.

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

По-этому сделал картинками. Генерятся phantomjs каждый день, на месяц назад

Можешь добавить, что бы фетчер при отсутствии интернета сообщал об этом. Сейчас он просто пишет получено ноль сообщений.

>А можешь сделать распределение сообщений по дням недели?

Что именно ты имеешь в виду? Среднее количество сообщений в день? За какой период?

О, неплохая статистика. А можешь сделать распределение сообщений по дням недели?

// "Количество" пишется с одной л :)

Difrex> Gpg + скрытоэха 100% рабочий вариант. Но, помню раньше некоторые были против.
Difrex> Вообще лички не хватает, да. Поддержку гпг в стандарте было бы хорошо заиметь. :)

Значит нас уже двое =)

У меня тут при общении с gl00my появились некоторые мысли. Я сперва их додумаю, а потом вывалю сюда. Но не знаю когда. Ближайшие две недели у меня будут очень напряжённые.

Сделал поиск по индексу исключая ботов, на пол-года назад.

Есть три графика, вот они: https://dynamic.lessmore.pw/stats.html :)

>> А можешь сделать распределение сообщений по дням недели?
Difrex> Что именно ты имеешь в виду? Среднее количество сообщений в день? За какой период?

Всего в выборке N сообщений (за последний месяц); на понедельники пришлось X1, на вторники - X2, и так далее, их сумма равна N.
Обычная гистограмма активности по дням недели, без подсчёта среднего. Желательно с указанием самих чисел, а не в процентах.

А sqlite не подходит?

Её можно всю в память поместить и зависимостей минимум.

Переделал.

Первый день - понедельник, а не воскресенье.

Сабж оказался плохой идеей. Слишком медленно это в реалиях узла работает. Надо или оставлять как есть или прикручивать взрослую СУБД.

Пожалуй, на каком-нить мускуле и остановлюсь. Как опуии. Дабы по прежнему можно было поднять свой узел так же просто, как во времена ii-03.

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

17track прикрыл лавочку с общедоступным API, однако cainiao прекрасно идёт ему на замену, съедая больше видов трек-номеров.

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

А вот переписать ридми пока руки не дошли. Но по работе со скриптами там всё описано и даже примеры есть. Остались только уточнения про имена директорий, вроде.

Теперь хорошо, спасибо.

// Не очень репрезентативно, наверное, за одну неделю (побольше бы промежуток), но в какой-то степени так даже лучше будет.

Сделал(картинка внизу) https://dynamic.lessmore.pw/stats.html

Phantomjs теряет подписи :(

AL>> @repto:57quEthADzoQSLloS6kE
jmaks> Вообще интересная строка !; Это нововведение или так отрабатывает
jmaks> веб-доступ? цезий, просто показывает ее как обычный текст.

Пофиксил, однако =)

Обнаружил в документации сабж.

> Id сообщения (msgid) - уникальный номер, который генерируется станцией, как 20 первых символов base64 sha256-bin хэша сообщения.

Не описано, что "-" нужно заменить на "A", а "_" на "z".

PS: Кстати, обратите внимание на адрес. Я начал тыкать go. Естественно, писать для освоения или хелло ворлды или решать знакомые задачи. Так что я написал ноду на go. Пока она в режиме тестирования. Скоро выложу в свободный доступ.

// Все желающие могут попробовать подключиться http://spline-online.tk:4242/ . Поинты дублируются с таверны.

AL> Не описано, что "-" нужно заменить на "A", а "_" на "z".

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

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

AL>> @repto:57quEthADzoQSLloS6kE
jmaks> Вообще интересная строка !; Это нововведение или так отрабатывает
jmaks> веб-доступ? цезий, просто показывает ее как обычный текст.

Это косяк в тоссере узла. Пофикшу в первую очередь =)

AL> PS: Кстати, обратите внимание на адрес. Я начал тыкать go. Естественно, писать для освоения или хелло ворлды или решать знакомые задачи. Так что я написал ноду на go. Пока она в режиме тестирования. Скоро выложу в свободный доступ.
А вот это реально круто, {go} вообще очень шустрый и довольно компактный
язык. Мне на нем реализация собственного гит-репозитория очень глянулась,
тот самый gogits

AL> @repto:57quEthADzoQSLloS6kE
Вообще интересная строка !; Это нововведение или так отрабатывает
веб-доступ? цезий, просто показывает ее как обычный текст.

Difrex> А sqlite не подходит?
Difrex> Её можно всю в память поместить и зависимостей минимум.

Пробовал sqlite в первую очередь. Меня не удовлетворило время построения индекса. Потом когда-нибудь, попробую что-нибудь по теме оптимизации дискового ресурса ещё.

@repto:57quEthADzoQSLloS6kE
AL>> Не описано, что "-" нужно заменить на "A", а "_" на "z".
vit01> Спасибо за багрепорт, добавил примечание в документацию.
vit01> И да, не забывай, что у тебя на Гитхабе в репозиторий с доками стоит RW-доступ, поэтому недочёты ты можешь чинить самостоятельно.

Никак не разберусь с этим =)

Никак не разберусь с сабжем. Чистка кеша x/c не даёт результата. Если эху в список я добавил после первого забора сообщений с ноды, то не получаю в неё ничего. При получении списка эх с ноды имею в конце эху null.

Как всё это пофиксить.

AL> Есть ли возможность экспорта/импорта конфига?

Открой боковое меню -> дополнительно -> вкладка база данных -> в самом низу экспорт/импорт конфига. Вообще этому функционалу место в настройках приложения, имхо.

AL>> При получении списка эх с ноды имею в конце эху null.
vit01> Ничего необычного. В конце list.txt сервер наверняка выдал пустую строку, а клиент посчитал её за настоящую. Могу починить, если критично.

Эта ситуация вполне обычная и тянется ещё с ii-03. Я имел в виду, что почему сюда не присобачить фильтр?

AL>> В этом случае получается поведение равнозначное отключенной поддержке x/c и он начинает сосать всё, до чего дотянется
vit01> Включай принудительную обрезку индекса (в Цезии это включено по умолчанию, в сабже - нет)

Это несколько неочевидно.

AL>> А почему ты не сделал что-то типа как у меня в мейлере к цезию? Чтобы он получал все x/c по подпискам и сравнивал с кешем для минимизации индекса? Или я опять что-то не уловил?
vit01> Выражайся яснее, пожалуйста. Совсем не понял, что здесь имеется в виду. База данных у меня единая, кэша индекса нет.

Я ж уже объяснял тебе эту фичу. Берём x/c с ноды, берём локальный x/c. Вычисляем максимальную разницу между каунтерами и её передаём в расширенный u/e. Если новая эха и в локальном x/c по ней информации, то выставляем длину индекса на умолчальную, если максимальная разница меньше.

AL> Чистка кеша x/c не даёт результата. Если эху в список я добавил после первого забора сообщений с ноды, то не получаю в неё ничего.

Вот это странно. Скорее всего, баг.

AL> При получении списка эх с ноды имею в конце эху null.

Ничего необычного. В конце list.txt сервер наверняка выдал пустую строку, а клиент посчитал её за настоящую. Могу починить, если критично.

btimofeev>> А если в настройках ноды выставить галку на "качать индекс дальше, если все сообщения новые", не помогает?
AL> В этом случае получается поведение равнозначное отключенной поддержке x/c и он начинает сосать всё, до чего дотянется

Включай принудительную обрезку индекса (в Цезии это включено по умолчанию, в сабже - нет)

AL> UPDATE: А вот как только значение x/c для эхи на узле меняется, он начинает выкачивать сообщения из новых эх. Поведения для меня совершенно загадочное. Ещё при изменении количества сообщений для забора он не забирает пока не изменится x/c для каждой эхи.

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

AL> А почему ты не сделал что-то типа как у меня в мейлере к цезию? Чтобы он получал все x/c по подпискам и сравнивал с кешем для минимизации индекса? Или я опять что-то не уловил?

Выражайся яснее, пожалуйста. Совсем не понял, что здесь имеется в виду. База данных у меня единая, кэша индекса нет.

AL> Есть ли возможность экспорта/импорта конфига?

Да, есть, уже было сказано ранее

btimofeev> А если в настройках ноды выставить галку на "качать индекс дальше, если все сообщения новые", не помогает?

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

btimofeev> У меня было несколько раз, что в ноду, в которую никто ничего давно не писал, клиент зачем-то начинает скачивать старые сообщения. Хотя вышеназванная настройка выключена.

Вот такого не наблюдал пока.

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

2vit01: А почему ты не сделал что-то типа как у меня в мейлере к цезию? Чтобы он получал все x/c по подпискам и сравнивал с кешем для минимизации индекса? Или я опять что-то не уловил?

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

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

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

vit01> Если вы все помните, я обещал поправить все баги в клиенте как можно скорее, когда куплю замену к процессору для сдохшего компа.
vit01> Реальность оказалась гораздо хуже: сдох не процессор, а сама материнская плата. Это значит, что писать андроид-софт через IDE я больше не могу. А нетбук, в свою очередь, студию не потянет.

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

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

Реальность оказалась гораздо хуже: сдох не процессор, а сама материнская плата. Это значит, что писать андроид-софт через IDE я больше не могу. А нетбук, в свою очередь, студию не потянет.

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

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