subject: Предложения или "Как нам обустроить idec?"
16.12.2021 19:22
ake (ping,30)
Доброго времени суток. На волне (пока ещё) энтузиазма решил поделиться "рационализаторскими" предложениями для 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 не поменялся.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
16.12.2021 20:36
vvs (ping,12) => w6o5S9CleUqqm4Lgc8O9
Подозреваю, что сначала надо задать вопрос: кому и зачем нужен idec? И тогда многие ответы станут очевидны.
То ли idec должен всё включать и поддерживать. И тогда проще взять уже существующие протоколы и софт. То ли все хотят игрушечную реализацию, доступную школьнику. И тогда он может кому-то показаться уже слишком переусложнённым. Кстати, даже в существующих реализациях иногда уже встречались некоторые несовместимости.
Сам я не знаю, зачем существует idec, но пользуюсь им для узкого круга общения, не заморачиваясь философскими деталями.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
16.12.2021 21:43
ake (ping,30) => uyN2bcxtbLH4UWfw1Urt
vvs> Подозреваю, что сначала надо задать вопрос: кому и зачем нужен idec? И тогда многие ответы станут очевидны.
vvs> Сам я не знаю, зачем существует idec, но пользуюсь им для узкого круга общения, не заморачиваясь философскими деталями.
Ну, а вот мне просто он концептуально и технически нравится, как универсальная вещь. Можно, конечно, сказать самому себе: "да нет, это просто группа друзей сделала для себя форум, просто вот так хитро устроенный, _это не для всех_", но это будет разочаровывающим выводом и во многом будет значить, что мне здесь делать, собственно, нечего. Но другого сообщества, использующего idec, у меня нет, а энтузиазм пока есть.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
16.12.2021 22:08
vvs (ping,12) => FpG3RhiLfkTDK6kVChAL
ake> Ну, а вот мне просто он концептуально и технически нравится, как универсальная вещь.
Причина ничем не хуже любой другой.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 11:51
Ordos (tgi,1) => w6o5S9CleUqqm4Lgc8O9
Думаю, что не стоит усложнять. Единственное, что может быть действительно полезно - это личка. Но здесь потребуется доработка клиентов. Самое простое - ввести дополнительный запрос с авторизацией на получение личных сообщений/эх. К этому потом можно прикрутить, например, ботов, предлагающих разное.
Помечать такие сообщения можно спец. тегом, из которого будет понятно, что это личка и в него же положить список участников.
Опять же введение доп. запроса исключает проблему несовместимости. Если клиент поддерживает его - будет личка, если нет - будет работать как обычно.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 11:58
Ordos (tgi,1) => 0tzTwsWNk9hoZgtRQvIr
Забыл добавить по поводу передачи лички между станциями. Лучше не забирать такие эхи, а наоборот пушить на нужную станцию. Таким образом, такие эхи не будут нигде отсвечивать и получить их список становится невозможно. Да и не нужно.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 11:59
hugeping (ping,1) => FpG3RhiLfkTDK6kVChAL
ake> но это будет разочаровывающим выводом и во многом будет значить, что мне здесь делать, собственно, нечего. Но другого сообщества, использующего idec, у меня нет, а энтузиазм пока есть.
Чужой энтузиазм радует! :) Но, откровенно говоря, я наблюдал многих энтузиастов (не только про idec сейчас говорю), которые на волне энтузиаста что-то делали, не доделали и ушли. В этом смысле у меня теперь есть прагматический скепсис, который вылился в то, что я перестал поддерживать всех идейных новичков. Просто потому, что начинаешь помогать, тратишь последние крохи времени (которые берёг для своих проектов) а потом... Всё в пустоту. Вот твоя фраза "делать нечего" она выдаёт именно такое отношение. Извини. :)
Вот у меня была цель, сделать себе место из которого я генерю свой "контент". Я его сделал. У меня есть и личка и редактирование сообщений, экспорт в gemini и многое другое. Но наружу я смотрю просто idec-ом. Даже если никаких узлов idec не останется, это меня не беспокоит -- потому что я не могу на это никак повлиять.
Но у меня не было цели сделать из idec универсальную технологию. Допустим, у тебя эта цель (не важно, чем она диктуется) есть. Тогда я предлагаю тебе додумать до конца твои идеи и оформить их в виде конкретных предложений стандарта. Обсуждать проще конкретные технические предложения (и отдельно каждое).
Потому что, то же редактирование -- не так просто как кажется в начале.
А так, из твоих предложений мне лично интересны:
- редактирование.
- личка (правда у тебя в списке этого нет)
Остальное на мой взгляд избыточные функции и я их вряд ли буду у себя реализовывать.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 13:36
ake (ping,30) => zqeJKrua2bLOe1L0lvWZ
hugeping> Чужой энтузиазм радует! :) Но, откровенно говоря, я наблюдал многих энтузиастов (не только про idec сейчас говорю), которые на волне энтузиаста что-то делали, не доделали и ушли. В этом смысле у меня теперь есть прагматический скепсис, который вылился в то, что я перестал поддерживать всех идейных новичков. Просто потому, что начинаешь помогать, тратишь последние крохи времени (которые берёг для своих проектов) а потом... Всё в пустоту. Вот твоя фраза "делать нечего" она выдаёт именно такое отношение. Извини. :)
В этом плане я не претендую на какую-то поддержку, и не хочу обещать того, что не смогу сделать. Не могу сказать, что сильно "идеен", но мне интересно заняться технической частью сети, и хотелось бы, чтобы это было кому-нибудь полезно, и тоже не было впустую. Если же это бесполезная затея, то "делать нечего" как раз подходит в качестве вывода.
hugeping> - личка (правда у тебя в списке этого нет)
Ну, примитивную личку можно собрать на базе идеи про перемаркировку, она там как раз в виде примера.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 13:58
ake (ping,30) => 0tzTwsWNk9hoZgtRQvIr
Ordos> Самое простое
Самое простое и никак не ломающее текущий api для клиентов, если говорить о простейшем сценарии с одним отправителем и одним получателем - это КМК зарезервированные псевдо- и скрытые эхи для отправки и получения сообщений, что в общих чертах описано в примере в первом из предложений.
Но это вопрос транспорта сообщений и api. Ещё есть вопрос обнаружения отправителей и получателей, особенно между нодами, ибо с этим на практике как-то не очень. Есть имя ноды, которое иногда может меняться со временем, по которому нельзя тривиально узнать адрес (видимо для этого предполагается собирать нодлист), а про получателя мы знаем только имя в свободной форме.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 14:47
Andrew Lobanov (tavern,1) => w6o5S9CleUqqm4Lgc8O9
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 , но осталась без ответов.
Возможность редактирования сообщений это зло.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 14:47
Andrew Lobanov (tavern,1) => zqeJKrua2bLOe1L0lvWZ
hugeping> А так, из твоих предложений мне лично интересны:
hugeping> - редактирование.
Является злом в чистом виде и должно быть запрещено законом :)
hugeping> - личка (правда у тебя в списке этого нет)
Есть некоторые идеи и есть потребность в этой фиче.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 14:47
Andrew Lobanov (tavern,1) => rZBWYJscKXG2Kr4xhaf0
hugeping>> - личка (правда у тебя в списке этого нет)
ake> Ну, примитивную личку можно собрать на базе идеи про перемаркировку, она там как раз в виде примера.
Как это будет работать в масштабе сети?
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 14:47
Andrew Lobanov (tavern,1) => O7uRNnuBy8EjtG7ZAtbJ
ake> Но это вопрос транспорта сообщений и api. Ещё есть вопрос обнаружения отправителей и получателей, особенно между нодами, ибо с этим на практике как-то не очень. Есть имя ноды, которое иногда может меняться со временем, по которому нельзя тривиально узнать адрес (видимо для этого предполагается собирать нодлист), а про получателя мы знаем только имя в свободной форме.
Посмотри в поле адреса. Оно не просто так сущетвует, а однозначно тебя идентифицирует в сети. В отличие от имени.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 16:29
ake (ping,30) => IMtYzzeV2ie4Fug5jK4H
> Менять сообщения, конечно, никто не запрещает, но не надо такое отдавать наружу никогда. А так - каждый волен со своей базой делать что угодно - хоть удалить вообще нафиг :)
Совсем не обязательно менять сообщения, ничто не запрещает отдавать в индексе эхи, сообщения имеющие другое значение в соответствующем поле. И кросспостинг почти про то же.
> Для этого нужна поддержка шифрованных сообщений.
Тэг с типом содержимого вообще ортогонален шифрованным сообщениям. Можно хоть что слать, заранее перекодировав и указав, что это base64/uuencode/koi8r/etc, если надо (да, будет неоптимально, но это опять организационный вопрос, и я в курсе про файл-эхи).
> Возможность редактирования сообщений это зло.
Обратный вопрос, перефразируя: "Какие проблемы это создаёт?"
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
17.12.2021 17:25
ake (ping,30) => QGZYqB6NbJ9KEenSGYja
AL> Как это будет работать в масштабе сети?
Навскидку - либо масштабируем то же самое до нод, т.е. складываем в скрытую эху outbound.some_node_authstr, на которую подписана эта нода; либо форвардим с помощью /u/push.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
18.12.2021 09:17
Andrew Lobanov (tavern,1) => bPWmcZqw4VP6Y10mYxBM
>> Менять сообщения, конечно, никто не запрещает, но не надо такое отдавать наружу никогда. А так - каждый волен со своей базой делать что угодно - хоть удалить вообще нафиг :)
ake> Совсем не обязательно менять сообщения, ничто не запрещает отдавать в индексе эхи, сообщения имеющие другое значение в соответствующем поле. И кросспостинг почти про то же.
Кросспостинг реализуется на стороне клиента и делается совсем иначе и проще. Зачем городить огород?
>> Для этого нужна поддержка шифрованных сообщений.
ake> Тэг с типом содержимого вообще ортогонален шифрованным сообщениям. Можно хоть что слать, заранее перекодировав и указав, что это base64/uuencode/koi8r/etc, если надо (да, будет неоптимально, но это опять организационный вопрос, и я в курсе про файл-эхи).
>> Возможность редактирования сообщений это зло.
ake> Обратный вопрос, перефразируя: "Какие проблемы это создаёт?"
Ну любые нововведения должны решать существующие проблемы. Изменения ради изменений это путь к сложной системе без смысла.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
18.12.2021 09:20
Andrew Lobanov (tavern,1) => 6arynKCD1uMnAG6X5FxH
AL>> Как это будет работать в масштабе сети?
ake> Навскидку - либо масштабируем то же самое до нод, т.е. складываем в скрытую эху outbound.some_node_authstr, на которую подписана эта нода; либо форвардим с помощью /u/push.
Химера какая-то, если честно. Давай чтоль нормальный POC :)
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
22.12.2021 21:22
ake (ping,30) => 2bTDaa9Cw1bPRgzakqhJ
Добавил на своей ноде.
На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху 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 чуть лучше - получение сообщений работает, для отправки нужен такой же трюк с вызовом редактора в любой эхе и исправлением её имени.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
22.12.2021 22:33
vvs (ping,12) => cxDRiPlPAOkMcmPfCytI
И всё-таки, зачем кому-то и дальше усложнять idec?
Если его существующие возможности не устраивают, то почему не взять что-то готовое? Это выглядит, как попытки изобрести велосипед. В чём тут может быть выигрыш? Нет, ну если просто очень хочется написать что-то своё, то вопросов нет. Не подумайте, что я кого-нибудь отговариваю - мне просто не понятны мотивы.
Кто-нибудь смотрел для сравнения, например, https://public-inbox.org/README.html ? Это очень простой механизм, который использует готовые решения и протоколы для всего. Например децентрализованная сеть там за счёт Git. К тому же оно используется самими разработчиками Git. Кто-то может оценить, в чём возможные преимущества реализации этих же функций на idec заново?
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
22.12.2021 23:43
shaos (tavern,34) => cxDRiPlPAOkMcmPfCytI
base32 это большие буквы и некоторые цифры - уж лучше обычный hex тогда
а так вроде всё логично :)
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
22.12.2021 23:46
shaos (tavern,34) => aQGcXHSUGcmrnjnVvbu9
И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
23.12.2021 00:07
vvs (ping,12) => z2PfZYiRH8Y6MleT5u82
shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
Если бы знал, то не спрашивал бы. Философия, стоящая за idec, для меня не вполне понятна. Я просто пользуюсь тем, что есть, для чисто практических целей.
Сам я никогда не делаю ничего сверх необходимого. Правда мои личные потребности могут кого-нибудь очень удивить, но я никогда и не претендовал на их объективную сущность :)
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
23.12.2021 12:02
hugeping (ping,1) => z2PfZYiRH8Y6MleT5u82
shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
Я лично считаю, что расширения нужно вводить только тогда, когда они нужны позарез.
Например, насколько я помню, одна из проблем -- необходимость для синхронизации сливать всегда все индексы. Да, это просто, но как-то уж очень перебор. Слайсы это исправили.
Но я, естественно, не претендую на какой-то значимый голос в сообществе. Мой анархичный ii-go на данный момент меня полностью устраивает. И если при внедрении расширений, наследие будет работать как и работало -- вообще замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но с интересом понаблюдаю за движухой.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
23.12.2021 12:23
hugeping (ping,1) => cxDRiPlPAOkMcmPfCytI
ake> Добавил на своей ноде.
ake> На клиенте:
ake> Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
ake> Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.
У меня были похожие вещи на старой ноде (на основе iing). У меня было понятие виртуальной эхи. Фактически, через них можно было делать любой запрос. Например, получить личные сообщения, делать поиск по содержимому итд. На текущей ii-go личку сделал проще. Сообщения шлются в эху .private (вообще, эхи с . у меня считаются специальными) и дальше при заборе этой эхи учитывается, что именно можно отдавать юзеру. Решение делается на основе поля To. Там кажется можно даже групповую переписку организовывать, но я сейчас не помню. Но если написать в личку All, то услышат все (через личку). :) Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.
Но главный вопрос в другом. Как наладить хождение почты между узлами? И тут возникает масса интересных вопросов... Начиная от адресации, маршрутизации и заканчивая вопросами как долго хранить эту переписку транзитным узлам. Ну итд. И тогда я подумал, а так ли нужна эта фича? Мне вот достаточно лички в пределах моего ресурса.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
23.12.2021 22:37
ake (ping,30) => rb5D2Z76yTrTXkVQ6GEO
> Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.
Ну, у меня ключевая идея была как раз в том, что если нам нужно авторизоваться для получения данных, то мы просто дописываем строку авторизации к идентификатору эхи (или сообщения) и не надо вводить никаких новых методов. Нет большой разницы, в плане наличия данных в запросе, обращаемся мы к специальному /u/private/myauth/secret.echo или к стандартному /u/e/myauth.secret.echo. Только с ограничением на имена эх промахнулся.
Без разницы, как это реализовано внутри - генерирует нода такие индексы динамически или честно форвардит входящие.
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
24.12.2021 09:56
shaos (tavern,34) => 2Zm0b7GfI0AscrZsMHdU
> ... если при внедрении расширений, наследие будет работать как и работало -- вообще
> замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но
> с интересом понаблюдаю за движухой.
Это самая правильная позиция :)
Главное не ломать совместимость со старыми версиями нодов/клиентов
--------------------------------------------------------------------------------
subject: Re: Предложения или "Как нам обустроить idec?"
21.01.2022 12:32
Andrew Lobanov (tavern,1) => cxDRiPlPAOkMcmPfCytI
ake> Добавил на своей ноде.
Это, безусловно, замечательно. А теперь как наладить отправку сообщения поинтом твоего узла поинту моего узла? :)
Внутри одного узла вообще не проблема личку сделать, но смысла в ней не очень много получается.
--------------------------------------------------------------------------------