С аватарками есть проблема. Как именно идентифицировать пользователя?
Сначала, я сделал по адресу. Потом по полю From. Оба решения не ахти.
Мне кажется, пока у нас нет отдельных register серверов, аватарки можно делать только кустарно-индивидуально. А так, мне тоже аватарки нравятся. )))

Новое на стенде: Появились ЛС! Как реализовано?

Эха, которая начинается с . (.private - на сервере). Это такая эха, в которой пользователь видит только свои сообщения, сообщения написанные ему и сообщения адресованные All

Такие эхи отдаются на фетч только по строке: /point/authstr/u/e/список эх

Список эх может включать не только приватные эхи, но и другие

В веб это смотрится довольно гармонично!

Итого, из моих планов -- осталось только шлифануть порефакторить и написать документацию :)

В общем, я поднял свою ноду - персональный арт-проект: http://hugeping.tk

Сейчас идёт синк с http://club.syscall.ru , но я буду его закрывать...
Прошу всех, кто с меня фетчит, переходить на http://hugeping.tk и отписаться о возникновении проблем.

Испытываю по живому. :)

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

Написал базовую документацию. На этом пока всё, буду потихоньку развивать ноду, но уже не так экстемально. :)

Если кого-то будут интересовать детали, расскажу или дополню доку.

https://github.com/gl00my/ii-go/blob/master/README.md

> @base64: имя файла - всё, что после этой строки берется как base64 аттач демка тут
Т.е. этот тег должен находится в конце тела сообщения?

> Прошу всех, кто с меня фетчит, переходить на hugeping.tk и отписаться о возникновении проблем.
Фетчу тебя. Пока все идет нормально.

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

> У тебя почему-то в топиках количество сообщений выводится на одно меньше, чем сообщений в топике на самом деле

Не заметил в чате.

Я специально вычитаю 1. Как это сделано на punbb форуме. Типа это ответы на пост. Не считая заголовок. 0 - нет ответов.

В принципе, фича, но можно поменять в коде....

hugeping> Я специально вычитаю 1. Как это сделано на punbb форуме. Типа это ответы на пост. Не считая заголовок. 0 - нет ответов.

hugeping> В принципе, фича, но можно поменять в коде....

Просто тогда в колонке это надо назвать не посты, а ответы, наверное.

> Просто тогда в колонке это надо назвать не посты, а ответы, наверное.

Согласен, завтра сделаю.

>> @base64: имя файла - всё, что после этой строки берется как base64 аттач демка тут
> Т.е. этот тег должен находится в конце тела сообщения?

Да. Все что после него это base64. Вообще, может быть стоит сделать по другому. Я сделал как было проще...

> Фетчу тебя. Пока все идет нормально.

Отлично! :)

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

Главное, чтобы в x/c правильно отображалось :)

> Главное, чтобы в x/c правильно отображалось :)

Очень надеюсь, что багов не будет. Хотя опыт показывает, что когда всё работает сразу, это означает наличие скрытых багов. :)

> Да. Все что после него это base64. Вообще, может быть стоит сделать по другому. Я сделал как было проще...

Вообще, я думал про начало/конец тега base64. И в веб версии это будет шикарно, в том числе и для картинок. Но если такое внедрять в консольные клиенты, всё-таки, одно сообщение - один base64 аттач - это более понятная и простая схема...

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

hugeping> В общем, я поднял свою ноду - персональный арт-проект: http://hugeping.tk
hugeping> Прошу всех, кто с меня фетчит, переходить на http://hugeping.tk и отписаться о возникновении проблем.

Так, я тут как всегда самый медленный по ответам. Фетч настроил на hugeping

С base64, спойлерами и остальным возитесь пока сами

Что касается гошной библиотеки и новой ноды как таковых:

1. Нужно всё-таки объединять усилия, приходить к некоторым компромиссам и пилить одну библиотеку на всех. А аргумент "хочу другую лицензию" хоть и имеет смысл на существование, но на благо проекта точно не пойдёт. Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

