Вот и до меня добралось. :)
В общем, пишу ноду на go.
Цели:
- никаких внешних зависимостей;
- экстремальная простота настройки и переноса базы;
- поддержка умного (адаптивного) fetch

На данный момент черновик ноды готов: https://github.com/gl00my/ii-go
Пока нет никакой морды, нет документации. Но решил показать что есть, вдруг кто-то pr накидает. ;)

Как посмотреть:

git clone https://github.com/gl00my/ii-go.git

cd ii-go/ii-tool
go build

./ii-tool fetch http://idec.spline-online.tk (полный фетч в 6 потоков всех эх (нужна поддержка list.txt), запускается только если видит, что база ноды изменилась, по наличию последнего сообщения)

./ii-tool -lim=-32 fetch http://idec.spline-online.tk (адаптивный фетч, спускается вглубь истории постепенно, по мере необходимости)

./ii-tool -lim=32 fetch https://club.syscall.ru (неадаптивный фетч, просто последние 32)

В конце можно указать файл с эхами или - для stdin

cat std.club | ./ii-tool -lim=32 fetch https://club.syscall.ru -

В итоге сольётся db и создастся db.idx - индекс. db - это просто бандл, и только этого файла достаточно, чтоб переносить базу.

можно теперь положить его к ноде:

mv db ../ii-node/
cd ../ii-node
go build
./ii-node - и запустить ноду на 8080

Теперь можно пофетчить с 127.0.0.1:8080 и позамерять скорость.

Ну и посылка сообщений тоже есть, см. -h

Увлекательное занятие, должен я сказать. :)

Это уже третья реализация годы на go будет :).

Опять предлагаю развивать библиотеку вместе: https://github.com/idec-net/go-idec

> Опять предлагаю развивать библиотеку вместе: https://github.com/idec-net/go-idec

Я с неё начал, сейчас фактически моя реализация покрывает твою. Почему я это сделал.

1) Хочу другую лицензию (MIT)
2) Нашел некоторые странности (@repto вместо @Repto, StdBASE64 вместо URLBase64 в get запросе, точно не помню, может ещё что-то по мелочи, типа Subg вместо Subj...
3) Наличие внешних зависимостей (противоречит моей цели)
4) Субъективно, хотелось простоты =)

> 1) Хочу другую лицензию (MIT)
На этом можно было и остановиться на самом деле :D GPL не хочу менять на MIT точно.

> @repto вместо @Repto
Разве у нас в стандарте с большой буквы прописано? В тех же iing и ii-php реализованно с маленькой.

> StdBASE64 вместо URLBase64 в get запросе
Там ескейпится потом. Не помню уже почему именно так сделано было.

> Subg вместо Subj
Это у меня исторически сложилось еще с perl клиента :)

> 3) Наличие внешних зависимостей (противоречит моей цели)
Хм, но там только одна внешняя зависимость и только для тестов - httpmock. Сама либа полностью на стандартной либе написана.

Но вообще ты меня подбил на то, чтобы почитать код go-idec :). Нашел несколько мест, которые можно определенно улучшить. Ну, и коверадж надо бы добить до 99% =)

> Разве у нас в стандарте с большой буквы прописано? В тех же iing и ii-php реализованно с маленькой.

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

> Хм, но там только одна внешняя зависимость и только для тестов - httpmock. Сама либа полностью на стандартной либе написана.

Угу, ошибся.

> Там ескейпится потом. Не помню уже почему именно так сделано было.

Да я видел. Я в итоге сделал всё таки urlsafe для get варианта.

>> @repto вместо @Repto
Difrex> Разве у нас в стандарте с большой буквы прописано? В тех же iing и ii-php реализованно с маленькой.

Всегда было с маленькой. Глянул в документацию - оказалось, что Github стал неправильно рендерить Markdown, и там отображается с большой, хотя в исходнике осталось всё как надо

>> StdBASE64 вместо URLBase64 в get запросе
Difrex> Там ескейпится потом. Не помню уже почему именно так сделано было.

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

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

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

Прикольно :)

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

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

> Глянул в документацию - оказалось, что Github стал неправильно рендерить Markdown, и там отображается с большой, хотя в исходнике осталось всё как надо
Походу дела нужно @ экранировать.

Что нового и вообще, что в ноде особенного на данный момент.

0) Ни одной внешней зависимости.
1) Вся база - это бандл. Бандлы легко мержить друг с другом, переносить и так далее. Индекс создается автоматически но он не является необходимым, так как при удалении создается заново автоматически.
2) Есть тулза для работы с базами если это понадобится
3) Нода - это фактически форум с видом по тредам
4) Можно редактировать сообщения. При этом ничего не меняется, а просто в базу добавляется новый вариант сообщения с тем же ID. Более актуальной считается всегда более новая версия. Blacklist делается так же.
5) Многопоточный фетчинг
6) Адаптивный фетчинг, это когда пробуем по одному сообщению с каким то шагом, постоянно умножая его на *2 и уходим в глубь до тех пор, пока не найдутся те сообщения, что у нас есть в базе. Например: -16:1 -32:1 -64:1 -128:1 (увидели, что сообщение есть в нашей базе!), Сделали: -128:128
7) Простая web морда, нормально выглядит и на мобильном и в eww
8) Никакого js!
9) Предпросмотр сообщений при редактировании и создании новых
10) Простота разворачивания

