AL>> Коммитнул в сабж
Anotheroneuser> Это значит, где-то опубликовал?

В внёс изменения в исходники документации по idec.

Anotheroneuser> А где?

На гитхабе.

Anotheroneuser> Я бы тоже хотел свой адрес оставить

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

Difrex> Я думаю, что нужно начинать с этим что-то делать.

Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)

Закладываю три вещи в это дело:

1. Реализация на python, чтобы любой желающий мог ознакомиться и внести изменения.
2. По возможности максимальная модульность реализации.
3. Настолько лаконичный и простой код, насколько я смогу.

В данный момент реализовано всё, кромен фэх и нет вебморды, но оно уже существенно лучше iing в плане реализации. Кода меньше, он проще и быстрее.

Difrex> Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
Difrex> разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
Difrex> и клиента.
Difrex> Вот этот репозиторий: https://github.com/idec-net/netmail

Хорошее дело.

Difrex> Давайте обсуждать и дописывать.

Обсуждать готов, а вот писать пока не очень.

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

> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Это дело хорошее :)

> В данный момент реализовано всё, кромен фэх и нет вебморды
А нужна ли веб-морда в эталонной реализации ноды?

> Обсуждать готов, а вот писать пока не очень.
Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.
Так мы вообще никак не переусложним стандарт.

>> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Difrex> Это дело хорошее :)

Нужное как минимум =)

>> В данный момент реализовано всё, кромен фэх и нет вебморды
Difrex> А нужна ли веб-морда в эталонной реализации ноды?

В реализации ноды, может, и не нужна. А клиент хочу с вебмордой сделать. Это потребует меньше кода и усилий для создания удобоваримого интерфейса. А от морды клиента до морды узла один шаг =)

>> Обсуждать готов, а вот писать пока не очень.
Difrex> Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

Обязательно, но пока занят всякой фигнёй =(

>> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Difrex> Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.

Да. Всё верно =)

Difrex> Так мы вообще никак не переусложним стандарт.

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

В текущем обновлении для сабжа появилась одна очень интересная фича

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

Что делать:

1. Обновите клиент
2. Зайдите в новостную эху (желательно habra.rss )
3. Возьмите любое сообщение и прокрутите в конец
4. Нажмите на волшебную кнопочку

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Привет!

Это первое сообщение от G2I - бота слежения за задачами в репозитории на Github.
Сейчас я наблюдаю за проектом https://github.com/idec-net/netmail.

Новые события будут публиковаться в этой теме.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 08:43:24 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472330230

> Мне кажется, что идеологически правильно дать возможность пользователю тянуть свою личку с любой ноды

Именно. Но при этом надо не давать ноде читать нетмейл поинтов чужих нод. Чтобы пересылать можно было, а читать - нет. Поэтому какое-то подобие шифрования желательно

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 09:44:30 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472350243

Напишу бота `github<->idec`, чтобы транслировать стрим, а то не все подключились в обсуждение.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:56:50 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472035614

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

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

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

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:58:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472036264

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

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

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


+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:11:45 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472017154

По факту это самая сложная штука для проработки

Ведь нам надо сделать так, чтобы

1. Нетмейл-сообщения ходили между станциями
2. Станция не могла прочитать нетмейл чужих станций
2.1 Но при этом могла отдавать их даунлинкам

Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Client protocol draft" https://github.com/idec-net/netmail/pull/1.
Оставлен 2019-03-12 12:22:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/1#issuecomment-471977969

Как в текущем виде?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-16 13:47:14 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-473531586

> Напишу бота github<->idec, чтобы транслировать стрим, а то не все подключились в обсуждение.
Написал. Постит комменты с гитхаба в этот тред: https://dynamic.lessmore.pw/thread/3a6a0226-a22f-475a-82d1-81311e552b3a

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Хм. Не вижу никакой новой кнопки.
Смотри скрин в файлоэхе pictures

+++ картошки хватит на всех

Difrex> Хм. Не вижу никакой новой кнопки.
Difrex> Смотри скрин в файлоэхе pictures

