Доброго времени суток. На волне (пока ещё) энтузиазма решил поделиться "рационализаторскими" предложениями для 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 не поменялся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 , но осталась без ответов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху 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 чуть лучше - получение сообщений работает, для отправки нужен такой же трюк с вызовом редактора в любой эхе и исправлением её имени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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