Продолжаю работать. То, что хочется сделать.

1) RSS
2) Возможно, активацию юзеров по почте или вручную
3) Карбонка
4) Поиск
5) Избранное

http://club.syscall.ru:8080 - демка для экспериментов,

На ii-go завезли котиков!

Не знаю зачем, но теперь в теле сообщения детектятся xpm. Как это выглядит - можно посмотреть на стенде. Можно постить котиков, но помните: лучше всего котика делать с 1 символом на цвет. (64-цветные палитры, например).

Котики тут: http://club.syscall.ru:8080/t5KocgBVCe3m37eRsXjd/1

Сырое сообщение, конечно, трэшовенько смотрится =)

Нормально смотрятся только небольшие. 32x32 или 64x64

Вот, например - ещё более менее: http://club.syscall.ru:8080/m/HUwMVOKfbms85NMXfkcy#HUwMVOKfbms85NMXfkcy

Короче, я на этом скоро сделаю аватарки :)

Прикрутил автатарки. Их можно загружать тоже в xpm и хранятся они в points.txt в текстовой форме.

http://club.syscall.ru:8080/IAXXN7yBVRqHzb9iG4Af/1

Я бы предложил это как-то стандартизировать в расширениях.
Можно добавить текстовые теги. Типа,

-*- xpm; -*-
static char * x_xpm[] = {
"32 32 17 1",
" 	c None",
".	c #18293E",
"+	c #112C39",
...
-*- xpm; -*-

Чтоб в клиентах можно было вырезать(или отрисовывать) это, например.

> Я бы предложил это как-то стандартизировать в расширениях.
> Можно добавить текстовые теги. Типа,

Я только за! Сейчас у меня такие _нестандартные_ теги:

1) @base64: имя файла - всё, что после этой строки берется как base64 аттач демка тут: http://club.syscall.ru:8080/jaHRwm0sPfK2w6n8jqhm#jaHRwm0sPfK2w6n8jqhm

2) @spoiler: строка - показать спойлер (В веб версии это реверс-строки и бледный цвет

3) XPM2 и XPM3 как есть воспринимаются, в соответствии с их форматом

@ мне нравятся, так как это аналог @repto:

Аватарки - это круть же! Может апи серверный какой придумать в расширениях, чтоб можно было постом аватарку пропихнуть на свою ноду?

-XPOST /x/avatar -d "pauth=authstring&xpm=$(echo "$XPM" | base64)"

Правда это небезопасная штука может быть.

С аватарками есть проблема. Как именно идентифицировать пользователя?
Сначала, я сделал по адресу. Потом по полю 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

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

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

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

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

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

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

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

>> 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? Но там вроде еще есть заполнение в виде ===?

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

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

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

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

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

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

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

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

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

Извините. :)

Кстати, не было повода, а тут вдруг вспомнил. Это чуть ли не единственный ресурс интернета, которым я пользуюсь, где толково реализован RSS. Ну просто идеально, даже клиент не нужен если не надо ничего писать. Чего не скажешь о различных форумах. В groups.google.com недавно поменяли интерфейс и окончательно испортили ленту, дата больше не обновляется и непрочитанные сообщения больше не видно :( К тому же там только первые несколько строк и из-за цитирования ничего не поймешь. На других форумах еще хуже. Там есть только первый пост в новой теме и все. Вот и на instead-games.ru/forum тоже.

А так хотелось все ресурсы объединить в одну ленту и сидеть как за штурвалом - все приборы обозревать одним взглядом с высоты капитанского кресла. Но видно не судьба. Вообще RSS явно нынче не в моде. Firefox еще раньше отказался его поддерживать, теперь пользуюсь newsboat.
P.S. Edited: 2020-12-04 22:22:38

vvs> А так хотелось все ресурсы объединить в одну ленту и сидеть как за штурвалом - все приборы обозревать одним взглядом с высоты капитанского кресла. Но видно не судьба. Вообще RSS явно нынче не в моде. Firefox еще раньше отказался его поддерживать, теперь пользуюсь newsboat.

Да. RSS нынче не в почёте. И теперь даже фиг знает как в idec заворачивать те ресурсы, где его нет и нет ему альтеративы. Только если писать сложные парсеры сайта на каждый ресурс отдельно. Но это сомнительное удовольствие.

AL> Да. RSS нынче не в почёте.

Видимо RSS заменили всплывающие уведомления от сайтов в браузере. Кто-нибудь использовал такое? Мне кажется начнется бардак если включить хотя бы на нескольких сайтах.