vit01> ]...] приложение не запускалась на ОС версий ниже 4.4

А такие девайсы у кого-то ещё остались и ими реально пользуются? У меня телефону 4 года, на нем сейчас андроид 6. Разве кто-то ещё с более старыми ходит?

vit01>> ]...] приложение не запускалась на ОС версий ниже 4.4

btimofeev> А такие девайсы у кого-то ещё остались и ими реально пользуются? У меня телефону 4 года, на нем сейчас андроид 6. Разве кто-то ещё с более старыми ходит?

Вышеописанный баг я починил, потому что кто-то мне на него пожаловался по емейлу. Иначе бы не узнал, что эта проблема существует.

А вообще у меня одногруппник есть в универе, который до сих пор ходит с мобилкой то ли на 4.2, то ли даже версии ниже (всеми любимый Телеграм там не пашет, дропнули поддержку). Работает девайс, а выбрасывать-то жалко. И есть другой чел, но у него 4.4

У самого вон планшет старый на 4.4 трудится до сих пор. Вот кого не видел - так это людей, пользующихся андроидом 2.3. Их точно у нас не повстречаешь уже. Но приложение на таких изначально и не нацеливалось.

+++ Sent from Android 4.2 (Emulator)

У меня Note 3 под 5-м Андроидом. Было раз, накатил прежний выпуск (Kit Kat), но потом вернул всё взад.

Поставил себе недавно 8 андроид наконец-то
Скоро будет фикс уведомлений и автофетча для IDEC Mobile

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

Попробовал починить падения и что-то сделать с уведомлениями в андроиде 8 и выше.

Надеюсь, оно будет хоть как-то работать. Качайте свежую сборку, тестируйте

Обнаружил одну очевидную проблему.
Если ввести в поиск по ключевым словам IDEC Mobile или Android, то будут выдаваться все сообщения, которые не относятся ни к тому, ни к другому.

Потому что подписи.

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

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

vit01, я тебе отправил пулл реквест с фиксами на андроид 9. Если есть возможность протестируй на предыдущих версиях, особенно на 4.* так как новая ACRA требует java 8, а она может не работать на старых устройствах.

ii-net.tk что-то недоступен.

btimofeev> ii-net.tk что-то недоступен.

Была проблема у хостера опять

Из-за переполнения /boot при очередном обновлении ядра скрипты системы не смогли сгенерировать initramfs, из-за чего система не загрузилась при следующем ребуте

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

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

vit01>> Надо как-то сделать так, чтобы поиск игнорировал это дело.

Difrex> Нужно в софт наш весь добавить парсеры на предмет подписей и пихать их в отдельное поле в бд.
Difrex> С плоской базой просто так работать не будет, но таких нод, вроде, и не осталось.

Что до отдельного поля в БД, то это целесообразно только на клиентском софте. Ноды переусложнять необязательно.

Хотя поисковой движок, запущенный для нашей базы, есть только у тебя, поэтому тут всё зависит от простоты постановки такого условия в ElasticSearch.

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

vit01> Хотя поисковой движок, запущенный для нашей базы, есть только у тебя, поэтому тут всё зависит от простоты постановки такого условия в ElasticSearch.

Мне добавить в парсер это не сложно, нужно только время выкроить

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

$сабж

Вот этот вот http://idec.spline-online.ml/x/file/nodegraph.svg не актуален.


// Да, по каким-то причинам сообщения с dynamic не долетают до Таверны и Клуба. Можете посмотреть в логи, что там не так?

Difrex> Можете посмотреть в логи, что там не так?
Если ты скажешь как, посмотрю

Difrex> $сабж
Difrex> Вот этот вот http://idec.spline-online.ml/x/file/nodegraph.svg не актуален.
Актуализацией надо заниматься. У нас нет актуального нодлиста, так что пока что не могу построить актуальный граф.

Скиньте актуальные сегменты нодлиста тогда.

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