2. Лично мне хотелось бы не новой ноды, а нормального десктопного клиента. С избранными, с черновиками, с красивым современным интерфейсом. Прямо сейчас пишу сообщение с IDEC Mobile в андроид эмуляторе, и это некомфортно: нельзя менять размер окна, приходится писать не с клавиатуры, а с графического планшета (т.к. с русским языком тут проблемы), да и сам этот эмулятор занимает гигабайта 3. Пытался накидать похожий интерфейс на Qt+QML и залип из-за их сложности, пытался на Flutter (кстати, хорошая штука), но понял, что надо будет заморачиваться с базой данных, и отложил это дело. Потихоньку пытаюсь попиливать Python-библиотеку в приватном репозитории, чтобы реализовать какое-то подобие клиента на Jupyter Widgets, но прогресс идёт слабо


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

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> 1. Нужно всё-таки объединять усилия, приходить к некоторым компромиссам и пилить одну библиотеку на всех. А аргумент "хочу другую лицензию" хоть и имеет смысл на существование, но на благо проекта точно не пойдёт. Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

Лицензионные вопросы важны.

vit01> 2. Лично мне хотелось бы не новой ноды, а нормального десктопного клиента. С избранными, с черновиками, с красивым современным интерфейсом. Прямо сейчас пишу сообщение с IDEC Mobile в андроид эмуляторе, и это некомфортно: нельзя менять размер окна, приходится писать не с клавиатуры, а с графического планшета (т.к. с русским языком тут проблемы), да и сам этот эмулятор занимает гигабайта 3. Пытался накидать похожий интерфейс на Qt+QML и залип из-за их сложности, пытался на Flutter (кстати, хорошая штука), но понял, что надо будет заморачиваться с базой данных, и отложил это дело. Потихоньку пытаюсь попиливать Python-библиотеку в приватном репозитории, чтобы реализовать какое-то подобие клиента на Jupyter Widgets, но прогресс идёт слабо

Всё от того, что ты хочешь пальцетыкательный интерфейс на десктопе, что, очевидно, моветон.

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

Перепутал вкусовщину с объекьтивностью.
vit01> +++ GNU/Linux, Android, physics, MLP:FIM

> С base64, спойлерами и остальным возитесь пока сами

Так это относится только к Web части. С этим возятся поинты моей ноды.

> 1. Нужно всё-таки объединять усилия .... Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

Это не сработает. Мне нравится писать то, что мне нравится. Это наверное основная движущая сила "моего опенсорца". Но никто не мешает брать мой код, если он нужен. Мой замысел в принципе не компромиссный. Потому что я хотел сделать не "что-то усреднённо хорошее", а ноду своей мечты. И нода и либа и веб морда готовы - их можно просто брать и использовать, если нравится. Если нет - делать своё.

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

Шрифты вообще не заданы нигде. Никакие. Так что используется тот шрифт, что стоит у тебя в настройках. :)

P.S. Edited: 2020-09-12 17:48:59

Хотел было забрать блог difrex, но:

$ curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog
difrex.blog
error: Internal error

>> 1. Нужно всё-таки объединять усилия .... Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

hugeping> Это не сработает. Мне нравится писать то, что мне нравится. Это наверное основная движущая сила "моего опенсорца". Но никто не мешает брать мой код, если он нужен. Мой замысел в принципе не компромиссный. Потому что я хотел сделать не "что-то усреднённо хорошее", а ноду своей мечты. И нода и либа и веб морда готовы - их можно просто брать и использовать, если нравится. Если нет - делать своё.

Окей, вопрос в каком-то смысле исчерпан

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

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

Предлагаю прописать font-family: sans-serif в body-блок CSS-ки. Это сработает на всех платформах, и разница станет заметна невооружённым глазом. Попробуй хотя бы ради эксперимента

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>> 1. Нужно всё-таки объединять усилия, приходить к некоторым компромиссам и пилить одну библиотеку на всех. А аргумент "хочу другую лицензию" хоть и имеет смысл на существование, но на благо проекта точно не пойдёт. Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

AL> Лицензионные вопросы важны.

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

vit01>> 2. Лично мне хотелось бы не новой ноды, а нормального десктопного клиента. С избранными, с черновиками, с красивым современным интерфейсом...
AL> Всё от того, что ты хочешь пальцетыкательный интерфейс на десктопе, что, очевидно, моветон.

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