Всё правильно, эта кнопочка на то и волшебная, что отображается не у всех =)

Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

>Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе
Ага, KDE Connect :).

А эта штука может работать вне кед?

>>Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе

Difrex> Ага, KDE Connect :)
Difrex> А эта штука может работать вне кед?

Конечно может. Я вот уже долгое время работаю в XFCE и этой штукой доволен.

А на нетбуке тоже KDE Connect работает, и там AwesomeWM

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>> Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.

Difrex> Сделаю страничку для роботов :)
Difrex> Еще есть в планах доливать раз в неделю данные в read-only индекс и прямо вставлять iframe из кибаны, чтобы все интерактивно было.

Спасибо, что сделал. Хорошая штука.

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

Скриншот в фэхе pictures прилагается

Хочется найти ему какое-то более крутое применение, потому что инструмент мощный, но придумать пока не могу :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Новый комментарий от пользователя Difrex
к задаче "Client protocol draft" https://github.com/idec-net/netmail/pull/1.
Оставлен 2019-03-16 19:28:35 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/1#issuecomment-473577352

Ну, что, мержим?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Сегодня буду обновлять основной хост динамика с Debian oldstable до stable.
Возможно все приляжет до завтра. Бэкапы льются на DO, так что все восстановимо будет, если что.
Так же буду переводить сеть между виртуалками с OpenVPN на Wireguard.

G2I> Ведь нам надо сделать так, чтобы
G2I> 1. Нетмейл-сообщения ходили между станциями

Это просто.

G2I> 2. Станция не могла прочитать нетмейл чужих станций

Почему? Если нужно шифрование, то оно должно быть на стороне клиента, а не на стороне ноды.

G2I> 2.1 Но при этом могла отдавать их даунлинкам

Это совсем просто.

G2I> Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

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

1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
3. Шифрование не является частью протокола.

То есть выглядеть оно должно примерно так:

Поинт забирает почту: GET /x/m/<authstr>[/слайс].

Поинт отправляет почту: POST /x/m/ (параметры pauth и tmsg).

Нода забирает почту с аплинка: GET /x/n/<password>.

Этого уже достаточно для рабочей лички, в принципе.

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

За основу формата сообщений предлагаю взять существующий формат:

ii/ok[/reply/<msgid>]
<адрес получателя>
<время>
<имя отправителя>
<адрес отправителя>
<имя получателя>
<тема>

<тело сообщения>

И для отправки тоже:

<адрес получателя>
<имя получателя>
<тема>

[@repto:<msgid>]
<тело сообщения>

В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?

ЗЫЖ Я за любую движуху, но без излишнего усложнения протокола.

Посмотри пожалуйста https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api

если согласен, то давай межить этот ПР.

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

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


+++ At work. idec.el/0.1

AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
Difrex> В принципе, если личка будет вся синхронизироваться нормально, то можно и своей ноды ее тянуть.

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

AL> 1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
AL> 2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
AL> 3. Шифрование не является частью протокола.

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

Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

Это и правда упрощает реализацию, хотя и теряется гибкость.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

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

Но это всего лишь мои мысли.

AL>>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01>> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

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

Предположим, у нас есть 3 станции по такой схеме:

node1 ---- node2 ---- node3

node1 не соединена напрямую с node3
Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:

1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM

2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

На счёт протокола получения лички клиентом возражений нет? Мержим?

+++ картошки хватит на всех

vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM


vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

vit01> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.

Можно обменяться ключами нод. Ну, шифровать ими личку с армором, тогда всё остаётся в plain text, но усложняет стандарт.
С другой стороны gpg есть ваще везде.

+++ картошки хватит на всех

Ура, у меня заработали уведомления о новой почте!

+++ картошки хватит на всех

vit01> Предположим, у нас есть 3 станции по такой схеме:
vit01> ====
vit01> node1 ---- node2 ---- node3
vit01> ====
vit01> node1 не соединена напрямую с node3
vit01> Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:
vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM
vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов
vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

