# Предложения или "Как нам обустроить idec?"
ake(ping,30) — All
2021-12-16 16:22:37


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

1. Правила перемаркировки эх. Идея простая - на ноду приходит сообщение (не важно, фетчится или от поинта) и, если у него в качестве эхи указано некое значение A, то оно заменяется на некоторое A* по определённому правилу. Самый очевидный вариант использования - "личные" эхи, один поинт отправляет сообщение в эху "sendmsg.username", в процессе оно перемаркируется, как "readmsg.username_authstr" и адресат его может получить. Ещё так можно укрупнять и агрегировать эхи, перемаркировывая сообщения из внешних "dev.c", "dev.cpp", "dev.python" в общую локальную "dev.main", например. Недостатком становится то, что такие эхи становятся либо односторонними, либо надо создавать сложные обратные правила (т.е. ответы должны будут помещаться и в новую эху, и в старую).

2. Кросспостинг - отправка и присутствие сообщения с одним ID в нескольких эхах одновременно.

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

4. Добавить тег определяющий кодировку или тип содержимого (mime-type) тела сообщения. По идее это должно гарантировано решить проблему с тем, как реализовывать шифрование сообщений - зашифрованное сообщение будет иметь соответствующий тег encoding и его расшифровкой должен будет заниматься клиент.

5. Хранить время фетча сообщения нодой и использовать его в качестве указателя сдвига для получения индекса в /u/e-подобном запросе. Я читал обсуждение чего-то подобного в idec.talks, но по-моему там предлагалось использовать время самого сообщения, что действительно может работать криво.

6. Метод POST для /u/e и /u/m, это тоже обсуждалось и, вроде, не должно требовать больших изменений, но почему-то не взлетело.

7. Хранить в тегах, кроме указателя на отвеченное сообщение, указатель на первое сообщение ветки обсуждения/топика. Чуть упрощает реализацию топиков и позволяет писать в них сообщения не являющиеся ответами на конкретный пост.

8. Пока ещё сырая, на как выходит не новая, идея, касающаяся редактирования сообщений, заключающаяся в отправке нового сообщения, с тегом, скажем, "amend" содержащим ID оригинального сообщения. Идентичная идея была описана ещё в ii://jOO4SZIyVrHLU9XxuhKW , но осталась без ответов.

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

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

# Re: Предложения или "Как нам обустроить idec?"
vvs(ping,12) — ake
2021-12-16 17:36:05


Подозреваю, что сначала надо задать вопрос: кому и зачем нужен idec? И тогда многие ответы станут очевидны.

То ли idec должен всё включать и поддерживать. И тогда проще взять уже существующие протоколы и софт. То ли все хотят игрушечную реализацию, доступную школьнику. И тогда он может кому-то показаться уже слишком переусложнённым. Кстати, даже в существующих реализациях иногда уже встречались некоторые несовместимости.

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

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — vvs
2021-12-16 18:43:07


vvs> Подозреваю, что сначала надо задать вопрос: кому и зачем нужен idec? И тогда многие ответы станут очевидны.

vvs> Сам я не знаю, зачем существует idec, но пользуюсь им для узкого круга общения, не заморачиваясь философскими деталями.

Ну, а вот мне просто он концептуально и технически нравится, как универсальная вещь. Можно, конечно, сказать самому себе: "да нет, это просто группа друзей сделала для себя форум, просто вот так хитро устроенный, _это не для всех_", но это будет разочаровывающим выводом и во многом будет значить, что мне здесь делать, собственно, нечего. Но другого сообщества, использующего idec, у меня нет, а энтузиазм пока есть.

# Re: Предложения или "Как нам обустроить idec?"
vvs(ping,12) — ake
2021-12-16 19:08:26


ake> Ну, а вот мне просто он концептуально и технически нравится, как универсальная вещь.

Причина ничем не хуже любой другой.

# Re: Предложения или "Как нам обустроить idec?"
hugeping(ping,1) — ake
2021-12-17 08:59:36


ake> но это будет разочаровывающим выводом и во многом будет значить, что мне здесь делать, собственно, нечего. Но другого сообщества, использующего idec, у меня нет, а энтузиазм пока есть.

Чужой энтузиазм радует! :) Но, откровенно говоря, я наблюдал многих энтузиастов (не только про idec сейчас говорю), которые на волне энтузиаста что-то делали, не доделали и ушли. В этом смысле у меня теперь есть прагматический скепсис, который вылился в то, что я перестал поддерживать всех идейных новичков. Просто потому, что начинаешь помогать, тратишь последние крохи времени (которые берёг для своих проектов) а потом... Всё в пустоту. Вот твоя фраза "делать нечего" она выдаёт именно такое отношение. Извини. :)