На Андроиде это хорошо сделано в стандартном емейл-приложении (или в GMail, где тот же интерфейс). На десктопе - Thunderbird, Apple Mail, Outlook, и.т.п. Просто в плане общения IDEC слишком похож на Email, чтобы избежать такого сравнения

vit01>> И да, шрифты говно. Не стал бы пользоваться новым интерфейсом просто из-за шрифтов с засечками. Так и людей распугать можно
AL> Перепутал вкусовщину с объективностью.

Это, конечно, грубо сказано было (и весьма в лоровском стиле, к сожалению), но тут тоже проблема просматривается и как раз объективная.

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

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

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

> Предлагаю прописать font-family: sans-serif в body-блок CSS-ки. Это сработает на всех платформах, и разница станет заметна невооружённым глазом. Попробуй хотя бы ради эксперимента

Вообще, я пробовал. Но тут такое дело. Я не хочу навязывать sans/sans-serif. Я сам из тех, кто долго верил в теорию вреда "шрифтов с засечками". А потом попробовал засечки, и мне понравилось. Поэтому я не хочу навязывать стиль шрифта. Пусть отображается дефултная настройка браузера. Те, если у тебя стоит в дефолте шрифты с засечками, ты их и увидишь. Есть вопрос с мобильными браузерами, там такой настройки нет... Ну, что поделать.

>>>> @repto вместо @Repto
Difrex>>> Разве у нас в стандарте с большой буквы прописано? В тех же iing и ii-php реализованно с маленькой.
vit01>> Всегда было с маленькой. Глянул в документацию - оказалось, что Github стал неправильно рендерить Markdown, и там отображается с большой, хотя в исходнике осталось всё как надо

Наконец-то исправил, чтобы норм отображалось.

>>>> StdBASE64 вместо URLBase64 в get запросе
Difrex>>> Там ескейпится потом. Не помню уже почему именно так сделано было.
vit01>> Для кодирования самого сообщения вроде как раз urlbase64 и используется. Для хэшей же идёт полная подмена символов, чтобы избежать знаков препинания

AL> Из документации это не следует никоим образом.

Цитирую: https://ii-net.tk/idec-doc/?p=standarts

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

> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.

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

>> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.

Это про msgid речь же. А вопрос вроде касался того, в каком формате поинт шлёт бандл на ноду (POST или GET, не важно). И в каком формате отдают/получают бандлы ноды.

В стандарте есть такая фраза: (все серверы обязаны принимать как обычный, так и urlsafe-словарь, генерируются же бандлы в формате обычного base64)

Для меня эта фраза непонятна. Бандлы вроде в обычном base64, но принимать я должен в любом? Надо детектить тип base?

Я так и не понял, в каком варианте base64 я должен принимать и отдавать бандлы нодам и принимать бандлы от юзера. В итоге имеем такие варианты:

Мой:
1) Я принимаю и отдаю нодам бандлы в обычном base64 (не считая msgid, который подвергается преобразованию описанному в стандарте)

2) принимаю post/get запросы от поинтов в urlsafe base64

И вроде это работает, по крайней мере со станцией Андрея.

difrex:

1) принимает от поинтов обычный base64 но предварительно заэскейпченный

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

hugeping> Это про msgid речь же. А вопрос вроде касался того, в каком формате поинт шлёт бандл на ноду (POST или GET, не важно). И в каком формате отдают/получают бандлы ноды.

Для поинтов политика такая: если пересылает через GET, значит обязательно urlsafe. Если через POST, то поинт может выбрать любой вариант, какой захочет, ведь нода обязана поддерживать и тот, и другой

hugeping> В стандарте есть такая фраза: (все серверы обязаны принимать как обычный, так и urlsafe-словарь, генерируются же бандлы в формате обычного base64)

hugeping> Для меня эта фраза непонятна. Бандлы вроде в обычном base64, но принимать я должен в любом? Надо детектить тип base?

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

То есть ещё раз: принимать нужно оба формата одновременно, но генерировать на отдачу желательно (как необязательная рекомендация) в обычном base64

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

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