Для этого есть PGP, например. Если уж параноишь в сети друзей, то делай это правильно. Шифрование на уровне стандарта это бессмысленное переусложнение. IDEC должен всего лишь носить почту, а остальное - не его забота.

vit01> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.

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

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

Difrex> На счёт протокола получения лички клиентом возражений нет? Мержим?

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

Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?

Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?

Никаких соображений. Всё замечательно. Так я это себе и представлял =)

Я тут немного выпадаю из сети. Не теряйте. Рано или поздно я отвечу =)

AL> Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?
AL> Никаких соображений. Всё замечательно. Так я это себе и представлял =)
Ок. Я мержу тогда.

+++ At work. idec.el/0.1

Новый комментарий от пользователя Difrex
к задаче "Описание client API" https://github.com/idec-net/netmail/issues/4.
Оставлен 2019-04-03 07:08:09 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/4#issuecomment-479367180

Сделано в рамках #1

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

В books закинул отличную книгу. Сабж. Очень помогает мне разобраться в себе и переосмыслить свои поступки, их причины, на свою жизнь и мир вокруг меня.

Книга представляет собой историю одного бизнесмена, рассказанную от первого лица. Действия в книге не так много, но зато много рассуждений и идей, который вроде бы и лежат на поверхности, но я сам до них не додумался за 33 года жизни.

Рекомендую к прочтению всем. Даже тем, кто уже полностью доволен собой и своей жизнью.

2vit01: в книге нет религиозной составляющей =)

PS: Пока я её не дочитал, но прочтённая четверть уже начала вправлять мне мозги.

Смотрю в стандарт и думаю про сабж.

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

Здравый смысл подсказывает мне, что как минимум ":" стоит запретить, так как это может быть чревато боком.

У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
Что-то больше мне не хочется называться Anotheroneuser-ом :)

Anotheroneuser> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
Anotheroneuser> Что-то больше мне не хочется называться Anotheroneuser-ом :)

Лучше попросить своего сисопа переименовать тебя. Потому что ты здесь это не только ник, но и адрес =)

> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
> Что-то больше мне не хочется называться Anotheroneuser-ом :)

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

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

Короче, по-новой зарегистрируюсь.

>> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
>> Что-то больше мне не хочется называться Anotheroneuser-ом :)
Peter> Могу попробовать просто заменить имя в конфиге. но если честно - я точно не помню, считается ли хеш по имени в тч или нет. Так что ничего страшного в том, чтоб новый акк сделать -- не вижу.

Хеш может быть любым.

> Хеш может быть любым.
Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало. Может быть, ты и прав, но проверить я сейчас не смогу.
В принципе, стоимость поддержки аккаунта нулевая, так что новый аккаунт это не страшно. )

>> Хеш может быть любым.
Peter> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало. Может быть, ты и прав, но проверить я сейчас не смогу.
Peter> В принципе, стоимость поддержки аккаунта нулевая, так что новый аккаунт это не страшно. )

Ну пока нет лички да =)

> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало
gk11.ru уже год, как лежит :(.

>> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало
> gk11.ru уже год, как лежит :(.

Это да... :(

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

На днях обновил nginx, и клиент перестал пускать на станцию мира, хотя в браузерах всё хорошо работало.

Ошибка заключалась в обновлении протоколов SSL у nginx и в невозможности старого https-клиента netcipher (который в составе IDEC Mobile) с ним работать. Итого я прописал в клиенте свежую версию netcipher, и всё заработало

Просьба обновиться

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

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

Мне-то ещё ладно, но люди ведь всерьёз воспринимают. Ещё и поверят, небось.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

AL> Здравый смысл подсказывает мне, что как минимум ":" стоит запретить, так как это может быть чревато боком.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> Прочитал книженцию полностью. Есть там годные и интересные мысли, однако под конец автор вообще всё запорол.
vit01> Особенно ту часть с доктором конспирологом-ВИЧ-диссидентом (приводящим совершенно идиотские аргументы), ну и потом многочисленные нападки на "извращуг" со стороны автора и форсирование "традиционных ценностей", от которых уже тошнить начинает.
vit01> Мне-то ещё ладно, но люди ведь всерьёз воспринимают. Ещё и поверят, небось.
vit01> А, и да, какие-то остаточные кусочки религиозного мировоззрения там всё-таки присутствуют в высказываниях персонажей.

На самом деле это что-то из разряда х/ф. "Yes man" же =)

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

Я опять проморгал движухху на freenom. Они теперь не пускают по github'овскому аккаунту. Так что перенастраивайте фетчеры на сабж на адрес http://idec.spline-online.tk/ я вернул старый домен себе.

> Так что перенастраивайте фетчеры на сабж на адрес idec.spline-online.tk я вернул старый домен себе
Done

Готово. Надо потом и документацию обновить

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Давненько уже я начал работу над сабжем, но некоторые события жизни и длинный отпуск существенно замедлили события. Сегодня я, вроде как, закончил вчерне всё. Доступно это добро тут https://gitlab.com/spline1986/idec

Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)

AL> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
Сделал ПР.

Замечания:
* Не импортируй звездочки из модулей
* Форматирование строк через % устарело
* PEP8

+++ At work. idec.el/0.1

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
Difrex> Сделал ПР.
Difrex> Замечания:
Difrex> * Не импортируй звездочки из модулей
Difrex> * Форматирование строк через % устарело
Difrex> * PEP8

Спасибо. Разберусь что к чему и смержусь/пофикшу.

Пора уже действительно писать как для людей, а не как для себя =)

И еще. Генерация authstring в points.txt отстой.
Т.к. зная имя пользователя, мы всегда можем получить его строку авторизации.

Сделал ПР.

+++ At work. idec.el/0.1

Клуб теперь работает не только по http, но и по https.

Difrex> И еще. Генерация authstring в points.txt отстой.
Difrex> Т.к. зная имя пользователя, мы всегда можем получить его строку авторизации.
Difrex> Сделал ПР.

А вот это по существу уже совсем. Спасибо.

Difrex> Сделал ПР.

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

> Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)
Ок, по стилю :)

Общие рекомендации:

* Код должен быть по PEP8.
* Хорошо бы иметь краткий докстринг в каждой функции -- это полезно, для того, чтобы
сразу понимать, что эта функция делает, для показа доков в Емаксе и для автогенерации
документации на код в том же Sphynx. У меня, например, настроена CI так, что ПР, где
нет докстрингов, не принимаются.
* Никогда не импортировать * из модулей.
* Не переопределять имена функций в переменные. Что я имею в виду:
В файле points.py(а возможно и в других, не копал еще сильно) есть функция `hsh()',
которая генерирует authstring. Так вот в нескольких других местах ты создаешь строковые
переменные с таким же именем. Это может привести к неочевидным последствиям.
Пример:

def h(x):
    return x * x


def some_method(func):
    val = get_val_from_rest_api()
    return func(val)


if __name__ == "__main__":
    h = "Template: {}"
    # Тут дальше идет какая-то логика
    # А под конец хотим вызвать какой-либо метод передав в него
    some_method(h
    # Получаем исключение, т.к. вместо функции мы передали строку

* Использование python-black по желанию -- это бескомпромиссный форматировщик кода.
Работает четко и круто.

Как облегчить себе жизнь и ваще не париться по поводу стиля:
Ставишь из своих репов autopep8, flake8, python-black, pip.
Настраиваешь Емакс: https://paste.lessmore.pw/hojecuqece.lisp

Теперь всю работу по форматированию кода, а так же комплиту, прыжкам в методы, и.т.д будет делать
за тебя GNU Emacs :)

+++ At work. idec.el/0.1

>> Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)
Difrex> Ок, по стилю :)
Difrex> Общие рекомендации:
Difrex> * Код должен быть по PEP8.

Уже переделал этот момент.

Difrex> * Хорошо бы иметь краткий докстринг в каждой функции -- это полезно, для того, чтобы
Difrex> сразу понимать, что эта функция делает, для показа доков в Емаксе и для автогенерации
Difrex> документации на код в том же Sphynx. У меня, например, настроена CI так, что ПР, где
Difrex> нет докстрингов, не принимаются.

Это у меня в TODO было давно =)

Difrex> * Никогда не импортировать * из модулей.

Да. Я уже усвоил это. Если импортировать только нужное, то получается гораздо нагляднее и безопаснее.

Difrex> * Не переопределять имена функций в переменные. Что я имею в виду:
Difrex> В файле points.py(а возможно и в других, не копал еще сильно) есть функция `hsh()',
Difrex> которая генерирует authstring. Так вот в нескольких других местах ты создаешь строковые
Difrex> переменные с таким же именем. Это может привести к неочевидным последствиям.