Вот у меня была цель, сделать себе место из которого я генерю свой "контент". Я его сделал. У меня есть и личка и редактирование сообщений, экспорт в gemini и многое другое. Но наружу я смотрю просто idec-ом. Даже если никаких узлов idec не останется, это меня не беспокоит -- потому что я не могу на это никак повлиять.

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

Потому что, то же редактирование -- не так просто как кажется в начале.

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

Остальное на мой взгляд избыточные функции и я их вряд ли буду у себя реализовывать.

# Re: Предложения или "Как нам обустроить idec?"
Ordos(tgi,1) — ake
2021-12-17 08:51:49


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

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

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

# Re: Предложения или "Как нам обустроить idec?"
Ordos(tgi,1) — Ordos
2021-12-17 08:58:36


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

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — hugeping
2021-12-17 10:36:50


hugeping> Чужой энтузиазм радует! :) Но, откровенно говоря, я наблюдал многих энтузиастов (не только про idec сейчас говорю), которые на волне энтузиаста что-то делали, не доделали и ушли. В этом смысле у меня теперь есть прагматический скепсис, который вылился в то, что я перестал поддерживать всех идейных новичков. Просто потому, что начинаешь помогать, тратишь последние крохи времени (которые берёг для своих проектов) а потом... Всё в пустоту. Вот твоя фраза "делать нечего" она выдаёт именно такое отношение. Извини. :)

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

hugeping> - личка (правда у тебя в списке этого нет)

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

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — Ordos
2021-12-17 10:58:57


Ordos> Самое простое

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

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

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — ake
2021-12-17 11:47:57


ake> Доброго времени суток. На волне (пока ещё) энтузиазма решил поделиться "рационализаторскими" предложениями для idec. Некоторые из них, в том или ином виде, озвучивались. Часть из них относится скорее к реализации нод, но некоторые потребуют либо дополнения протокола, либо изменений с разной степенью обратной совместимости.

Ты забыл самое главное написать: какие существующие проблемы это решает?

ake> 1. Правила перемаркировки эх. Идея простая - на ноду приходит сообщение (не важно, фетчится или от поинта) и, если у него в качестве эхи указано некое значение A, то оно заменяется на некоторое A* по определённому правилу. Самый очевидный вариант использования - "личные" эхи, один поинт отправляет сообщение в эху "sendmsg.username", в процессе оно перемаркируется, как "readmsg.username_authstr" и адресат его может получить. Ещё так можно укрупнять и агрегировать эхи, перемаркировывая сообщения из внешних "dev.c", "dev.cpp", "dev.python" в общую локальную "dev.main", например. Недостатком становится то, что такие эхи становятся либо односторонними, либо надо создавать сложные обратные правила (т.е. ответы должны будут помещаться и в новую эху, и в старую).

Менять сообщения, конечно, никто не запрещает, но не надо такое отдавать наружу никогда. А так - каждый волен со своей базой делать что угодно - хоть удалить вообще нафиг :)

ake> 2. Кросспостинг - отправка и присутствие сообщения с одним ID в нескольких эхах одновременно.

Это задача клиента.

ake> 3. Хуки на появление сообщений в эхе/от пользователя/в качестве ответа. Тогда можно будет сделать, например, эху для управления нодой, какие-нибудь голосовалки (изначально была идея нодо-локальной общественной модерации) и ещё что-нибудь.

Непонятно какие задачи решает. Голосования проводили и без этого. Можно анализировать сабжи. Это дёшево.

ake> 4. Добавить тег определяющий кодировку или тип содержимого (mime-type) тела сообщения. По идее это должно гарантировано решить проблему с тем, как реализовывать шифрование сообщений - зашифрованное сообщение будет иметь соответствующий тег encoding и его расшифровкой должен будет заниматься клиент.

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

ake> 5. Хранить время фетча сообщения нодой и использовать его в качестве указателя сдвига для получения индекса в /u/e-подобном запросе. Я читал обсуждение чего-то подобного в idec.talks, но по-моему там предлагалось использовать время самого сообщения, что действительно может работать криво.

Можно попробовать POC написать.

ake> 6. Метод POST для /u/e и /u/m, это тоже обсуждалось и, вроде, не должно требовать больших изменений, но почему-то не взлетело.