>Если ты скажешь как, посмотрю
Это скорее к держателям нод вопрос был =)

А. Ну я, как в "Приключениях Шурика":
— Песчаный карьер!
— Я!
))

Первый раз в жизни запустил mutt. Сказочные ощущения.
Правда, с gmail.
Google, оказывается, бдит. Причём, делает это довольно настырно.
Настроив конфиг, несколько раз пытался за-mutt-иться, но всякий раз программа высвечивала "регистрация не удалась".

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

На dynamic.lessmore.pw появилась возможность читать треды.

Строятся по repto, у каждого поста теперь есть topicid, вида
3ee870f3-be0c-4ea4-8a6d-b6c8ecd64dac.

Если мы перейти по ссылке https://dynamic.lessmore.pw/thread/3ee870f3-be0c-4ea4-8a6d-b6c8ecd64dac, то
можно будет читать тред с сортировкой по времени от старых к новым.

Чтобы попасть в тред нужно перейти по ссылке в сабже.

У каждого поста есть якорь с msgid, так что можно добавить #8EuhW1rxWVNQAcPxuxLn и перейти к нужному сообщению.
На самом деле, id уже проставляется в ссылке, но почему-то браузер не переходит куда надо.

:)

+++ At work. idec.el/0.1

А что случилось с сабжевой эхой? Уже почти месяц нет новостей. Могу натравить своего робота, если у тебя какие-либо проблемы с ним.

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

AL> Скиньте актуальные сегменты нодлиста тогда.

Фетчу таверну, инстед клуб и динамик, всё с интервалом в 10 минут

Остальное не менялось

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

AL> А что случилось с сабжевой эхой? Уже почти месяц нет новостей. Могу натравить своего робота, если у тебя какие-либо проблемы с ним.

Мне каждый день оттуда новости приходят. Может быть, ты подписался неправильно?

lor-opennet.17

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

Если вы видите это сообщение, значит ii-net.tk успешно переехал на новый сервер к немцам

Мне пришлось сильно задолбаться, чтобы проапгрейдить MySQL до версии 5.7 и php до 7.2

А ещё чтобы сменить lighttpd на nginx

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

AL> Актуализацией надо заниматься. У нас нет актуального нодлиста, так что пока что не могу построить актуальный граф.
AL> Скиньте актуальные сегменты нодлиста тогда.
Мой: https://dynamic.lessmore.pw/nodelist.json

+++ At work. idec.el/0.1

btimofeev> vit01, я тебе отправил пулл реквест с фиксами на андроид 9. Если есть возможность протестируй на предыдущих версиях, особенно на 4.* так как новая ACRA требует java 8, а она может не работать на старых устройствах.

См. https://github.com/idec-net/idec-mobile/pull/30

Провозился с этим делом и потом отложил в долгий ящик.

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

Новая сборка уже на сайте, можно обновляться.
И за сам факт пулл-реквеста спасибо

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

Мне кажется, что на Таверне что-то с фетчем. Мои сообщения, например, не доходят.

vit01> Если вы видите это сообщение, значит ii-net.tk успешно переехал на новый сервер к немцам
vit01> Мне пришлось сильно задолбаться, чтобы проапгрейдить MySQL до версии 5.7 и php до 7.2
vit01> А ещё чтобы сменить lighttpd на nginx

Вот где собака зарыта! Фетчер забирал сообщения с Мира по http. Мы месяц жили с поломанным линком.

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

>Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Вот это еще не особо нравится.

Со стороны клиента мне это видится так:

           +--------------+
           |              |
           | IDEC Client  |
   +------>|              |<------+
   |       +--------------+       |
   |                              |
 xdata tag                      message
   |                             data
   |                              |
   |                              v
 +-+-------------+      +-----------------+
 | /u/m/gkC...   |      | /x/d/gkC...     |
 |               |      |                 |
 +---------------+      +-----------------+

Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.

>> Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Difrex> Вот это еще не особо нравится.
Difrex> Со стороны клиента мне это видится так:
Difrex> ====
Difrex> +--------------+
Difrex> | |
Difrex> | IDEC Client |
Difrex> +------>| |<------+
Difrex> | +--------------+ |
Difrex> | |
Difrex> xdata tag message
Difrex> | data
Difrex> | |
Difrex> | v
Difrex> +-+-------------+ +-----------------+
Difrex> | /u/m/gkC... | | /x/d/gkC... |
Difrex> | | | |
Difrex> +---------------+ +-----------------+
Difrex> ====
Difrex> Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
Difrex> один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.

Зачем третий запрос? Клиент видит тэг, запрашивает все аттачи по этому тегу. Ему приходят они. В верхней квоте ни слова про третий запрос нет. И на схеме у тебя его нет.

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

>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>> Вот это не нравится. А если я не хочу все аттачи тянуть?
> Тогда просто игнорируешь тег и всё.
Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

>>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>>> Вот это не нравится. А если я не хочу все аттачи тянуть?
>> Тогда просто игнорируешь тег и всё.
Difrex> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

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

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

>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
>Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.
Но что-то делать с этим точно надо :)

Идея была все-таки вот в чем.
С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.

Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Ну как в современных мессенжерах. :)

А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.

Peter> Идея была все-таки вот в чем.
Peter> С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Peter> Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.
Peter> Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Peter> Ну как в современных мессенжерах. :)

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

Peter> А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.

Ну тут да. Можно подумать как и что пропускать. Можно метаданные передавать ещё к каждому блобу.

> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.
Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.

>> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.
Peter> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.

Вообще, я примерно так и думаю.

Например:

image:<filename>:<base64>
audio:<filename>:<base64>

А желание не пропустить информацию, ИМХО, противоречит самой цели секты.

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

Пример получения последних сообщений:

package main

import (
	"fmt"
	"time"

	idec "github.com/idec-net/go-idec"
)

func main() {
	fc := idec.FetchConfig{
		Node:   "https://dynamic.lessmore.pw/idec/",
		Echoes: []string{"pipe.2032", "idec.talks"},
		Offset: -3,
		Limit:  3,
	}
	ids, err := fc.GetMessagesIDS()
	if err != nil {
		panic(err)
	}
	msgs, err := fc.GetRawMessages(ids)
	if err != nil {
		panic(err)
	}
	for _, m := range msgs {
		msg, err := idec.ParseMessage(m.Message)
		if err != nil {
			panic(err)
		}
		fmt.Printf("Author: %s, Subg: %s, Date: %s\n", msg.From, msg.Subg, time.Unix(int64(msg.Timestamp), 0))
	}
}

Запуск

go run test.go
Author: Difrex, Subg: Re: idec, Date: 2019-03-04 11:56:06 +0300 +03
Author: Difrex, Subg: Re: idec, Date: 2019-03-04 11:21:04 +0300 +03
Author: Peter, Subg: Re: idec, Date: 2019-03-04 11:09:22 +0300 +03
Author: Andrew Lobanov, Subg: Re: Метадата, Date: 2019-03-03 08:25:10 +0300 +03
Author: Peter, Subg: Re: Метадата, Date: 2019-03-02 23:17:49 +0300 +03
Author: Andrew Lobanov, Subg: Re: Метадата, Date: 2019-03-02 20:02:04 +0300 +03

Коммитнул в сабж изменение своего мыла. Старое более недоступно.

Тоже добавил свое и мыло, а так же ссылку на idec.el.

AL> Коммитнул в сабж
Это значит, где-то опубликовал?
А где?
Я бы тоже хотел свой адрес оставить

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

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

Вот этот репозиторий: https://github.com/idec-net/netmail
Давайте обсуждать и дописывать.

+++ At work. idec.el/0.1

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> Сделал ПР.

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