Этот момент я ещё не проработал, но ошибка весьма очевидна, если подумать. Спасибо =)

Difrex> * Использование python-black по желанию -- это бескомпромиссный форматировщик кода.
Difrex> Работает четко и круто.

Пока я просто прогнал все файлы через pep8 и исправил все замечания. Ну и форматирование исправил с оператора форматирование на метод форматирования. Правда пока не тестировал чего я там наделал, зато исправил пару критичных багов попутно =)

Difrex> Как облегчить себе жизнь и ваще не париться по поводу стиля:
Difrex> Ставишь из своих репов autopep8, flake8, python-black, pip.
Difrex> Настраиваешь Емакс: https://paste.lessmore.pw/hojecuqece.lisp
Difrex> Теперь всю работу по форматированию кода, а так же комплиту, прыжкам в методы, и.т.д будет делать
Difrex> за тебя GNU Emacs :)

Как раз собирался гуглить как это сделать. GNU Emacs это сила =)

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

Тут интересуются, почему в плеймаркете нет твоего клиента. :) Действительно, почему? Может уже пора начать захватывать мир? Только регистрацию бы попроще сделать...

Я только за!

Peter> Тут интересуются, почему в плеймаркете нет твоего клиента. :) Действительно, почему? Может уже пора начать захватывать мир? Только регистрацию бы попроще сделать...

Для этого есть несколько проблем

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

2. В клиенте есть некоторые баги, которые до сих пор фиг знает как чинить, и для новичков они будут доставлять дискомфорт. Ещё есть недоработки в UI. См. Projects на Гитхабе. Ещё для финальной версии нужна поддержка шифрования, которую мне до сих пор лень делать.

3. Нет нормального хэлпа внутри клиента и некоторого "вступительного экрана". Но с этим вы можете помочь

4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

5. Нетмейл. Все про него постоянно спрашивают

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег
Думаю, что мы можем задонатить =)

> 5. Нетмейл. Все про него постоянно спрашивают
Продолжу писать стандарт на следующей неделе.

vit01> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

Дополнительно можно в F-droid выложить. Могу с этим помочь.

Новый комментарий от пользователя Difrex
к задаче "Описание формата бандла" https://github.com/idec-net/netmail/issues/6.
Оставлен 2019-07-21 07:43:30 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/6#issuecomment-513531557

Вроде, как описание в мастере. Возражений нет.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание формата сообщения на отправку" https://github.com/idec-net/netmail/issues/7.
Оставлен 2019-07-21 07:43:48 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/7#issuecomment-513531576

В мастере.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Node 2 node initial" https://github.com/idec-net/netmail/pull/8.
Оставлен 2019-07-21 09:51:13 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/8#issuecomment-513539603

В таком виде ок?

Не уверен только на счет нужности получения колличества сообщений.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

vit01>> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

btimofeev> Дополнительно можно в F-droid выложить. Могу с этим помочь.

Думаю, что F-Droid - это всё-таки наша первоначальная цель. Потому что это более "элитный" стор.

Difrex> Думаю, что мы можем задонатить =)

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

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

Ещё у меня на 9 андроиде после перезагрузки системы клиент падает с вот таким эксепшеном:

06-20 10:27:41.475 I/it01.idecmobil( 7793): Late-enabling -Xcheck:jni
06-20 10:27:41.976 I/Perf ( 7793): Connecting to perf service.
06-20 10:27:42.579 I/ACRA ( 7793): ACRA is enabled for vit01.idecmobile, initializing...
06-20 10:27:42.878 I/it01.idecmobile( 7793): type=1400 audit(0.0:101): avc: denied { getattr } for path="/data/data/com.android.keychain" dev="dm-0" ino=111211 scontext=u:r:untrusted_app:s0:c140,c256,c512,c768 tcontext=u:object_r:system_app_data_file:s0 tclass=dir permissive=1
06-20 10:27:42.888 W/it01.idecmobil( 7793): Accessing hidden method Landroid/security/IKeyChainService$Stub;-><init>()V (dark greylist, linking)
06-20 10:27:42.889 D/AndroidRuntime( 7793): Shutting down VM
--------- beginning of crash
06-20 10:27:42.893 E/AndroidRuntime( 7793): FATAL EXCEPTION: main
06-20 10:27:42.893 E/AndroidRuntime( 7793): Process: vit01.idecmobile, PID: 7793
06-20 10:27:42.893 E/AndroidRuntime( 7793): java.lang.NoSuchMethodError: No direct method <init>()V in class Landroid/security/IKeyChainService$Stub; or its super classes (declaration of 'android.security.IKeyChainService$Stub' appears in /system/framework/framework.jar!classes2.dex)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.keychain.KeyChainService$1.<init>(KeyChainService.java:95)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.keychain.KeyChainService.<init>(KeyChainService.java:95)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at java.lang.Class.newInstance(Native Method)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:103)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3554)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.access$1300(ActivityThread.java:202)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1674)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.os.Handler.dispatchMessage(Handler.java:106)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.os.Looper.loop(Looper.java:193)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.main(ActivityThread.java:6744)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at java.lang.reflect.Method.invoke(Native Method)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:859)
06-20 10:27:42.913 E/ACRA ( 7793): ACRA caught a NoSuchMethodError for vit01.idecmobile
06-20 10:27:42.913 E/ACRA ( 7793): java.lang.NoSuchMethodError: No direct method <init>()V in class Landroid/security/IKeyChainService$Stub; or its super classes (declaration of 'android.security.IKeyChainService$Stub' appears in /system/framework/framework.jar!classes2.dex)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.keychain.KeyChainService$1.<init>(KeyChainService.java:95)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.keychain.KeyChainService.<init>(KeyChainService.java:95)
06-20 10:27:42.913 E/ACRA ( 7793): at java.lang.Class.newInstance(Native Method)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:103)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3554)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.access$1300(ActivityThread.java:202)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1674)
06-20 10:27:42.913 E/ACRA ( 7793): at android.os.Handler.dispatchMessage(Handler.java:106)
06-20 10:27:42.913 E/ACRA ( 7793): at android.os.Looper.loop(Looper.java:193)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.main(ActivityThread.java:6744)
06-20 10:27:42.913 E/ACRA ( 7793): at java.lang.reflect.Method.invoke(Native Method)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:859)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Много чего доделал и доработал в сабже. Также написал простенький idec-txt под шумок. И переписал скрипт отсылки файлов в фэхи.

Всё это лежит вот тут:

* https://gitlab.com/spline1986/idec - эталонная нода;
* https://gitlab.com/spline1986/idec-txt - скрипт для отпрафки файлов в фэхи;
* https://gitlab.com/spline1986/idec-utils - тут я собираюсь возродить свои скрипты для idec, но пока тут только скрипт для отправки файлов.

Если есть желание и время, буду признателен, если потестируете или сделаете замечания по README хотя бы =)

PS: Да. Докстринги я до сих пор не прописал. Это на очереди.

Теперь idec-txt поддерживает слайсы. Вроде как, теперь он вполне себе POC клиентской части полноценный.

> сделаете замечания
filter() - это встроенная функция python.

Т.е. делая так

from api import filter

Ты ее переопределяешь.