Смысла особого нет. Не решает ни одной проблемы.

ake> 7. Хранить в тегах, кроме указателя на отвеченное сообщение, указатель на первое сообщение ветки обсуждения/топика. Чуть упрощает реализацию топиков и позволяет писать в них сообщения не являющиеся ответами на конкретный пост.

Смысла нет, так как построить цепочку ответов это практически бесплатно.

ake> 8. Пока ещё сырая, на как выходит не новая, идея, касающаяся редактирования сообщений, заключающаяся в отправке нового сообщения, с тегом, скажем, "amend" содержащим ID оригинального сообщения. Идентичная идея была описана ещё в ii://jOO4SZIyVrHLU9XxuhKW , но осталась без ответов.

Возможность редактирования сообщений это зло.

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — hugeping
2021-12-17 11:47:57


hugeping> А так, из твоих предложений мне лично интересны:
hugeping> - редактирование.

Является злом в чистом виде и должно быть запрещено законом :)

hugeping> - личка (правда у тебя в списке этого нет)

Есть некоторые идеи и есть потребность в этой фиче.

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — ake
2021-12-17 11:47:57


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

Как это будет работать в масштабе сети?

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — ake
2021-12-17 11:47:57


ake> Но это вопрос транспорта сообщений и api. Ещё есть вопрос обнаружения отправителей и получателей, особенно между нодами, ибо с этим на практике как-то не очень. Есть имя ноды, которое иногда может меняться со временем, по которому нельзя тривиально узнать адрес (видимо для этого предполагается собирать нодлист), а про получателя мы знаем только имя в свободной форме.

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

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — Andrew Lobanov
2021-12-17 13:29:52


> Менять сообщения, конечно, никто не запрещает, но не надо такое отдавать наружу никогда. А так - каждый волен со своей базой делать что угодно - хоть удалить вообще нафиг :)

Совсем не обязательно менять сообщения, ничто не запрещает отдавать в индексе эхи, сообщения имеющие другое значение в соответствующем поле. И кросспостинг почти про то же.

> Для этого нужна поддержка шифрованных сообщений.

Тэг с типом содержимого вообще ортогонален шифрованным сообщениям. Можно хоть что слать, заранее перекодировав и указав, что это base64/uuencode/koi8r/etc, если надо (да, будет неоптимально, но это опять организационный вопрос, и я в курсе про файл-эхи).

> Возможность редактирования сообщений это зло.

Обратный вопрос, перефразируя: "Какие проблемы это создаёт?"

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — Andrew Lobanov
2021-12-17 14:25:06


AL> Как это будет работать в масштабе сети?

Навскидку - либо масштабируем то же самое до нод, т.е. складываем в скрытую эху outbound.some_node_authstr, на которую подписана эта нода; либо форвардим с помощью /u/push.

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — ake
2021-12-18 06:17:58


>> Менять сообщения, конечно, никто не запрещает, но не надо такое отдавать наружу никогда. А так - каждый волен со своей базой делать что угодно - хоть удалить вообще нафиг :)
ake> Совсем не обязательно менять сообщения, ничто не запрещает отдавать в индексе эхи, сообщения имеющие другое значение в соответствующем поле. И кросспостинг почти про то же.

Кросспостинг реализуется на стороне клиента и делается совсем иначе и проще. Зачем городить огород?

>> Для этого нужна поддержка шифрованных сообщений.
ake> Тэг с типом содержимого вообще ортогонален шифрованным сообщениям. Можно хоть что слать, заранее перекодировав и указав, что это base64/uuencode/koi8r/etc, если надо (да, будет неоптимально, но это опять организационный вопрос, и я в курсе про файл-эхи).
>> Возможность редактирования сообщений это зло.
ake> Обратный вопрос, перефразируя: "Какие проблемы это создаёт?"

Ну любые нововведения должны решать существующие проблемы. Изменения ради изменений это путь к сложной системе без смысла.

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — ake
2021-12-18 06:20:41


AL>> Как это будет работать в масштабе сети?
ake> Навскидку - либо масштабируем то же самое до нод, т.е. складываем в скрытую эху outbound.some_node_authstr, на которую подписана эта нода; либо форвардим с помощью /u/push.

Химера какая-то, если честно. Давай чтоль нормальный POC :)

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — Andrew Lobanov
2021-12-22 18:22:03


Добавил на своей ноде.

На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.