Можно этот момент описать подробнее. Каким алгоритмом base64 декодировать и что на что заменять? Я немного посмотрел, разница в стандартах base64 не такая маленькая, как мне показалось, чтобы решить её заменой. Но похоже, я ошибся.

Можно рассказать алгоритм?

Достаточно ли замены:

msg = strings.Replace(msg, "-", "+", -1) /* if it is URL base64 */
msg = strings.Replace(msg, "_", "/", -1) /* make it base64 */

И потом декодировать стандартным base64? Но там вроде еще есть заполнение в виде ===?

Хм. Это я сломал что-то в базовом протоколе :).

Работает только со смещением сейчас

curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog/-250:250
difrex.blog
2fDZ67P8JkchA9Rh4If4
2NszlFTgvhakzz7dIfvc
ML8cpSyzyOKaFA6Lx1NF
8TtPHu5T7oo3GSXdDYc5
U6ZYZxgYz2sq01L96zZz
igt9lCsui5qE9AICtdgP
mTWsJXVOAljita3sgDOK
V0hj3Z0QjFxpluaaiKvI
b91aGfRgRLJWfB1q60bg
pNfzXBddGbSy7AW7slpz
4fmEizz5kjk4UcQf7VIJ
OxdmEiQJIZqrqjCUNp2i
ojRAXNp7wzVIF9GBetZn
z5UV57mUeyhAmFsaMUq0

Спасибо, поправлю.

Fixed

> Fixed
Теперь есть другая проблема. Возможно, с моим фетчером.
В выводе у тебя нет последнего перевода строки. То-есть, на запрос -1:1, к примеру, приходит MsgId без \n. Как к этому относиться? Нужно ли мне переделывать?

hugeping> Достаточно ли замены:
hugeping> ====
hugeping> msg = strings.Replace(msg, "-", "+", -1) /* if it is URL base64 */
hugeping> msg = strings.Replace(msg, "_", "/", -1) /* make it base64 */
hugeping> ====
hugeping> И потом декодировать стандартным base64? Но там вроде еще есть заполнение в виде ===?

Должно быть достаточно. А заполнение как было знаками равно, так и должно вроде как остаться таковым

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

Хм, вот про newline в конце интересно. Это у нас нигде не описано, но и проблем ни у кого не возникало

> Хм, вот про newline в конце интересно. Это у нас нигде не описано, но и проблем ни у кого не возникало

Нужно решение комитета. )
Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный. Заметил только благодаря адаптивному фетчу, который делает пробы по 1 id. Так бы просто последнее сообщение бы не взял и всё.

> Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный.
А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

messages := make(map[string][]string)
echoList := strings.Split(getBody(resp.Body))
var currentEcho string
for i := range echoList {
  if echoList[i] == "" {
    continue
  }
  if isEcho(echoList[i]) {
    currentEcho = echoList[i]
  }
  if isMessage(echoList[i]) {
    messages[currentEcho] = append(messages[currentEcho], echoList[i])
  }
}

> А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

Почему так, вопрос, который я тоже могу задать: "Разве ты не делаешь просто Printf каждого из id? Зачем вырезать последний \n?

Дело в том, что я старался писать строго. Строка с переводом строки - это однозаначность. Например, пустая строка - это тоже пустая строка и \n.

В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?

Например, вот функция, которая используется везде при работе с сетью:

func http_req_lines(url string, fn func(string) bool) error {
	resp, err := http.Get(url)
	if err != nil {
		return err
	}
	defer resp.Body.Close()
	reader := bufio.NewReader(resp.Body)
	for {
		line, err := reader.ReadString('\n')
		if err != nil && err != io.EOF {
			return err
		}
		line = strings.TrimSuffix(line, "\n")
		if err == io.EOF {
			break
		}
		if !fn(line) {
			break
		}
	}
	return nil
}

Обрати внимание, что if err === io.EOF стоит ПЕРЕД fn(line).

А вот правка, чтоб сработало с твоей нодой:

                if err == io.EOF {

			if line != "" { /* no eol in last line? broken node? */
				fn(line)
			}
                        break
                 }

Если же я перенесу fn(line) перед err == io.EOF, то fn(line) будет вызываться для последнего \n у других нод, которые делают \n в каждой строке.