>> сделаете замечания
Difrex> filter() - это встроенная функция python.
Difrex> Т.е. делая так
Difrex> ====
Difrex> from api import filter
Difrex> ====
Difrex> Ты ее переопределяешь.

Спасибо. Переделаю.

Обратился ко мне по емейлу якобы владелец одного сайтеца, просит удалить ссылки с архива на alicorn.tk

Hi there,

I’m working on cleaning the website adaptavist . com, and I need your help in removing some links from your site. Your site is probably perfectly legitimate, but I’m just trying to eliminate as many links as possible.

I’m asking this because it’s come to our attention that some of the links to our website have been acquired against Google’s Webmaster Guidelines, so it’s important for us to remove links that are harming traffic to our website. Furthermore, by linking to our site, it could be detrimental to your site’s overall traffic, so it will be important for you to remove the link.

Here are some examples:

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK
Link text: ... (убрано мной, чтобы снова их скрипт не сработал)
Page on our site: ...

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK
Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK&reply

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK&reply
Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=1

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=1

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=88

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=88

The link(s) need to be actually removed, rather than just disavowed. Even if they are “nofollow,” I’d still like them to be removed.

Please let me know if you have any questions. If you could email me once you have removed the link that would be great.

Thanks in advance! I hope to hear from you soon.

Kind Regards,

Adaptavist Webmaster

Мой ответ этим товарищам был вот такой:

These links which were mentioned by you, are actually from annotations of archived posts of the Habrahabr website
 
The traffic which comes to your website, is primarily caused by this habrahabr post: https://habr.com/ru/company/billing/blog/271805/ (for example)
 
We can try to get rid of those links, but it's just an archive of short abstracts from the "real" articles. So, I just wanted to make it clear why are you worried about them and if you contacted the author of the original habrahabr article

Что может посоветовать в этой ситуации многоуважаемый All?

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Меня видно?

Видно, видно

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Вижу тебя.

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

+++ At work. idec.el/0.1

vit01> Видно, видно

Спасибо. Переехал на новое железо и не был уверен, что фетчер адвокатно отрабатывает.

AL> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)

Слабая валидация POST данных. Особенно на тех же файловых эхах

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

Мои пожелания:

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

// все блэклисты и изменяемые конфиги полностью туда

К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

2. Объединить cli-скрипты в единый интерфейс и запускать вроде

idec.py run
idec.py points add Vasya
idec.py stats -f ... -t ...
idec.py stats --help

3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один

https://docs.python.org/3/library/argparse.html

4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Попытался запустить на рабочем сервере своём ii-net.tk и обломался, потому что там проставлен HSTS, и браузер ни в какую не хочет пускать по обычному http, форсируя защищённое соединение.

Нужна поддержка сертификатов.

В той же Gitea всё это продумано до мелочей, хз, как с этим bottle себя ведёт.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
vit01> Слабая валидация POST данных. Особенно на тех же файловых эхах

Непонятно что именно не так =)

vit01> Способ хранения индексов вместе с файлами в фэхах меня тоже немного удивил. Можно попробовать в качестве атаки ввести фэху index и загрузить там файл с названием другой фэхи, тем самым легко затерев всё содержимое последней.

Можешь привести пример?

vit01> Мои пожелания:
vit01> 1. Складывать все конфиги, файлы, относящиеся к эхам и файлэхам, в отдельный каталог вроде "data"

На боевой реализации конфиги вообще в БД будут

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

В БД всё.

vit01> К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

Зачем ускорять развёртывание эталонной реализации. Это же по факту POC.

vit01> 2. Объединить cli-скрипты в единый интерфейс и запускать вроде
vit01> ====
vit01> idec.py run
vit01> idec.py points add Vasya
vit01> idec.py stats -f ... -t ...
vit01> idec.py stats --help
vit01> ====

Нет смысла. Это усложнит чтение исходного кода.

vit01> 3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один
vit01> https://docs.python.org/3/library/argparse.html

Про это я пока у Лутца не читал =)