В интерфейсе ноды:
Входящие - http://gears.headake.win/idec/ui2/directmail/inbox
Отправить сообщение - http://gears.headake.win/idec/ui2/directmail/send (адрес вводится в обычном формате "nodename, 123")

Реквизиты для тестов
Адрес пользователя: ake, 5
Строка авторизации: jfmq66fj6e

Адрес пользователя: ake, 6
Строка авторизации: 7uyoxz2fj4

О грустном - клиентах и разных подводных граблях.

В IDEC mobile отправка сообщений работает (хоть и требует финта ушами, вроде захода в любую эху и изменении поля в форме), а с получением сложнее - имя эхи приводится к нижнему регистру (и да, я проверил, это описано в стандарте), в отличие от строк авторизации, у которых таких ограничений нет (можно, конечно, кодировать строку в base32, но это отдельный уровень костыльности). В caesium чуть лучше - получение сообщений работает, для отправки нужен такой же трюк с вызовом редактора в любой эхе и исправлением её имени.

# Re: Предложения или "Как нам обустроить idec?"
vvs(ping,12) — ake
2021-12-22 19:33:39


И всё-таки, зачем кому-то и дальше усложнять idec?

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

Кто-нибудь смотрел для сравнения, например, https://public-inbox.org/README.html ? Это очень простой механизм, который использует готовые решения и протоколы для всего. Например децентрализованная сеть там за счёт Git. К тому же оно используется самими разработчиками Git. Кто-то может оценить, в чём возможные преимущества реализации этих же функций на idec заново?

# Re: Предложения или "Как нам обустроить idec?"
shaos(tavern,34) — ake
2021-12-22 20:43:51


base32 это большие буквы и некоторые цифры - уж лучше обычный hex тогда

а так вроде всё логично :)

# Re: Предложения или "Как нам обустроить idec?"
shaos(tavern,34) — vvs
2021-12-22 20:46:44


И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

# Re: Предложения или "Как нам обустроить idec?"
vvs(ping,12) — shaos
2021-12-22 21:07:52


shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

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

Сам я никогда не делаю ничего сверх необходимого. Правда мои личные потребности могут кого-нибудь очень удивить, но я никогда и не претендовал на их объективную сущность :)

# Re: Предложения или "Как нам обустроить idec?"
hugeping(ping,1) — shaos
2021-12-23 09:02:58


shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

Я лично считаю, что расширения нужно вводить только тогда, когда они нужны позарез.

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

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

# Re: Предложения или "Как нам обустроить idec?"
hugeping(ping,1) — ake
2021-12-23 09:23:44


ake> Добавил на своей ноде.

ake> На клиенте:
ake> Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
ake> Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.

У меня были похожие вещи на старой ноде (на основе iing). У меня было понятие виртуальной эхи. Фактически, через них можно было делать любой запрос. Например, получить личные сообщения, делать поиск по содержимому итд. На текущей ii-go личку сделал проще. Сообщения шлются в эху .private (вообще, эхи с . у меня считаются специальными) и дальше при заборе этой эхи учитывается, что именно можно отдавать юзеру. Решение делается на основе поля To. Там кажется можно даже групповую переписку организовывать, но я сейчас не помню. Но если написать в личку All, то услышат все (через личку). :) Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.

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

# Re: Предложения или "Как нам обустроить idec?"
ake(ping,30) — hugeping
2021-12-23 19:37:43


> Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.

Ну, у меня ключевая идея была как раз в том, что если нам нужно авторизоваться для получения данных, то мы просто дописываем строку авторизации к идентификатору эхи (или сообщения) и не надо вводить никаких новых методов. Нет большой разницы, в плане наличия данных в запросе, обращаемся мы к специальному /u/private/myauth/secret.echo или к стандартному /u/e/myauth.secret.echo. Только с ограничением на имена эх промахнулся.

Без разницы, как это реализовано внутри - генерирует нода такие индексы динамически или честно форвардит входящие.

# Re: Предложения или "Как нам обустроить idec?"
shaos(tavern,34) — hugeping
2021-12-24 06:56:57


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

Это самая правильная позиция :)

Главное не ломать совместимость со старыми версиями нодов/клиентов

# Re: Предложения или "Как нам обустроить idec?"
Andrew Lobanov(tavern,1) — ake
2022-01-21 09:32:52


ake> Добавил на своей ноде.

Это, безусловно, замечательно. А теперь как наладить отправку сообщения поинтом твоего узла поинту моего узла? :)

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