Я лично считаю, что \n быть должен, но в как бы мы не решили, это должно быть прописано в стандарте, кмк.

Ну, в общем давай подождем остальных, что скажут. По мне так '\n' в конце списка эх необязателен, т.к. не относится к данным.

Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

Но в случае чего, я могу добавить перенос строки.

> В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?
Это справедливо только для имен эх, а вот id сообщения всегда можно понять прочитался ли он полностью.

> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

Мой довод, в основном, будет таким.

В UNIX все текстовые файлы традиционно заканчиваются на \n.

https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

Стандарт POSIX определяет строку так:

> 3.206 Line
> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Зафиксируем это и не ошибёмся. :)

Difrex> Ну, в общем давай подождем остальных, что скажут. По мне так '\n' в конце списка эх необязателен, т.к. не относится к данным.

'\n' в конце это однозначное и ожидаемое поведение. Мне кажется, что делать стоит единообразно. У меня даже emacs в файлах в конце '\n' ставит :)

Difrex> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

В стандарте вроде про newline ничего не сказано, поэтому предусматривается, что "\n" - это лишь разделитель списка, и в конце он необязателен

В нодах и клиентах принято использовать логику, по которой принимают и то, и другое. Но, думаю, для лучшей совместимости с unix-утилитами стоит явно закрепить в стандарте, чтобы newline в конце присутствовал

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

> У меня даже emacs в файлах в конце '\n' ставит :)
У меня тоже. Но это все таки данные не совсем для человека.

Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

// Newline в конце добавлю, но фетчер у меня умеет и так и так.

> У меня тоже. Но это все таки данные не совсем для человека.

Ну как, curl можно автоматизировать. Я так и делал, когда переносил данные с ноды, генерировал скриптом запросы, парсил вывод. Удобнее с \n это делать.

> Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

Лучше я промолчу о том, что я делаю с сообщением поинта, а то вы меня тут заклюёте =)

> // Newline в конце добавлю, но фетчер у меня умеет и так и так.

Угу, отпишись тогда, я от тебя хочу взять fetch difrex.blog (ну и назад забирай тогда её у меня =)

Сделал исправление тоже, поставил на тебя фетч (blog.difrex). Ожидаю взаимного фетча. ;)

Пофиксил, фетчу тебя :)

Меня убедили начать комментировать код. :)

Так что постепенно буду это делать. На данный момент описал функции в msg.go -- это базовые функции для манипуляции бандлами (decode/encode) и приём сообщений от поинтов.

https://github.com/gl00my/ii-go/blob/master/ii/msg.go

hugeping> Меня убедили начать комментировать код. :)

hugeping> Так что постепенно буду это делать. На данный момент описал функции в msg.go -- это базовые функции для манипуляции бандлами (decode/encode) и приём сообщений от поинтов.

Ну что я могу сказать? Хоть я и был среди убеждающих, ты подал хороший пример всем нам. Надо будет заняться документированием idec-client :)

Заметил довольно большой расход заряда - чуть больше 6% на дефолтных настройках.

johnbrown> Заметил довольно большой расход заряда - чуть больше 6% на дефолтных настройках.

Просьба отписаться всем остальным, кто пользуется клиентом, каков расход батареи

ну и доп. инфа, что за мобила, какая версия ОС и.т.п.

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

vit01> Просьба отписаться всем остальным, кто пользуется клиентом, каков расход батареи
Расхода нет.
vit01> ну и доп. инфа, что за мобила, какая версия ОС и.т.п.
SM-n900, Android 7.1.2, LineageOS-14.1-20200911-unofficial-ha3g

Там от меня ушли 7 сообщений из черновиков/неотправленных? мобильного клиента... Нужно их блеклистить:

ii://2NszlFTgvhakzz7dIfvc
ii://Q03NcPZRuqeaOT5d6Tze
ii://v48ZAPJMiFbWl68YiFWU
ii://5JdRzlDtEJTfOtKCtTb4
ii://pEtdZQ4aPz7SAhFK3zwR
ii://SglNQOG3vyujcZLXjDtu
ii://flYuqUgR5SVgybdnYnVp

Извините. :)