vit01> 4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

Нет смысла в эталонной реализации. Как и вебморда не нужна.

vit01> Попытался запустить на рабочем сервере своём ii-net.tk и обломался, потому что там проставлен HSTS, и браузер ни в какую не хочет пускать по обычному http, форсируя защищённое соединение.
vit01> Нужна поддержка сертификатов.
vit01> В той же Gitea всё это продумано до мелочей, хз, как с этим bottle себя ведёт.

Зачем это эталонной реализации? Кто-то будет её юзать в боевых условиях?

Сабж!

Пока только вытаскиваются треды за последние 30 дней. Но в скором времени появится паджинация и прочие плюшки.

Заценить можно тут: https://dynamic.lessmore.pw/forum

Жду отзывов :)

> Заценить можно тут: https://dynamic.lessmore.pw/forum
> Жду отзывов :)

Вообще, мне нравится. А регистрация есть у тебя?
Заметил, если включить список эх слева, а потом нажать "меню", то меню появляется ПОД списком эх.

> Вообще, мне нравится. А регистрация есть у тебя?
Пока только по почте, но планируется. Я просто API для реги не допилил :)

> Заметил, если включить список эх слева, а потом нажать "меню", то меню появляется ПОД списком эх.
Прикольно, спасибо за репорт - пофикшу :)

Difrex> Заценить можно тут: https://dynamic.lessmore.pw/forum

Difrex> Жду отзывов :)

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

// И немного уменьшить шрифт для сабжа в списке, а то выбивается из дизайна и места занимает больше. Где-то до 16-18 пикселей

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Решил провести ревизию своих фетчеров и обнаружил кое-что:

1. На dynamic'e появился один msgid аномальной длины :)
2. API club.syscall.ru и таверны в /u/e запросах дописывают пустые строки после названий эх при попытке запросить эхи, которые отсутствуют у них в локальных базах. Но пустые строки пихать туда вообще нельзя

Наглядный тест: https://club.syscall.ru/u/e/test.1/test.2/ii.test.14/-2:2

3. Последние сообщения из ifhub.club мой фетчер упрямо не хочет сохранять в БД. Почему, пока не знаю

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

А у меня похоже банально кончилось место на хостинге. В этом была причина битых счетчиков. :( Надо что то думать.

> 2. API club.syscall.ru и таверны в /u/e запросах дописывают пустые строки после названий эх при попытке запросить эхи, которые отсутствуют у них в локальных базах. Но пустые строки пихать туда вообще нельзя

Вроде исправил, сейчас ок?

>> 2. API club.syscall.ru и таверны в /u/e запросах дописывают пустые строки после названий эх при попытке запросить эхи, которые отсутствуют у них в локальных базах. Но пустые строки пихать туда вообще нельзя

Peter> Вроде исправил, сейчас ок?

Да, сейчас норм всё

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Навел меня на мысли тред про мониторинг(и не только). А именно обсуждщение приватности метрик.

В общем, я открыл всем дашборд со статистикой сети,
доступен по ссылке https://grafana.lessmore.pw/d/vPKzlQKWk/idec?orgId=1

+++ At work. idec.el/0.1

Difrex> Навел меня на мысли тред про мониторинг(и не только). А именно обсуждщение приватности метрик.

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

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

Difrex> В общем, я открыл всем дашборд со статистикой сети, доступен по ссылке https://grafana.lessmore.pw/d/vPKzlQKWk/idec?orgId=1

Круто, конечно, но с графиками было бы ещё круче :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Планирую в ближайшем времени запустить ноду, ничего не изменилось в регламенте?! Поставишь в фетч, как будет готово?

jmaks> Планирую в ближайшем времени запустить ноду, ничего не изменилось в регламенте?! Поставишь в фетч, как будет готово?

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

jmaks> Планирую в ближайшем времени запустить ноду, ничего не изменилось в регламенте?! Поставишь в фетч, как будет готово?

Всё осталось как было. Отпишись сюда или мне куда-нить как будет готов узел и наладим связь.