# 2022
shaos (shaos, 2) → All – 04:23:09 2022-01-02
Всех обитателей IDEC сети поздравляю с Новым 2022-м Годом! Желаю IDEC в новом году разростись до немыслимых размеров и подмять под себя ну скажем всех Спринтеристов (и даже частично Синклеристов), а если получится, то и ещё кого-нибудь в придачу ;)
shaos (shaos, 2) → All – 04:23:09 2022-01-02
Всех обитателей IDEC сети поздравляю с Новым 2022-м Годом! Желаю IDEC в новом году разростись до немыслимых размеров и подмять под себя ну скажем всех Спринтеристов (и даже частично Синклеристов), а если получится, то и ещё кого-нибудь в придачу ;)
# Re: Актуальный нодлист
Ordos (tgi,1) → shaos – 10:31:59 2021-12-24
Вот кстати здравая мысль. И фича полезная и ничего не ломает. Я - за.
Ordos (tgi,1) → shaos – 10:31:59 2021-12-24
Вот кстати здравая мысль. И фича полезная и ничего не ломает. Я - за.
# Re: Актуальный нодлист
shaos (tavern,34) → shaos – 07:12:14 2021-12-24
А кстати небыло мыслей сделать специальный вызов в API, который возвращал бы uplinks?
Типа /fetches.txt
Ну и было бы неплохо иметь возможность через API спросить у нода как он называется, а то я сейчас не вижу как по http://idec.spline-online.ml понять, что это tavern
И после этого можно будет строить топологию сети автоматически :)
shaos (tavern,34) → shaos – 07:12:14 2021-12-24
А кстати небыло мыслей сделать специальный вызов в API, который возвращал бы uplinks?
Типа /fetches.txt
http://idec.spline-online.ml/;idec.talks/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum;15
https://.....;something.something;60
Ну и было бы неплохо иметь возможность через API спросить у нода как он называется, а то я сейчас не вижу как по http://idec.spline-online.ml понять, что это tavern
И после этого можно будет строить топологию сети автоматически :)
# Re: Мысли про возможное будущее IDEC
shaos (tavern,34) → hugeping – 06:58:03 2021-12-24
> ii подмножество idec. Если речь про ii, то всё-ещё так. :)
ii более несуществует - есть только idec ;)
и он чуть более сложный...
shaos (tavern,34) → hugeping – 06:58:03 2021-12-24
> ii подмножество idec. Если речь про ii, то всё-ещё так. :)
ii более несуществует - есть только idec ;)
и он чуть более сложный...
# Re: Предложения или "Как нам обустроить idec?"
shaos (tavern,34) → hugeping – 06:56:57 2021-12-24
> ... если при внедрении расширений, наследие будет работать как и работало -- вообще
> замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но
> с интересом понаблюдаю за движухой.
Это самая правильная позиция :)
Главное не ломать совместимость со старыми версиями нодов/клиентов
shaos (tavern,34) → hugeping – 06:56:57 2021-12-24
> ... если при внедрении расширений, наследие будет работать как и работало -- вообще
> замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но
> с интересом понаблюдаю за движухой.
Это самая правильная позиция :)
Главное не ломать совместимость со старыми версиями нодов/клиентов
# Re: Предложения или "Как нам обустроить idec?"
ake (ping,30) → hugeping – 19:37:43 2021-12-23
> Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.
Ну, у меня ключевая идея была как раз в том, что если нам нужно авторизоваться для получения данных, то мы просто дописываем строку авторизации к идентификатору эхи (или сообщения) и не надо вводить никаких новых методов. Нет большой разницы, в плане наличия данных в запросе, обращаемся мы к специальному /u/private/myauth/secret.echo или к стандартному /u/e/myauth.secret.echo. Только с ограничением на имена эх промахнулся.
Без разницы, как это реализовано внутри - генерирует нода такие индексы динамически или честно форвардит входящие.
ake (ping,30) → hugeping – 19:37:43 2021-12-23
> Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.
Ну, у меня ключевая идея была как раз в том, что если нам нужно авторизоваться для получения данных, то мы просто дописываем строку авторизации к идентификатору эхи (или сообщения) и не надо вводить никаких новых методов. Нет большой разницы, в плане наличия данных в запросе, обращаемся мы к специальному /u/private/myauth/secret.echo или к стандартному /u/e/myauth.secret.echo. Только с ограничением на имена эх промахнулся.
Без разницы, как это реализовано внутри - генерирует нода такие индексы динамически или честно форвардит входящие.
# Re: Предложения или "Как нам обустроить idec?"
hugeping (ping,1) → ake – 09:23:44 2021-12-23
ake> Добавил на своей ноде.
ake> На клиенте:
ake> Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
ake> Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.
У меня были похожие вещи на старой ноде (на основе iing). У меня было понятие виртуальной эхи. Фактически, через них можно было делать любой запрос. Например, получить личные сообщения, делать поиск по содержимому итд. На текущей ii-go личку сделал проще. Сообщения шлются в эху .private (вообще, эхи с . у меня считаются специальными) и дальше при заборе этой эхи учитывается, что именно можно отдавать юзеру. Решение делается на основе поля To. Там кажется можно даже групповую переписку организовывать, но я сейчас не помню. Но если написать в личку All, то услышат все (через личку). :) Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.
Но главный вопрос в другом. Как наладить хождение почты между узлами? И тут возникает масса интересных вопросов... Начиная от адресации, маршрутизации и заканчивая вопросами как долго хранить эту переписку транзитным узлам. Ну итд. И тогда я подумал, а так ли нужна эта фича? Мне вот достаточно лички в пределах моего ресурса.
hugeping (ping,1) → ake – 09:23:44 2021-12-23
ake> Добавил на своей ноде.
ake> На клиенте:
ake> Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
ake> Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.
У меня были похожие вещи на старой ноде (на основе iing). У меня было понятие виртуальной эхи. Фактически, через них можно было делать любой запрос. Например, получить личные сообщения, делать поиск по содержимому итд. На текущей ii-go личку сделал проще. Сообщения шлются в эху .private (вообще, эхи с . у меня считаются специальными) и дальше при заборе этой эхи учитывается, что именно можно отдавать юзеру. Решение делается на основе поля To. Там кажется можно даже групповую переписку организовывать, но я сейчас не помню. Но если написать в личку All, то услышат все (через личку). :) Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.
Но главный вопрос в другом. Как наладить хождение почты между узлами? И тут возникает масса интересных вопросов... Начиная от адресации, маршрутизации и заканчивая вопросами как долго хранить эту переписку транзитным узлам. Ну итд. И тогда я подумал, а так ли нужна эта фича? Мне вот достаточно лички в пределах моего ресурса.
# Re: Мысли про возможное будущее IDEC
hugeping (ping,1) → shaos – 09:11:45 2021-12-23
>> Реализация всё ещё пишется за несколько часов :)
shaos> Это далеко не так ;)
ii подмножество idec. Если речь про ii, то всё-ещё так. :)
hugeping (ping,1) → shaos – 09:11:45 2021-12-23
>> Реализация всё ещё пишется за несколько часов :)
shaos> Это далеко не так ;)
ii подмножество idec. Если речь про ii, то всё-ещё так. :)
# Re: Предложения или "Как нам обустроить idec?"
hugeping (ping,1) → shaos – 09:02:58 2021-12-23
shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
Я лично считаю, что расширения нужно вводить только тогда, когда они нужны позарез.
Например, насколько я помню, одна из проблем -- необходимость для синхронизации сливать всегда все индексы. Да, это просто, но как-то уж очень перебор. Слайсы это исправили.
Но я, естественно, не претендую на какой-то значимый голос в сообществе. Мой анархичный ii-go на данный момент меня полностью устраивает. И если при внедрении расширений, наследие будет работать как и работало -- вообще замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но с интересом понаблюдаю за движухой.
hugeping (ping,1) → shaos – 09:02:58 2021-12-23
shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
Я лично считаю, что расширения нужно вводить только тогда, когда они нужны позарез.
Например, насколько я помню, одна из проблем -- необходимость для синхронизации сливать всегда все индексы. Да, это просто, но как-то уж очень перебор. Слайсы это исправили.
Но я, естественно, не претендую на какой-то значимый голос в сообществе. Мой анархичный ii-go на данный момент меня полностью устраивает. И если при внедрении расширений, наследие будет работать как и работало -- вообще замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но с интересом понаблюдаю за движухой.
# Re: Предложения или "Как нам обустроить idec?"
vvs (ping,12) → shaos – 21:07:52 2021-12-22
shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
Если бы знал, то не спрашивал бы. Философия, стоящая за idec, для меня не вполне понятна. Я просто пользуюсь тем, что есть, для чисто практических целей.
Сам я никогда не делаю ничего сверх необходимого. Правда мои личные потребности могут кого-нибудь очень удивить, но я никогда и не претендовал на их объективную сущность :)
vvs (ping,12) → shaos – 21:07:52 2021-12-22
shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
Если бы знал, то не спрашивал бы. Философия, стоящая за idec, для меня не вполне понятна. Я просто пользуюсь тем, что есть, для чисто практических целей.
Сам я никогда не делаю ничего сверх необходимого. Правда мои личные потребности могут кого-нибудь очень удивить, но я никогда и не претендовал на их объективную сущность :)
# Re: Предложения или "Как нам обустроить idec?"
shaos (tavern,34) → vvs – 20:46:44 2021-12-22
И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
shaos (tavern,34) → vvs – 20:46:44 2021-12-22
И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)
# Re: Предложения или "Как нам обустроить idec?"
shaos (tavern,34) → ake – 20:43:51 2021-12-22
base32 это большие буквы и некоторые цифры - уж лучше обычный hex тогда
а так вроде всё логично :)
shaos (tavern,34) → ake – 20:43:51 2021-12-22
base32 это большие буквы и некоторые цифры - уж лучше обычный hex тогда
а так вроде всё логично :)
# Re: Предложения или "Как нам обустроить idec?"
vvs (ping,12) → ake – 19:33:39 2021-12-22
И всё-таки, зачем кому-то и дальше усложнять idec?
Если его существующие возможности не устраивают, то почему не взять что-то готовое? Это выглядит, как попытки изобрести велосипед. В чём тут может быть выигрыш? Нет, ну если просто очень хочется написать что-то своё, то вопросов нет. Не подумайте, что я кого-нибудь отговариваю - мне просто не понятны мотивы.
Кто-нибудь смотрел для сравнения, например, https://public-inbox.org/README.html ? Это очень простой механизм, который использует готовые решения и протоколы для всего. Например децентрализованная сеть там за счёт Git. К тому же оно используется самими разработчиками Git. Кто-то может оценить, в чём возможные преимущества реализации этих же функций на idec заново?
vvs (ping,12) → ake – 19:33:39 2021-12-22
И всё-таки, зачем кому-то и дальше усложнять idec?
Если его существующие возможности не устраивают, то почему не взять что-то готовое? Это выглядит, как попытки изобрести велосипед. В чём тут может быть выигрыш? Нет, ну если просто очень хочется написать что-то своё, то вопросов нет. Не подумайте, что я кого-нибудь отговариваю - мне просто не понятны мотивы.
Кто-нибудь смотрел для сравнения, например, https://public-inbox.org/README.html ? Это очень простой механизм, который использует готовые решения и протоколы для всего. Например децентрализованная сеть там за счёт Git. К тому же оно используется самими разработчиками Git. Кто-то может оценить, в чём возможные преимущества реализации этих же функций на idec заново?
# Re: Предложения или "Как нам обустроить idec?"
ake (ping,30) → Andrew Lobanov – 18:22:03 2021-12-22
Добавил на своей ноде.
На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.
В интерфейсе ноды:
Входящие - http://gears.headake.win/idec/ui2/directmail/inbox
Отправить сообщение - http://gears.headake.win/idec/ui2/directmail/send (адрес вводится в обычном формате "nodename, 123")
Реквизиты для тестов
>> Читать далее
ake (ping,30) → Andrew Lobanov – 18:22:03 2021-12-22
Добавил на своей ноде.
На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху 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
>> Читать далее
# Re: IDEC identity
shaos (tavern,34) → Difrex(mobile) – 09:14:47 2021-12-22
По поводу общих поинтов - PGP/GPG тяжеловат потому как многообразен - надо что-то одно широко известное выбрать и поддержать, но только цифровую подпись - без шифрования (которое в IDEC по-моему противопоказано), например можно взять отданный в общенародное достояние алгоритм Ed25519, существующий уже 10 лет и не подпадающий ни под какие патенты - в нём есть 32-байтовый публичный ключ и 64-байтовый секретный ключ (половина из которого это копия публичного ключа). Публичные ключи распространяются по всем узлам и клиентам (например посредством специальной эхо-конференции от имени пользователя как поинта своего узла) и идентифицируют глобальных пользователей (которые всё также могут оставаться поинтами на своих узлах). К сообщению подписанному цифровой подписью Ed25519 цепляется 64-байтовя signature (в строке тэгов после тэга signature/ например как 128-символьная шестнадцатиричная строка либо как 103-символьная строка в кодировке BASE32 либо как 86-символьная строка в кодировке BASE64URL, либо как 80-символьная строка в кодировке ASCII85 где символ / подменён скажем на | - хотя наверное надо таки использовать BASE64URL как родной способ кодирования бинарных данных в IDEC). Чтобы проверить валидность сообщения, по имени пользователя (msgfrom) берётся его публичный ключ (предварительно распространённый) и по телу сообщения проверяется его цифровая подпись, чтобы удостовериться, что письмо не подменено или не подписано поддельным ключом.
Подробнее про внедрения Ed25519: https://ianix.com/pub/ed25519-deployment.html
P.S. Правда надо ещё придумать процедуру восстановления identity если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).
shaos (tavern,34) → Difrex(mobile) – 09:14:47 2021-12-22
По поводу общих поинтов - PGP/GPG тяжеловат потому как многообразен - надо что-то одно широко известное выбрать и поддержать, но только цифровую подпись - без шифрования (которое в IDEC по-моему противопоказано), например можно взять отданный в общенародное достояние алгоритм Ed25519, существующий уже 10 лет и не подпадающий ни под какие патенты - в нём есть 32-байтовый публичный ключ и 64-байтовый секретный ключ (половина из которого это копия публичного ключа). Публичные ключи распространяются по всем узлам и клиентам (например посредством специальной эхо-конференции от имени пользователя как поинта своего узла) и идентифицируют глобальных пользователей (которые всё также могут оставаться поинтами на своих узлах). К сообщению подписанному цифровой подписью Ed25519 цепляется 64-байтовя signature (в строке тэгов после тэга signature/ например как 128-символьная шестнадцатиричная строка либо как 103-символьная строка в кодировке BASE32 либо как 86-символьная строка в кодировке BASE64URL, либо как 80-символьная строка в кодировке ASCII85 где символ / подменён скажем на | - хотя наверное надо таки использовать BASE64URL как родной способ кодирования бинарных данных в IDEC). Чтобы проверить валидность сообщения, по имени пользователя (msgfrom) берётся его публичный ключ (предварительно распространённый) и по телу сообщения проверяется его цифровая подпись, чтобы удостовериться, что письмо не подменено или не подписано поддельным ключом.
Подробнее про внедрения Ed25519: https://ianix.com/pub/ed25519-deployment.html
P.S. Правда надо ещё придумать процедуру восстановления identity если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).
# Re: Мысли про возможное будущее IDEC
shaos (tavern,34) → Andrew Lobanov – 08:02:49 2021-12-22
> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.
Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).
> Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)
и это тоже можно сделать ;)
ну или по классике - в теле письма писать URL на ii-объект:
ii://1KpcmGrc9pUtZQ6Puv1z
shaos (tavern,34) → Andrew Lobanov – 08:02:49 2021-12-22
> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.
Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).
> Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)
и это тоже можно сделать ;)
ну или по классике - в теле письма писать URL на ii-объект:
ii://1KpcmGrc9pUtZQ6Puv1z
# Re: Мысли про возможное будущее IDEC
shaos (tavern,34) → Andrew Lobanov – 07:54:13 2021-12-22
> Реализация всё ещё пишется за несколько часов :)
Это далеко не так ;)
> Да и не повод дальше усложнять.
Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)
> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
Ну для начала - добавляет бинарных данных в рассылки.
> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.
Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)
>> Читать далее
shaos (tavern,34) → Andrew Lobanov – 07:54:13 2021-12-22
> Реализация всё ещё пишется за несколько часов :)
Это далеко не так ;)
> Да и не повод дальше усложнять.
Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)
> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
Ну для начала - добавляет бинарных данных в рассылки.
> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.
Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)
>> Читать далее
# Re: Мысли про возможное будущее IDEC
Andrew Lobanov (tavern,1) → shaos – 05:09:30 2021-12-22
shaos> Несколько комментариев к моему изначальному сообщению.
shaos> - Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).
ii-go это анархическая реализация. Взять хоть редактирование сообщений :)
shaos> - При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...
Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ. Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)
Andrew Lobanov (tavern,1) → shaos – 05:09:30 2021-12-22
shaos> Несколько комментариев к моему изначальному сообщению.
shaos> - Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).
ii-go это анархическая реализация. Взять хоть редактирование сообщений :)
shaos> - При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...
Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ. Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)
# Re: Мысли про возможное будущее IDEC
Andrew Lobanov (tavern,1) → shaos – 05:09:30 2021-12-22
>> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
shaos> Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)
Реализация всё ещё пишется за несколько часов :) Да и не повод дальше усложнять. Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
>> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
shaos> Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).
С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею. А найти и прочитать сообщение в общем случае это O(1). Другое дело, что в зависимости от конкретной платформы и конкретной реализации в абсолютных величинах это может быть долго. Я догадываюсь куда именно ты клонишь.
Andrew Lobanov (tavern,1) → shaos – 05:09:30 2021-12-22
>> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
shaos> Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)
Реализация всё ещё пишется за несколько часов :) Да и не повод дальше усложнять. Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
>> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
shaos> Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).
С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею. А найти и прочитать сообщение в общем случае это O(1). Другое дело, что в зависимости от конкретной платформы и конкретной реализации в абсолютных величинах это может быть долго. Я догадываюсь куда именно ты клонишь.
# Re: Мысли про возможное будущее IDEC
shaos (tavern,34) → shaos – 02:18:44 2021-12-22
Несколько комментариев к моему изначальному сообщению.
- Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).
- При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...
shaos (tavern,34) → shaos – 02:18:44 2021-12-22
Несколько комментариев к моему изначальному сообщению.
- Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).
- При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...
# Re: Мысли про возможное будущее IDEC
shaos (tavern,34) → ake – 01:47:34 2021-12-22
> Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC
> это практически контентно-адресуемая сеть...
Ну по сути так оно и есть :)
> ...и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений
А зачем прикручивать, если IDEC по сути вполне годится на роль "downsized IPFS"? ;)
Самая первая версия IPFS v0.1 появилась в феврале 2015, а самая первая версия ii v0.1 - в марте 2014. Получается IPFS это "upsized ii" :)
А так внутри IPFS есть "Distrubuted Hash Map", который есть последний пункт моих мыслей применительно к IDEC :)
И как над IPFS появилась криптовалюта Filecoin, над IDEC может в перспективе появится IDECoin и всё забурлит и запенится ;)
Шутка...
>> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
> Мне кажется такую функциональность проще реализовать в виде варианта запроса
>> Читать далее
shaos (tavern,34) → ake – 01:47:34 2021-12-22
> Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC
> это практически контентно-адресуемая сеть...
Ну по сути так оно и есть :)
> ...и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений
А зачем прикручивать, если IDEC по сути вполне годится на роль "downsized IPFS"? ;)
Самая первая версия IPFS v0.1 появилась в феврале 2015, а самая первая версия ii v0.1 - в марте 2014. Получается IPFS это "upsized ii" :)
А так внутри IPFS есть "Distrubuted Hash Map", который есть последний пункт моих мыслей применительно к IDEC :)
И как над IPFS появилась криптовалюта Filecoin, над IDEC может в перспективе появится IDECoin и всё забурлит и запенится ;)
Шутка...
>> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
> Мне кажется такую функциональность проще реализовать в виде варианта запроса
>> Читать далее
# Re: Мысли про возможное будущее IDEC
shaos (tavern,34) → Andrew Lobanov – 01:38:43 2021-12-22
> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)
> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).
shaos (tavern,34) → Andrew Lobanov – 01:38:43 2021-12-22
> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)
> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).
# Re: Мысли про возможное будущее IDEC
ake (ping,30) → shaos – 18:34:00 2021-12-21
Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC это практически контентно-адресуемая сеть и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений.
> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
Мне кажется такую функциональность проще реализовать в виде варианта запроса индекса, который будет возвращать (кроме идентификатора и закодированного сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет то, как клиент будет отображать полученное содержимое.
ake (ping,30) → shaos – 18:34:00 2021-12-21
Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC это практически контентно-адресуемая сеть и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений.
> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
Мне кажется такую функциональность проще реализовать в виде варианта запроса индекса, который будет возвращать (кроме идентификатора и закодированного сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет то, как клиент будет отображать полученное содержимое.
# Re: Мысли про возможное будущее IDEC
Andrew Lobanov (tavern,1) → shaos – 17:41:54 2021-12-21
shaos> Всем привет
shaos> Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):
Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
Когда доползу до компа, постараюсь ответить более развёрнуто.
Andrew Lobanov (tavern,1) → shaos – 17:41:54 2021-12-21
shaos> Всем привет
shaos> Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):
Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
Когда доползу до компа, постараюсь ответить более развёрнуто.
# Мысли про возможное будущее IDEC
shaos (shaos, 2) → All – 08:13:05 2021-12-21
Всем привет
Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):
1) Кроме base64 существует чуть более компактный способ представления бинарных данных в виде текста - это алгоритм ascii85, когда каждые 4 байта представляются 5-значным 85-ричным числом, где каждая "цифра" это символ от '!' до 'u', плюс буквы 'z' и 'y' несут особый смысл, кодируя четвёрки нулей и пробелов соответственно - в результате данные раздуваются не в 4/3=1.33 раз, как в случае base64 (или uue), а в 5/4=1.25 раз или меньше, что как минимум на 6% компактнее. Можно немного развить ascii85 для кодирования произвольных бинарных данных, назвав новую систему кодирования скажем ascii85+ задействуя остальные неиспользованные символы: 'x' может кодировать четвёрку 0xFF (это может помочь при кодировании прошивок ПЗУ), 'w' - четвёрку 0x80 (это может помочь при кодировании 8-битных беззнаковых WAV-файлов), 'v' - пока может использоваться для детектирования ошибки, фигурные скобки { и } могут выделять закодированный бинарный блок в тексте (наличие явно заданного стартового символа упрощает парсинг, а наличие явно заданного терминатора поможет обрабатывать пограничные ситуации, когда концовка файла не влезает в 4 байта целиком), а ~ и | могут использоваться для каких-то особых случаев (см.ниже). Этот подход можно использовать для встраивания бинарных файлов в текст сообщений как вложений (аля ююки), указывая имя файла после втавки (чтобы клиент знал с чем этот файл надо есть и надо ли):
Старые клиенты будут показывать такие сообщения как текст, а новые клиенты могут получать такие сообщения даже со старых узлов и показывать картинки как картинки или файлы как вложения (ряд иконок внизу сообщения), которые можно сохранить на диск на стороне клиента.
2) Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:
>> Читать далее
shaos (shaos, 2) → All – 08:13:05 2021-12-21
Всем привет
Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):
1) Кроме base64 существует чуть более компактный способ представления бинарных данных в виде текста - это алгоритм ascii85, когда каждые 4 байта представляются 5-значным 85-ричным числом, где каждая "цифра" это символ от '!' до 'u', плюс буквы 'z' и 'y' несут особый смысл, кодируя четвёрки нулей и пробелов соответственно - в результате данные раздуваются не в 4/3=1.33 раз, как в случае base64 (или uue), а в 5/4=1.25 раз или меньше, что как минимум на 6% компактнее. Можно немного развить ascii85 для кодирования произвольных бинарных данных, назвав новую систему кодирования скажем ascii85+ задействуя остальные неиспользованные символы: 'x' может кодировать четвёрку 0xFF (это может помочь при кодировании прошивок ПЗУ), 'w' - четвёрку 0x80 (это может помочь при кодировании 8-битных беззнаковых WAV-файлов), 'v' - пока может использоваться для детектирования ошибки, фигурные скобки { и } могут выделять закодированный бинарный блок в тексте (наличие явно заданного стартового символа упрощает парсинг, а наличие явно заданного терминатора поможет обрабатывать пограничные ситуации, когда концовка файла не влезает в 4 байта целиком), а ~ и | могут использоваться для каких-то особых случаев (см.ниже). Этот подход можно использовать для встраивания бинарных файлов в текст сообщений как вложений (аля ююки), указывая имя файла после втавки (чтобы клиент знал с чем этот файл надо есть и надо ли):
Посмотрите на эту весёлую картинку:
{Abhdhj!$^390+-
...
Bhdbdfjg}=funny.gif
Старые клиенты будут показывать такие сообщения как текст, а новые клиенты могут получать такие сообщения даже со старых узлов и показывать картинки как картинки или файлы как вложения (ряд иконок внизу сообщения), которые можно сохранить на диск на стороне клиента.
2) Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:
>> Читать далее