AL> То есть для тебя 32-бита и 64-бита это теологический, а не технический вопрос?

Для меня - да :)

AL> Конечно, есть частные случаи, когда 32 бит хватит на всё и некоторые корпорации старательно сокращают их количество. Но я бы не назвал уход с 32 бит именно модой.

У тех кому хватает 32 бита - это частный случай. Кому не хватает - тоже. Абсолютной необходимости ни у кого нет и быть не может. Для большинства обычных людей разрядность компьютера вообще никакого значения не имеет и они могут её даже и не знать. При выборе компьютера они руководствуются вовсе не техническими критериями. Не стоит забывать, что доля именно специалистов в информатике среди пользователей вычислительных устройств относительно невелика. Вон у меня сосед пользуется телевизором, подключённым к интернету, а сам в информатике абсолютный ноль. Вопрос: зачем ему этот интернет в телевизоре? Зачем вообще людям, например, социальные сети? Только не надо меня убеждать, что они без них жить не могут. Жили же раньше. Так меня когда-то убеждал один мой сотрудник по поводу жизненной необходимости своего автомобиля, на котором он на работу ездил. До меня так и не доходит, как можно путать удобства с жизненной необходимостью. Может потому, что я сам удобствам никакого значения не придаю - это абсолютно субъективно.

AL>> В народе это называется "бабский аргумент". Тематику разделять это нормально. Плодить сущности ради плодения сущностей - это не нормально.
hugeping> Я кстати не против перейти на новую болталку, но только ЕСЛИ на это согласятся остальные. Иначе, у нас просто будет две эхи... С другой стороны, действиетельно, я могу просто почистить старые сообщения и всё... Просто лень. :)

Да ради бока же :) Просто бессмысленное действие ради бессмысленного действия. А завтра кто-нибудь захочет перекатить другую конфу только ради перекатывания другой конфы. А после завтра ещё разок. Какой в этом смысл? Сэкономить пару мегабайт на диске?

+++ Caesium/0.4 RC1

AL> В народе это называется "бабский аргумент". Тематику разделять это нормально. Плодить сущности ради плодения сущностей - это не нормально.

Я кстати не против перейти на новую болталку, но только ЕСЛИ на это согласятся остальные. Иначе, у нас просто будет две эхи... С другой стороны, действиетельно, я могу просто почистить старые сообщения и всё... Просто лень. :)

> нифига не понял, почему это в develop

Да это мой косяк. Постил из браузера - он эху не ту подставил. Главное, что тред один и тот же и msgid не потерялись.

> ЗЫЖ Го в трубу уже с этими разговорами :)

я, собственно, про то, что моя станция совместима с подавляющим большинством старых компьютеров.

>> Зачем ишак, когда есть мозаик? :)
ii.51t.ru> ну, в mosaic я, честно говоря, не осилил, как там банально открыть url :) в ie осилил. ie3 был моим первым браузером, потом уже netscape. в пятой версии опера начала поддерживать русские буквы, но у меня опера началась только с 6.0.5, на winnt4 и на долгие годы, в т.ч. в linux, версии этак до 10-й

Пользовался оперой с 7 по 10 версии. Хотя, ещё до 8 я переполз на огнелис полностью, а опера была вторым браузером. А вот ишаком я пользовался на самой заре своей диалапной жизни.

ЗЫЖ Го в трубу уже с этими разговорами :)

+++ Caesium/0.4 RC1

> Зачем ишак, когда есть мозаик? :)

ну, в mosaic я, честно говоря, не осилил, как там банально открыть url :) в ie осилил. ie3 был моим первым браузером, потом уже netscape. в пятой версии опера начала поддерживать русские буквы, но у меня опера началась только с 6.0.5, на winnt4 и на долгие годы, в т.ч. в linux, версии этак до 10-й

> Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

ii.51t.ru> Для win 3.1 есть ie5

Зачем ишак, когда есть мозаик? :)

+++ Caesium/0.4 RC1

AL>> А вот это, в рамках обсуждения, просто подмена понятий. Не все нововведения одинаково полезны. Зато подменил и вроде как молодец - доказал что-то (нет).
vvs> Обсуждают и доказывают что-то только при наличии общих понятий. Кто это будет обсуждать теологические вопросы с атеистами? Спорить о разнице в мировоззрении - глупейшее занятие, я в этом участвовать не собираюсь. Будем считать, что у нас противоположные взгляды. Опять же флаг в руки.

То есть для тебя 32-бита и 64-бита это теологический, а не технический вопрос? 64-битная архитектура решает конретные технические проблемы, упрощая жизнь. При чём тут мода? У меня в голове нет этого понимания до сих пор.

Конечно, есть частные случаи, когда 32 бит хватит на всё и некоторые корпорации старательно сокращают их количество. Но я бы не назвал уход с 32 бит именно модой.

+++ Caesium/0.4 RC1

Для win 3.1 есть ie5

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

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

>> Для меня тут простая арифметика. Сколько операторов с тобой согласны? Скольким остальным надо будет лезть в настройки узла из-за этого?
ii.51t.ru> прально, лучше всё писать в одной эхе :)

В народе это называется "бабский аргумент". Тематику разделять это нормально. Плодить сущности ради плодения сущностей - это не нормально.

+++ Caesium/0.4 RC1

>> При этом на действительно старой машине со старой системой к тебе всё таки не сходить.
ii.51t.ru> сходить. с дискетами. восьмидюймовыми. или с перфокартами. а в транслит я уж как-нибудь перкодирую.

Речь о сети и пользователях Windows 3.11. С дискетами они, конечно, могут, но лучше бы по сети всё таки.

Хотя, пользователи какого-нибудь Apple ][ могли бы и с дискетами. Хотя, у них вообще-то есть модем.

+++ Caesium/0.4 RC1

> Для меня тут простая арифметика. Сколько операторов с тобой согласны? Скольким остальным надо будет лезть в настройки узла из-за этого?

прально, лучше всё писать в одной эхе :)

> При этом на действительно старой машине со старой системой к тебе всё таки не сходить.

сходить. с дискетами. восьмидюймовыми. или с перфокартами. а в транслит я уж как-нибудь перкодирую.

AL> 1. Это не арифметический вопрос.

Ну если бы только арифметические вопросы не решались голосованием...

AL> 2. Только мнение операторов и значит хоть что-то в этом вопросе. Потому что только одного оператора, который наверняка, как и всегда, пришёл на пару недель, чтобы опять уйти на несколько лет, это не устраивает в то время, как остальным вполне нормально живётся без этой беготни с созданием/архивированием конференций ради создания/архивирования конференций.

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

Всё, что вызвало такую мою реакцию - это что чьей-то правотой здесь не пахнет. Субъективная значимость чьего-то мнения - это что угодно, но только не "правота". Ведь даже если какое-то предложение кого-то не устраивает, то совершенно не обязательно привязывать это к личности автора (ad hominem). И, в любом случае, ни к чему не обязывает. И это невольно заставляет поставить себя на его место.

Просто мои пять копеек.

P.S. А кстати, разве есть какой-то устав, который ограничивает время пребывания операторов в сети? Старожилы имеют особый статус? Напоминает тюремные порядки.

AL>>>> Если первых будет будет больше вторых, то ты прав. Если же меньше, то нет.
vvs>>> Давайте проголосуем, чему равно 235095860486 x 9857605486086085? Если больше половины будет за то, что это 2317482244082922453325937310, то так и есть. Считать запрещено :P
AL>> Я озвучил гораздо более простую задачку. У нас операторов по пальцам пересчитать можно. Именно отсюда моё предположение, что посчитать их - тривиальная, в сущности, задачка. Хотя, отчасти, я согласен, что я могу завышать способности некоторых людей.
vvs> Смысл моего предложения вовсе не в том, что это очень "сложная" задача, а в том, что решать арифметические задачи голосованием - вообще бессмысленно. И аналогично, определять чью-нибудь правоту голосованием - бессмысленно тоже. Так можно только выяснить, какая точка зрения имеет больше сторонников в момент голосования и только среди его участников.

1. Это не арифметический вопрос.
2. Только мнение операторов и значит хоть что-то в этом вопросе. Потому что только одного оператора, который наверняка, как и всегда, пришёл на пару недель, чтобы опять уйти на несколько лет, это не устраивает в то время, как остальным вполне нормально живётся без этой беготни с созданием/архивированием конференций ради создания/архивирования конференций.

+++ Caesium/0.4 RC1

AL>> Не вижу как таковой моды. Вижу только удобство в возможности легче и быстрее обрабатывать больший объём информации.
vvs> Ну, если кто-то не хочет что-нибудь видеть, то это не значит, что этого нет. Зачем, например, покупают iPhone? Ах это просто удобство и эффективность обработки информации? Ну да, ну да...

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

AL>> Время не имеет значения только для бессметрных людей с бесплатной электроэнергией. И таки почему вдруг упирательство идёт именно в 32 бита, а не, скажем, в 16? Ведь переход с 16 на 32 тоже был модой, если быть последовательными.
vvs> Не на сто процентов, но мода там участвовала тоже. 32-бита здесь просто актуальнее для присутствующих. Ну какой смысл сейчас вспоминать уже далёкое прошлое? У меня есть ностальгия и по огромным мэйнфреймам, но это уже не актуально для тех, кто сейчас это читает.

Из здесь присутствующих это актуально двум человекам. Так что в лучшем случае лишь для некоторых из здесь присутствующих. Причём, судя по всему, актуальность никак не обусловлена технически.

vvs> А время значение, конечно, имеет, но только не в том контексте, о котором идёт речь.

В каком же? В обсуждаемом нами вопросе вполне имеет. И таки нет ответа почему именно 32 бита, а не 16 или 8. Ведь 32 бит пришли именно на замену 16.

AL>> P.S.: Если всё дело в моде, то почему нет тотального перехода с 64 бит на 128?
vvs> А? А почему 128 бит должно быть моднее? Ну если будет, то и перейдут. У меня нет желания выяснять здесь почему что-то является модным для кого-то.

Про моду ты начал. Сам притащил, сам говоришь, что тебе это не важно. А почему 128 должно быть моднее я не знаю. Как и не знаю почему 64 моднее 32. Но ты говоришь о моде, значит ты точно знаешь почему. Ну и почему, если будет? 128-бит уже было спроектировано в конце 90-х и то, что оно не пошло в массы как процессор общего назначения, это не неповоротливость моды, а практический подход. В них просто нет смысла, в то время как в 64-битных машинах смысл есть.

+++ Caesium/0.4 RC1

AL>>> Если первых будет будет больше вторых, то ты прав. Если же меньше, то нет.
vvs>> Давайте проголосуем, чему равно 235095860486 x 9857605486086085? Если больше половины будет за то, что это 2317482244082922453325937310, то так и есть. Считать запрещено :P

AL> Я озвучил гораздо более простую задачку. У нас операторов по пальцам пересчитать можно. Именно отсюда моё предположение, что посчитать их - тривиальная, в сущности, задачка. Хотя, отчасти, я согласен, что я могу завышать способности некоторых людей.

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

AL> Не вижу как таковой моды. Вижу только удобство в возможности легче и быстрее обрабатывать больший объём информации.

Ну, если кто-то не хочет что-нибудь видеть, то это не значит, что этого нет. Зачем, например, покупают iPhone? Ах это просто удобство и эффективность обработки информации? Ну да, ну да...

AL> Время не имеет значения только для бессметрных людей с бесплатной электроэнергией. И таки почему вдруг упирательство идёт именно в 32 бита, а не, скажем, в 16? Ведь переход с 16 на 32 тоже был модой, если быть последовательными.

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

А время значение, конечно, имеет, но только не в том контексте, о котором идёт речь.

AL> P.S.: Если всё дело в моде, то почему нет тотального перехода с 64 бит на 128?

А? А почему 128 бит должно быть моднее? Ну если будет, то и перейдут. У меня нет желания выяснять здесь почему что-то является модным для кого-то.

AL>> Если первых будет будет больше вторых, то ты прав. Если же меньше, то нет.
vvs> Давайте проголосуем, чему равно 235095860486 x 9857605486086085? Если больше половины будет за то, что это 2317482244082922453325937310, то так и есть. Считать запрещено :P

Я озвучил гораздо более простую задачку. У нас операторов по пальцам пересчитать можно. Именно отсюда моё предположение, что посчитать их - тривиальная, в сущности, задачка. Хотя, отчасти, я согласен, что я могу завышать способности некоторых людей.

+++ Caesium/0.4 RC1

AL>> Тут сугубо экономический вопрос. Мода тут постолько поскольку. Поддержка 32-бит это не только сборка дистрибутива или программы, это ещё и тестирование. Если, например, количество пользователей меньше 1%, уже просто нецелесообразно заниматься поддержкой старой архитектуры.
vvs> Это лишь следствие. А причина в том спросе, который во многом формируется модой. Не было бы спроса, не надо было бы ничего и тестировать. Хотя это лишь один из многих примеров, где разные люди видят противоположные причинно-следственные связи. Ну вот, что было раньше: курица или яйцо? :P

Не вижу как таковой моды. Вижу только удобство в возможности легче и быстрее обрабатывать больший объём информации.

AL>> А что за исследования? Как проводились? Где публиковались? Было бы интересно почитать как измеряют ум. Особенно ум давно умерших людей. Насколько крестьянин XIX века был умнее современного обывателя?
vvs> http://dx.doi.org/10.1016/j.intell.2013.04.006
vvs> И надо всегда помнить, что любая научная модель - это упрощение. "Ум" в общем смысле, измерить невозможно, поскольку нет его однозначного определения. Измеряют какую-то конкретную величину, принятую здесь за "ум". Галилей в своей модели тоже не учитывал сопротивление воздуха, тем не менее это было полезно для механики. Философия же вечно обсуждает некие общие нечёткие понятия и поэтому от неё мало толку на практике, если только не считать бессмысленных споров о смысле слов.

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

AL>> Ну так это же здорово. Тебе не надо собирать мир на целевой дохлой машинке. Собрал что надо как надо под нужную архитектуру на мощном сервере и заливай себе хоть на одноплатник. Это выгодно и по времени и по электроэнергии.
vvs> Это плохо с точки зрения независимости от прихотей моды, как в данном случае. Время в данном случае не имеет значения. А с точки зрения эффективности использования электроэнергии, все должны питаться в столовой и жить в бараках :P

Время не имеет значения только для бессметрных людей с бесплатной электроэнергией. И таки почему вдруг упирательство идёт именно в 32 бита, а не, скажем, в 16? Ведь переход с 16 на 32 тоже был модой, если быть последовательными.

P.S.: Если всё дело в моде, то почему нет тотального перехода с 64 бит на 128?

+++ Caesium/0.4 RC1

AL> Если первых будет будет больше вторых, то ты прав. Если же меньше, то нет.

Давайте проголосуем, чему равно 235095860486 x 9857605486086085? Если больше половины будет за то, что это 2317482244082922453325937310, то так и есть. Считать запрещено :P

AL> Тут сугубо экономический вопрос. Мода тут постолько поскольку. Поддержка 32-бит это не только сборка дистрибутива или программы, это ещё и тестирование. Если, например, количество пользователей меньше 1%, уже просто нецелесообразно заниматься поддержкой старой архитектуры.

Это лишь следствие. А причина в том спросе, который во многом формируется модой. Не было бы спроса, не надо было бы ничего и тестировать. Хотя это лишь один из многих примеров, где разные люди видят противоположные причинно-следственные связи. Ну вот, что было раньше: курица или яйцо? :P

AL> А что за исследования? Как проводились? Где публиковались? Было бы интересно почитать как измеряют ум. Особенно ум давно умерших людей. Насколько крестьянин XIX века был умнее современного обывателя?

http://dx.doi.org/10.1016/j.intell.2013.04.006

И надо всегда помнить, что любая научная модель - это упрощение. "Ум" в общем смысле, измерить невозможно, поскольку нет его однозначного определения. Измеряют какую-то конкретную величину, принятую здесь за "ум". Галилей в своей модели тоже не учитывал сопротивление воздуха, тем не менее это было полезно для механики. Философия же вечно обсуждает некие общие нечёткие понятия и поэтому от неё мало толку на практике, если только не считать бессмысленных споров о смысле слов.

AL> Ну так это же здорово. Тебе не надо собирать мир на целевой дохлой машинке. Собрал что надо как надо под нужную архитектуру на мощном сервере и заливай себе хоть на одноплатник. Это выгодно и по времени и по электроэнергии.

Это плохо с точки зрения независимости от прихотей моды, как в данном случае. Время в данном случае не имеет значения. А с точки зрения эффективности использования электроэнергии, все должны питаться в столовой и жить в бараках :P

>> Это один и тот же вопрос. На половине узлов твоя новая труба 2033, на второй половине труба 2032. Не за то боролись большевики.
ii.51t.ru> pipe.2032 is dead. если прямо сейчас, ничего не меняя, отправить всем её в архив - ничо не изменится :) остальные эхи тоже dead, но там хотя бы архивы сообщений могут представлять ценность. конечно, если их не завалить оффтопиком, чем мы все здесь начинаем потихоньку заниматься, поэтому офтопик сворачиваем, как говорил Славик: "посидим, поговорим о тоссерах"

pipe.2033 тоже мертва. Никому ненужная болталка, которая при этом ещё сугубо твоя локалка, никуда не проброшенная. Если я напишу в 2032, то сообщение пройдёт по всей сети и никому при этом не надо судорожно переписывать конфиги потому что на тебя что-то там "давит". А если ты напишешь в 2033, то сможешь мило пообщаться сам с собой.

+++ Caesium/0.4 RC1

>> Революция ради революции. Не хочешь старых переписок - не читай и не качай. Раз уж всё равно разброд и шатание, то хотя бы оставь текущее общение без фрагментации.
ii.51t.ru> Да уже поздно, уже idec.talks в болталку превратили :)

По вопросам сети она и есть болталка.

ii.51t.ru> Просто хотелось общую болталку без legacy, чтобы с чистого листа. Я лично не хочу pipe.2032, она давит на меня воспоминаниями. :) И противоречит моим замыслам. Никого в неё не тяну, но 2032 брать не буду.

Твоё право. Хоть каждый день у себя новые болталки создавай. Только не агитируй народ на сегментацию.

+++ Caesium/0.4 RC1

>> Ну ой тогда. Тянуть весь мир в то, что может потянуть Микро-80, это луддитство чистой воды. На третьем же пентиуме вполне себе работает и 11 дебиан. Конечно, система после старта с иксами и оконным менеджером отъедает 70 МБ ОЗУ, но с этим вполне можно жить.
ii.51t.ru> у меня на третьем пентиуме стоят OpenBSD 7.2, Alt 3.0 и Debian 4.0. Мне так хочется. С KDE и Гномом, соответственно. Шик, блеск, все дела. OpenBSD современный я и на первый пень ставил. Да и современный Links во FreeDOS запускал и свой сайт смотрел: единственное, в графическом режиме русский ввод не работает. Жаль, эху со всеми тестами потерял.

При этом на действительно старой машине со старой системой к тебе всё таки не сходить.

ii.51t.ru> Вопрос не в том, куда тянуть весь мир. Вопрос, наоборот, а куда можно сходить со старой системы. Ко мне - можно. А планов сделать всё на html8, чтобы было "ну вааще круто" у меня не было.

Ну если у человека не было планов сделать всё на HTML1 с однобайтной кодировкой, чтобы было "ну вааще круто", то можно ли его за это винить?

+++ Caesium/0.4 RC1

>> В том же фидонете это никого не парило никогда.
ii.51t.ru> в фидонете тоссинг, а не консистентные эхи. меня, кстати, это парило, когда подписываешься на эху, а там пусто. у partoss была команда ареафиксу, чтобы набрать сообщений из эхи, но для passthru-эх и вообще на практике это не работало. поэтому я это учитывал при своей схеме.

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

Для меня тут простая арифметика. Сколько операторов с тобой согласны? Скольким остальным надо будет лезть в настройки узла из-за этого?

Если первых будет будет больше вторых, то ты прав. Если же меньше, то нет.

+++ Caesium/0.4 RC1

AL>> Старое остаётся в прошлом. Как отошли 8-разрядные машины, за ними ушли в прошлое 16-разрядные, так отходят и 32-разрядные. Это остаётся только принять или изобретать велосипеды
vvs> Когда толпа бегает за модой, то это её дело. Плохо только то, что и другим приходится приспосабливаться, кому на моду наплевать и у них всё и так прекрасно работало. Ну, я уже сижу под 64-бит, выбора особого нет :(

Тут сугубо экономический вопрос. Мода тут постолько поскольку. Поддержка 32-бит это не только сборка дистрибутива или программы, это ещё и тестирование. Если, например, количество пользователей меньше 1%, уже просто нецелесообразно заниматься поддержкой старой архитектуры.

vvs> И так во всём, бракованные стереотипы навязываются в качестве эталона. Удручает, что жить становится всё хуже и это объективная тенденция :( Кто теперь осмелится утверждать, что ностальгия по прошлому вызвана исключительно ушедшей молодостью? Тем же, кто помоложе просто не с чем сравнивать. Вот и научные исследования утверждают, что в викторианскую эпоху люди были умнее :( Автаркия полезна не столько из-за политических рисков, сколько из-за экзистенциальных... По крайней мере для меня, самое страшное - это просто быть, как все.

А что за исследования? Как проводились? Где публиковались? Было бы интересно почитать как измеряют ум. Особенно ум давно умерших людей. Насколько крестьянин XIX века был умнее современного обывателя?

AL>> Гентушники уже давно занимаются кроскомпиляцией, насколько я помню.
vvs> Вот-вот :/

Ну так это же здорово. Тебе не надо собирать мир на целевой дохлой машинке. Собрал что надо как надо под нужную архитектуру на мощном сервере и заливай себе хоть на одноплатник. Это выгодно и по времени и по электроэнергии.

+++ Caesium/0.4 RC1

> Это один и тот же вопрос. На половине узлов твоя новая труба 2033, на второй половине труба 2032. Не за то боролись большевики.

pipe.2032 is dead. если прямо сейчас, ничего не меняя, отправить всем её в архив - ничо не изменится :) остальные эхи тоже dead, но там хотя бы архивы сообщений могут представлять ценность. конечно, если их не завалить оффтопиком, чем мы все здесь начинаем потихоньку заниматься, поэтому офтопик сворачиваем, как говорил Славик: "посидим, поговорим о тоссерах"

> Вот и научные исследования утверждают, что в викторианскую эпоху люди были умнее :(

Да чего уж там, в советскую люди были умнее.

На ютубе можно найти видео с советскими школьниками и посмотреть, как они рассуждают. Причём не единично, а в качестве тенденции. Сейчас я такого представить даже не могу.

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

Да уже поздно, уже idec.talks в болталку превратили :)

Просто хотелось общую болталку без legacy, чтобы с чистого листа. Я лично не хочу pipe.2032, она давит на меня воспоминаниями. :) И противоречит моим замыслам. Никого в неё не тяну, но 2032 брать не буду.

> А IS-DOS отлично работал на спектруме.

У меня там работала последняя, 10-я версия Альта. Просто у меня щас нет этой таблетки.

> Ну ой тогда. Тянуть весь мир в то, что может потянуть Микро-80, это луддитство чистой воды. На третьем же пентиуме вполне себе работает и 11 дебиан. Конечно, система после старта с иксами и оконным менеджером отъедает 70 МБ ОЗУ, но с этим вполне можно жить.

у меня на третьем пентиуме стоят OpenBSD 7.2, Alt 3.0 и Debian 4.0. Мне так хочется. С KDE и Гномом, соответственно. Шик, блеск, все дела. OpenBSD современный я и на первый пень ставил. Да и современный Links во FreeDOS запускал и свой сайт смотрел: единственное, в графическом режиме русский ввод не работает. Жаль, эху со всеми тестами потерял.

Вопрос не в том, куда тянуть весь мир. Вопрос, наоборот, а куда можно сходить со старой системы. Ко мне - можно. А планов сделать всё на html8, чтобы было "ну вааще круто" у меня не было.

> В том же фидонете это никого не парило никогда.

в фидонете тоссинг, а не консистентные эхи. меня, кстати, это парило, когда подписываешься на эху, а там пусто. у partoss была команда ареафиксу, чтобы набрать сообщений из эхи, но для passthru-эх и вообще на практике это не работало. поэтому я это учитывал при своей схеме.

AL> Старое остаётся в прошлом. Как отошли 8-разрядные машины, за ними ушли в прошлое 16-разрядные, так отходят и 32-разрядные. Это остаётся только принять или изобретать велосипеды

Когда толпа бегает за модой, то это её дело. Плохо только то, что и другим приходится приспосабливаться, кому на моду наплевать и у них всё и так прекрасно работало. Ну, я уже сижу под 64-бит, выбора особого нет :(

И так во всём, бракованные стереотипы навязываются в качестве эталона. Удручает, что жить становится всё хуже и это объективная тенденция :( Кто теперь осмелится утверждать, что ностальгия по прошлому вызвана исключительно ушедшей молодостью? Тем же, кто помоложе просто не с чем сравнивать. Вот и научные исследования утверждают, что в викторианскую эпоху люди были умнее :( Автаркия полезна не столько из-за политических рисков, сколько из-за экзистенциальных... По крайней мере для меня, самое страшное - это просто быть, как все.

AL> Гентушники уже давно занимаются кроскомпиляцией, насколько я помню.

Вот-вот :/

vvs> ii.51t.ru> alt 32битный с mate у меня нормально работал на таблетке с a100 на 600 мгц вместо процессора, правда памяти 2 гб
vvs> Каждый смотрит со своей колокольни. Федора на 256 МБ даже не загрузится. Мой далеко не полный список претензий к последним версиям 32-битных линуксов, которые мне пришлось испытывать: не работает Mount Rainier, suspend to disk (похоже проблема связана с интеловской графикой), Qt5. Если речь не обязательно о линуксе, то можно добавить кучу бинарных приложений, откомпилированных под Pentium 4 с SSE2 (например Firefox) или, на закуску, древние, ещё досовские игры, портированные исключительно под OpenGL 3.3 :) Да, есть еще проблемы с совместимостью из-за забаненных старых версий протоколов и алгоритмов, типа SHA1. Доставляют также изменённые умолчания, например в samba, из-за чего новые версии не хотят коннектиться к Windows XP (это поправимо, но лишняя нервотрёпка). Вообще, старое железо работает под новым ядром только хуже, некому тестировать, всем плевать на 32-битные баги.

Старое остаётся в прошлом. Как отошли 8-разрядные машины, за ними ушли в прошлое 16-разрядные, так отходят и 32-разрядные. Это остаётся только принять или изобретать велосипеды, как делают в рамках проекта Sprinter с их SprinterNet. То есть писать некий прокси-шлюз, который будет забирать из большого интернета то, что надо и предоставлять в удобоваримом для слабой машинки виде.

vvs> Сидеть и самостоятельно всё это исправлять, перекомпилировать целые ОС с исходников - нет ни ресурсов, ни желания. И, кстати, кто-нибудь пробовал самостоятельно откомпилировать Firefox или WebKit на 32-бит? Там же недостаточно 4 ГБ памяти. Та же хрень с Хаскеллом, возьмите, например, pandoc. Тут даже не имеет значения, что компьютер не старый. Особенно весело должно быть пользователям Gentoo (не смотрел, как они в таком случае выкручиваются). Вообще, для меня ОС должна работать из коробки и не отвлекать от основных задач.

Гентушники уже давно занимаются кроскомпиляцией, насколько я помню.

+++ Caesium/0.4 RC1

>> Давай. В чём принципиальное отличие новой трубы от старой? Какая выгода будет операторам и пользователям от перехода на новую эху?
ii.51t.ru> тем, что она новая, без древних переписок с древними людьми. таким эхам место в архиве. я не вижу смысла держаться за старую, это просто болталка. знач, pipe.2033 будет моим эксклюзивом, осталось придумать, куда её протянуть :)

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

+++ Caesium/0.4 RC1

>> Какой смысл в архиве?
ii.51t.ru> а какой смысл в неконсистентных эхах?

Это один и тот же вопрос. На половине узлов твоя новая труба 2033, на второй половине труба 2032. Не за то боролись большевики.

ii.51t.ru> в архив отправляются сообщения, которые понадобятся крайне редко. в случае с болталками нет смысла хранить переписку в эхах, а то вдруг кто-то пойдёт, зачитается и не вернётся. у меня на такие случаи поддерживается вид "эха-книжка", а на 3500 сообщений это будет очень большая книжка :)

Заставлять всю сеть что-то делать только потому, что это будет удобно на одном только твоём узле... Ну такое.

+++ Caesium/0.4 RC1

>> Ну скоро останется только генту компилить под 32-бита или слаку ставить, пока Пат не выкинет поддержку. Пока что Debian 11 работает на старых машинах, но это тоже временно.
ii.51t.ru> alt 32битный с mate у меня нормально работал на таблетке с a100 на 600 мгц вместо процессора, правда памяти 2 гб

А IS-DOS отлично работал на спектруме.

+++ Caesium/0.4 RC1

>> Ты неправильно видишь целевую аудиторию. Со старых систем и компьютеров доступ никто не запрещал. Если ты не хочешь обновлять сертификаты у себя, то это ты себе запрещаешь использовать эти сайты, а не тебе.
ii.51t.ru> дело не в сертификатах, а в протоколах, которые на новых сайтах уже заблокированы. точно так же я не могу зайти по ssh на современные системы - поэтому telnet рулит, как 40 лет назад работал, так и работает :) аналогично с http

Ну ой тогда. Тянуть весь мир в то, что может потянуть Микро-80, это луддитство чистой воды. На третьем же пентиуме вполне себе работает и 11 дебиан. Конечно, система после старта с иксами и оконным менеджером отъедает 70 МБ ОЗУ, но с этим вполне можно жить.

+++ Caesium/0.4 RC1

>> На NCSA Mosaic 1 работает? Или оставишь жителей Windows 3.11 за бортом?
ii.51t.ru> не работает в ie3 в win95 - не поддерживается utf-8. сначала хотел приделать перекодировку, но потом решил, что пользователи ie3 должны страдать. нетскейп навигатор и коммуникатор 4.77 под debian sarge работают, под виндой не проверял

Пользователи любой версии IE должны страдать. Но NCSA Mosaic то за что?

+++ Caesium/0.4 RC1

>> А кто тебя заставляет их тянуть? Просто качай последние 100/10/5/1 сообщений и радуйся жизни.
ii.51t.ru> тогда не будет целостности эх - на одной станции столько то сообщений, а на другой - другое. чтобы была целостность, надо чтобы везде было одно и то же.

А надо ли? Я серьёзно. В том же фидонете это никого не парило никогда. Эха это не столько способ хранения информации, сколько способ её передачи же.

ii.51t.ru> с другой стороны, там ценность только для архива, это же болталка. болталки проще перезатирать

Вот да. Для болталки не имеет значения.

+++ Caesium/0.4 RC1

ii.51t.ru> alt 32битный с mate у меня нормально работал на таблетке с a100 на 600 мгц вместо процессора, правда памяти 2 гб

Каждый смотрит со своей колокольни. Федора на 256 МБ даже не загрузится. Мой далеко не полный список претензий к последним версиям 32-битных линуксов, которые мне пришлось испытывать: не работает Mount Rainier, suspend to disk (похоже проблема связана с интеловской графикой), Qt5. Если речь не обязательно о линуксе, то можно добавить кучу бинарных приложений, откомпилированных под Pentium 4 с SSE2 (например Firefox) или, на закуску, древние, ещё досовские игры, портированные исключительно под OpenGL 3.3 :) Да, есть еще проблемы с совместимостью из-за забаненных старых версий протоколов и алгоритмов, типа SHA1. Доставляют также изменённые умолчания, например в samba, из-за чего новые версии не хотят коннектиться к Windows XP (это поправимо, но лишняя нервотрёпка). Вообще, старое железо работает под новым ядром только хуже, некому тестировать, всем плевать на 32-битные баги.

Сидеть и самостоятельно всё это исправлять, перекомпилировать целые ОС с исходников - нет ни ресурсов, ни желания. И, кстати, кто-нибудь пробовал самостоятельно откомпилировать Firefox или WebKit на 32-бит? Там же недостаточно 4 ГБ памяти. Та же хрень с Хаскеллом, возьмите, например, pandoc. Тут даже не имеет значения, что компьютер не старый. Особенно весело должно быть пользователям Gentoo (не смотрел, как они в таком случае выкручиваются). Вообще, для меня ОС должна работать из коробки и не отвлекать от основных задач.

>вернёмся к сабжу. у меня вопрос - а как вообще что-то фетчить со станции, какой url? :)
url тот же - https://tgistation.ru/ (теперь и http можно).

>хочу забрать bot.habr.rss (в ro) и game.rogue.14
Пожалуйста. Только хабр редко что-то годное выдает, а в game.rogue.14 вроде давно уж ничего не писалось.

>а где ещё есть роботные эхи?
В таверне, насколько я знаю, имеется всякое - http://idec.spline-online.tk/

вернёмся к сабжу. у меня вопрос - а как вообще что-то фетчить со станции, какой url? :)

хочу забрать bot.habr.rss (в ro) и game.rogue.14 (но тогда нужен бекфетч)

а где ещё есть роботные эхи?

добавил к себе эхи linux.14 и std.game с hugeping.tk

> Давай. В чём принципиальное отличие новой трубы от старой? Какая выгода будет операторам и пользователям от перехода на новую эху?

тем, что она новая, без древних переписок с древними людьми. таким эхам место в архиве. я не вижу смысла держаться за старую, это просто болталка. знач, pipe.2033 будет моим эксклюзивом, осталось придумать, куда её протянуть :)

> Какой смысл в архиве?

а какой смысл в неконсистентных эхах?

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

> Ну скоро останется только генту компилить под 32-бита или слаку ставить, пока Пат не выкинет поддержку. Пока что Debian 11 работает на старых машинах, но это тоже временно.

alt 32битный с mate у меня нормально работал на таблетке с a100 на 600 мгц вместо процессора, правда памяти 2 гб

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

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

> А в чём принципиальная разница?

Пётр уже ответил

> На NCSA Mosaic 1 работает? Или оставишь жителей Windows 3.11 за бортом?

не работает в ie3 в win95 - не поддерживается utf-8. сначала хотел приделать перекодировку, но потом решил, что пользователи ie3 должны страдать. нетскейп навигатор и коммуникатор 4.77 под debian sarge работают, под виндой не проверял

> А кто тебя заставляет их тянуть? Просто качай последние 100/10/5/1 сообщений и радуйся жизни.

тогда не будет целостности эх - на одной станции столько то сообщений, а на другой - другое. чтобы была целостность, надо чтобы везде было одно и то же.

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

Ordos> После некоторых размышлений таки убрал принудительный редирект на https. Теперь работает и так и так, по желанию. Мне не критично, а кому-то может и да.

Крут!

Ordos> Заодно зацепил к себе https://ii.51t.ru/ii/. Эхи idec.talks и zx.spectrum. Пусть будет.

Значит мне можно не перенастраивать фетчер. Люблю, когда мне не надо что-либо делать :)

+++ Caesium/0.4 RC1

>> Сейчас фетч "поумнел" и он адаптивный, то-есть все 3500 сообщений фечнутся только один раз. На сеть нагрузки с моей стороны никакой. В общем, я пока забираю pipe2032.
ii.51t.ru> ну они всегда один раз забираются. я не понимаю просто смысла держать эху с сообщениями лет за 9, которая просто болталка. такие вещи надо держать в архиве.

Ну так держи. Кто ж тебе запрещает то? Хоть в архиве, хоть в кладовке, хоть на полочке. Зачем всем то этим заниматься? Не хочешь ни разу тянуть всю эху - тебя никто не заставляет. Можешь тянуть хоть последние 10 сообщений и потом только новое.

ii.51t.ru> просто у нас сейчас в таком случае болталкой стала idec.talks, сиё не очень хорошо :) ладно, буду искать линка на pipe.2033, 3500 сообщений, некоторые из которых мне вообще не нравятся, я хранить не хочу - хочу историю с чистого листа.

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

ii.51t.ru> ясно. не буду гейтовать. буду pipe.2033 рекламировать :)

Давай. В чём принципиальное отличие новой трубы от старой? Какая выгода будет операторам и пользователям от перехода на новую эху?

+++ Caesium/0.4 RC1

>> Про pipe.2033 -- если создание эхи приведёт к тому что у нас будет две эхи, вместо одной, то я бы этого не хотел. Так что я не то чтобы инициативу не поддерживаю, я считаю что это нужно всем решать станциям.
ii.51t.ru> так я и выносил вопрос на все станции. все станции молчат. pipe.2032 давно не использовалась, а таскать 3500 сообщений туда-сюда из чатовой эхи смысла нет. именно поэтому изначально был обязательный постфикс, чтобы "освежать" эхи а старую инфу уводить в архив.

Чтобы не таскать 3500 сообщений туда-сюда достаточно использовать нормальный софт. Или допилить свой софт до нормального состояния. А архивы это удел ii и 2014-го года. Уже 8+ лет как не актуально.

+++ Caesium/0.4 RC1

hugeping> Про pipe.2033 -- если создание эхи приведёт к тому что у нас будет две эхи, вместо одной, то я бы этого не хотел. Так что я не то чтобы инициативу не поддерживаю, я считаю что это нужно всем решать станциям.

Смысла нет совершенно, так как это решает только проблемы лентяев, которые не могут добавить поддержку срезов в фетчер :)

+++ Caesium/0.4 RC1

iiii> 2. что думаешь о создании эхи pipe.2033 и отправке 2032 в архив

Какой смысл в архиве? Ну кроме недофетчеров, которые не поддерживают стандарт в полном объёме.

+++ Caesium/0.4 RC1

hugeping> В кои-то веки -- оживление!
hugeping> Мне тоже не нравится принудительный https, но тут каждый сам решает что на ноде крутить. Опять же, есть технические нюансы. Мне кажется, что заворот http на https это сейчас настройка по умолчанию много где. На моей ноде всё сделано руками, поэтому мне было не сложно оставить выбор.

Вот тут то и непонятно - какое кому дело, пока есть узлы, работающие по http. Всё равно основное всё ходит по всем, а остальное и прокинуть можно при желании.

hugeping> P.S. gemini требует ssl и это для меня существенный минус. Выкидывает за борт всё ретро сразу. Хотя в остальном gemini мне очень нравится...

Да. Тоже это в gemini не нравится.

+++ Caesium/0.4 RC1

shaos>> Ну новых планов не выпускают, а дебианы - выпускают. Какой смысл сидеть на старой версии если уже было выпущено много новых с обновлениями (в том числе секьюрными) и т.д.? Вот у меня есть старый повербук на G4 - там ничего новее MacOS X 10.4 не идёт ну я там и сижу в сафари который не обновлялся с 2007 года и тоже страдаю по недоступности многих сайтов https (хотя вот например некоторые летсэнкрипнутые сайты там открываются), но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)
vvs> "Не корысти ради, а токмо..." ради верности фактам. Я дебианом никогда сам не пользовался, но вот федорой - много лет. И с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем". Да и до этого минимальные требования памяти уже заметно превышали возможности старых компьютеров. Ну и, например, многие перестали поддерживать старые процессора ниже Pentium 4. Я с этим только вчера сталкивался, пытаясь установить android-x86 на старый комп (не ради любопытства, кстати).

Ну скоро останется только генту компилить под 32-бита или слаку ставить, пока Пат не выкинет поддержку. Пока что Debian 11 работает на старых машинах, но это тоже временно.

+++ Caesium/0.4 RC1

iiii> Я просто логики не вижу. Сделать сайт, лучше всего подходящий для старых систем и компьютеров, и запретить к нему доступ старым системам и компьютерам. И непонятно, к чему указывать, что у нас нет того, того и того, если основная целевая аудитория этого всё равно не увидит :)

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

+++ Caesium/0.4 RC1

Ordos> iiii> а что мешает использовать javascript, cookie, картинки? какой тогда смысл выпячивать "тут нет того и этого"?
Ordos> Разве кто-то что-то выпячивал? Просто констатация факта и не более того. Уж извините, но сделано так, как я посчитал нужным. В том числе и несчастный принудительный https. Где-то в стандартах указывается, что его нельзя использовать?
Можешь хоть по FTP или SSH трафик отдавать. Это не столько принципиально. Если у одного конкретного оператора что-то подгорает от твоего HTTPS, то это проблема одного конкретного оператора. Тем более, что он появляется раз в пятилетку набросить на вентилятор, что мы тут неправильно все живём, и снова сгинуть в небытие.

Ordos> P. S. Ну хоть эха оживилась и то хорошо.

Это конвульсии :)

+++ Caesium/0.4 RC1

>> но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)
iiii> а что мешает использовать javascript, cookie, картинки? какой тогда смысл выпячивать "тут нет того и этого"?

Наличие кучи актуальных браузеров, где это всё или не работает или работает некорректно.

+++ Caesium/0.4 RC1

iiii> я про то, какие эхи гейтовать: std.hugeping это локальный блог или глобальный?

А в чём принципиальная разница?

+++ Caesium/0.4 RC1

iiii> От создания контента - к его провайдингу.
iiii> http://ii.51t.ru
iiii> для старых компьютеров - ок. осталось забить контентом. функциональность "эхи как книги" надо будет вернуть, но переосмыслить под "архив эх". никакого https, никакого javascript и css. проверена работа на win 95 с ie4, на debian woody с netscape navigator и на всём остальном.
iiii> сейчас фетчатся эхи idec.talks и pipe.2033 (пока не существующая) с hugeping.tk, поллинг 5 минут
iiii> описание станции (точнее, софта эхи): http://ii.51t.ru/ii/html/about.html

На NCSA Mosaic 1 работает? Или оставишь жителей Windows 3.11 за бортом?

+++ Caesium/0.4 RC1

iiii> а где болтаем-то?

В реале.

+++ Caesium/0.4 RC1

iiii> или std.hugeping тоже теперь болталка? :)

А было иначе? Каждый волен делать у себя что хочет. Анархия.

+++ Caesium/0.4 RC1

iiii> 1. перепись узлов - кто что гейтует? чё ща модно гейтовать

Ничего.

iiii> 2. давайте сделаем новую межсетевую болталку - pipe.2033? новый год всё таки, а тянуть 3500+ сообщений 9-летней давности про болтание не стоит - лучше в архив :)

А кто тебя заставляет их тянуть? Просто качай последние 100/10/5/1 сообщений и радуйся жизни.

+++ Caesium/0.4 RC1

shaos>> Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)
shaos>> Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...
vvs> О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал. Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Так никто оттуда и не намекает, что надо убирать SSL. Кому надо, те просто ставят проксирующий сервер своими силами и не жужжат.

vvs> Конечно ожидать, что все будут этот антиквариат поддерживать - наивно. Но, учитывая специфику сети idec, вообще-то не так уж и глупо.
vvs> P.S. Извините, что влез не в своё дело, но слишком часто приходится видеть это "а зачем вам всё это надо?". Имеет каждый человек право на свои причуды и интересы. И отнестись к ним с сочувствием или хотя бы с пониманием - ничего ведь не отнимется. У меня самого в углу древний комп стоит, на который ничего новее 2005 года не установишь, а выкинуть жалко

Смотря насколько древний. У меня валяется Compaq Evo N600c начала века. На него прекрасно ставится актуальный Debian. Конечно, работает он не очень шустро, на него бессмысленно ставить современный браузер, но в остальном машинка вполне юзабельная и я за ней периодически с удовольствием сижу. Хотя казалось бы: третий пентиум (ещё и М) да 256 МБ ОЗУ.

+++ Caesium/0.4 RC1

>> Хм. Да, это так. Но разве https - это плохо? Первый раз слышу, чтобы были какие-то проблемы.
iiii> Да, есть проблемы. Несовместимость. Поэтому из старых ос на этот сайт не зайти в принципе. Хоть он трижды без javascript и всего остального.

Это, по идее, можно вылечить, обновив сертификаты, которые сто лет как стухли.

>> В любом случае - это всего лишь web-морда станции. И как таковой полезной нагрузки не несёт.
iiii> какая разница, всё остальное тоже работает по https, и нельзя приконнектиться. у меня вон, текстовый клиент гоняется на python 2.4 на debian etch :) к hugeping.tk я могу свободно подключаться, он http

Как будто что-то хорошее :)

+++ Caesium/0.4 RC1

После некоторых размышлений таки убрал принудительный редирект на https. Теперь работает и так и так, по желанию. Мне не критично, а кому-то может и да.

Заодно зацепил к себе https://ii.51t.ru/ii/. Эхи idec.talks и zx.spectrum. Пусть будет.

> Сейчас фетч "поумнел" и он адаптивный, то-есть все 3500 сообщений фечнутся только один раз. На сеть нагрузки с моей стороны никакой. В общем, я пока забираю pipe2032.

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

просто у нас сейчас в таком случае болталкой стала idec.talks, сиё не очень хорошо :) ладно, буду искать линка на pipe.2033, 3500 сообщений, некоторые из которых мне вообще не нравятся, я хранить не хочу - хочу историю с чистого листа.

> Да, теперь понял. У меня скорее всего запрещено создание статей не от меня в этой эхе, но работает ли это если забор идёт через fetch, я не помню. Я посмотрю, чуть позже.

ясно. не буду гейтовать. буду pipe.2033 рекламировать :)

ii.51t.ru> и какие эхи ты фетчишь?

https://club.hugeping.ru/list.txt

ii.51t.ru> так я и выносил вопрос на все станции. все станции молчат. pipe.2032 давно не использовалась, а таскать 3500 сообщений туда-сюда из чатовой эхи смысла нет. именно поэтому изначально был обязательный постфикс, чтобы "освежать" эхи а старую инфу уводить в архив.

Сейчас фетч "поумнел" и он адаптивный, то-есть все 3500 сообщений фечнутся только один раз. На сеть нагрузки с моей стороны никакой. В общем, я пока забираю pipe2032.

> хотя у hugeping тоже нет https,

Он есть, просто не принудительный.

ii.51t.ru> вопрос только в std.hugeping - там основная жизнь, но это всё-таки блог конкретной станции, конкретного автора. возможно, придётся режим read-only предусмотреть.

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

а, ты все свои эхи берёшь. тогда я, наверное, поставлю в обменник zx.spectrum и plan.9, в первой даже из 2022 есть сообщения. вдруг кто ходит и не знает, куда на zx.spectrum и plan.9 зайти

> У меня довольно утилитарное применение idec, я бы даже сказал - эгоистичное. По соображениям простоты я фетчу всё-то, что показываю. Так что фетч я взаимный поставил, но забираться будут только те эхи, которые присутствуют на станции.

я так и не понял, гейтовать std.hugeping или нет?

и какие эхи ты фетчишь? вообще, какой-нибудь бонлист есть или нет, чтобы понимать, что куда ходит? я уже писал, что и откуда фетчу, надо чтобы все сисопы делились такой информацией.

> Про pipe.2033 -- если создание эхи приведёт к тому что у нас будет две эхи, вместо одной, то я бы этого не хотел. Так что я не то чтобы инициативу не поддерживаю, я считаю что это нужно всем решать станциям.

так я и выносил вопрос на все станции. все станции молчат. pipe.2032 давно не использовалась, а таскать 3500 сообщений туда-сюда из чатовой эхи смысла нет. именно поэтому изначально был обязательный постфикс, чтобы "освежать" эхи а старую инфу уводить в архив.

> Кроме того, твоя нода обычно появляется, потом пропадает. :) Ты создаёшь какие то эхи, потом забываешь. Поэтому я с осторожностью отношусь к идее. :)

я и написал, что не создаю больше контент (к тому же старая станция содержала кучу подобного контента, но он, по идее, пропал, потому что оно никуда не гейтовалось :( жалко терять, полезный был, уникальный), а делаю именно гейт в мир для старых компьютеров. собственно, идея возродить и чуть изменить родилась спонтанно, из-за пафоса tgistation, на которую принудительно прибили https, нафиг сбив этот пафос. моей станцией можно реально пользоваться :) это просто окно в мир. хотя у hugeping тоже нет https, но у меня будет свой набор эх, в том числе, видимо, и роботные эхи (опять же, для потребителей контента со старых пк) . из своих эх только локалка, которая негейтуемая и чисто для того, чтобы было.

из лайвовых эх чатилка (лучше 2033, чем 2032), idec.talks как нужная для обмена информацией по самой системе (нужен бонлист!), вопрос только в std.hugeping - там основная жизнь, но это всё-таки блог конкретной станции, конкретного автора. возможно, придётся режим read-only предусмотреть.

iiii> Пётр, я с тебя фетчу idec.talks и pipe.2033

iiii> 1. сделай бекфетч с http://ii.51t.ru/ii/ :)
iiii> 2. что думаешь о создании эхи pipe.2033 и отправке 2032 в архив
iiii> 3. стоит ли гейтовать std.hugeping

iiii> у меня станция заточена под http и старые браузеры (проверено на win95 с ie4)

У меня довольно утилитарное применение idec, я бы даже сказал - эгоистичное. По соображениям простоты я фетчу всё-то, что показываю. Так что фетч я взаимный поставил, но забираться будут только те эхи, которые присутствуют на станции.

Про pipe.2033 -- если создание эхи приведёт к тому что у нас будет две эхи, вместо одной, то я бы этого не хотел. Так что я не то чтобы инициативу не поддерживаю, я считаю что это нужно всем решать станциям.

Кроме того, твоя нода обычно появляется, потом пропадает. :) Ты создаёшь какие то эхи, потом забываешь. Поэтому я с осторожностью отношусь к идее. :)

>> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".

shaos> Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:

Забавно. Я, вроде бы, совершенно ясно написал, что речь идёт вовсе не о дебиане, а о федоре и каких-то других ОС. Кроме того я упомянул и другие, не менее важные причины, почему современные ОС обычно не подходят для старых компьютеров. Как насчет них? Ссылаться только на официальные спецификации - не стоит, иначе остаётся впечатление, что спор идет только ради самого спора. Я не раз уже убеждался на личном опыте, что от задекларированных характеристик до реальности иногда дистанция огромного размера.

Задам тогда прямой и недвусмысленный вопрос: на каком именно старом компьютере кто-нибудь лично использовал последние версии каких-то ОС и какие остались впечатления? Какие именно ОС? Сколько было нужно памяти? Какие старые процессора работали, а какие - нет? Были ли проблемы с какими-то приложениями, которых не было на 64-битных компьютерах? Работали ли все устройства? Возможно ли было использовать готовые носители данных (CD, USB) для их установки без доработки напильником (речь о старых BIOS)?

P.S. Я вообще-то никогда не позволяю себе голословных домыслов. Все свои утверждения я проверял на реальных компьютерах. Могу назвать каждый и возникшие там конкретные проблемы. Результатом было то, что несмотря на моё сопротивление, спустя три года, я был вынужден перейти на 64-битную платформу с ОС, официально поддерживающей 32-бит до сих пор (не дебиан).

Пётр, я с тебя фетчу idec.talks и pipe.2033

1. сделай бекфетч с http://ii.51t.ru/ii/ :)
2. что думаешь о создании эхи pipe.2033 и отправке 2032 в архив
3. стоит ли гейтовать std.hugeping

у меня станция заточена под http и старые браузеры (проверено на win95 с ie4)

В кои-то веки -- оживление!

Мне тоже не нравится принудительный https, но тут каждый сам решает что на ноде крутить. Опять же, есть технические нюансы. Мне кажется, что заворот http на https это сейчас настройка по умолчанию много где. На моей ноде всё сделано руками, поэтому мне было не сложно оставить выбор.

P.S. gemini требует ssl и это для меня существенный минус. Выкидывает за борт всё ретро сразу. Хотя в остальном gemini мне очень нравится...

>> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".
> Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:
> https://www.debian.org/releases/buster/

интересно, это как надо так умудриться читать?

ps. Дебиан любой версии, вплоть до sid, поддерживает 32 бита

> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".

Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:

https://www.debian.org/releases/buster/

shaos> Ну новых планов не выпускают, а дебианы - выпускают. Какой смысл сидеть на старой версии если уже было выпущено много новых с обновлениями (в том числе секьюрными) и т.д.? Вот у меня есть старый повербук на G4 - там ничего новее MacOS X 10.4 не идёт ну я там и сижу в сафари который не обновлялся с 2007 года и тоже страдаю по недоступности многих сайтов https (хотя вот например некоторые летсэнкрипнутые сайты там открываются), но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

"Не корысти ради, а токмо..." ради верности фактам. Я дебианом никогда сам не пользовался, но вот федорой - много лет. И с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем". Да и до этого минимальные требования памяти уже заметно превышали возможности старых компьютеров. Ну и, например, многие перестали поддерживать старые процессора ниже Pentium 4. Я с этим только вчера сталкивался, пытаясь установить android-x86 на старый комп (не ради любопытства, кстати).

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

P.S. А Plan 9 имеет несколько активных форков, но обновления там только для функциональности. В таких экзотических системах людей слишком мало, а работы - слишком много (хм, прямо Атос в исполнении Смехова: "можете не сомневаться, что я убью Вас" :)). А обновления безопасности - это только для больших, популярных ОС (Кстати, не самообман ли это на самом деле? Если сторонние приложения там никогда разработчиками на этот предмет даже не изучались?).

Хотя я в любом случае ПРИНУДИТЕЛЬНЫЙ https считаю тупостью, лишающей пользователей выбора.

Я просто логики не вижу. Сделать сайт, лучше всего подходящий для старых систем и компьютеров, и запретить к нему доступ старым системам и компьютерам. И непонятно, к чему указывать, что у нас нет того, того и того, если основная целевая аудитория этого всё равно не увидит :)

iiii> а что мешает использовать javascript, cookie, картинки? какой тогда смысл выпячивать "тут нет того и этого"?

Разве кто-то что-то выпячивал? Просто констатация факта и не более того. Уж извините, но сделано так, как я посчитал нужным. В том числе и несчастный принудительный https. Где-то в стандартах указывается, что его нельзя использовать?

P. S. Ну хоть эха оживилась и то хорошо.

> но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

а что мешает использовать javascript, cookie, картинки? какой тогда смысл выпячивать "тут нет того и этого"?

Приветствую

> О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал.

Ну новых планов не выпускают, а дебианы - выпускают. Какой смысл сидеть на старой версии если уже было выпущено много новых с обновлениями (в том числе секьюрными) и т.д.? Вот у меня есть старый повербук на G4 - там ничего новее MacOS X 10.4 не идёт ну я там и сижу в сафари который не обновлялся с 2007 года и тоже страдаю по недоступности многих сайтов https (хотя вот например некоторые летсэнкрипнутые сайты там открываются), но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

> Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Ретро это хорошо, но старый дебиан - это не ретро, а скорее дырявое корыто ;)

Прикольный дизайн прямо как в wap 2000

iiii> я про то, какие эхи гейтовать: std.hugeping это локальный блог или глобальный?

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

Peter> Я решил завести блог на IDEC, так как у меня есть много разрозненных
Peter> блогов. Но надо концентрировать сови усилия. IDEC - имеет прекрасный
Peter> формат для такого. Буду периодически высказываться на разные
Peter> темы. Что-то вроде текствого радио. Ну, просто потому, что надо что-то
Peter> делать!

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

я про то, какие эхи гейтовать: std.hugeping это локальный блог или глобальный?

iiii> а где болтаем-то?

У Петра, в основном. Вот здесь RSS всех сообщений по датам, где видна вся (не)активность: https://club.hugeping.tk/echo/all/rss

От создания контента - к его провайдингу.

http://ii.51t.ru

для старых компьютеров - ок. осталось забить контентом. функциональность "эхи как книги" надо будет вернуть, но переосмыслить под "архив эх". никакого https, никакого javascript и css. проверена работа на win 95 с ie4, на debian woody с netscape navigator и на всём остальном.

сейчас фетчатся эхи idec.talks и pipe.2033 (пока не существующая) с hugeping.tk, поллинг 5 минут

описание станции (точнее, софта эхи): http://ii.51t.ru/ii/html/about.html

а где болтаем-то?

iiii> или std.hugeping тоже теперь болталка? :)

Судя по статистике с начала ноября, боюсь, что я тут самый болтливый. Это при том, что и сказать мне особо нечего :P

или std.hugeping тоже теперь болталка? :)

1. перепись узлов - кто что гейтует? чё ща модно гейтовать

2. давайте сделаем новую межсетевую болталку - pipe.2033? новый год всё таки, а тянуть 3500+ сообщений 9-летней давности про болтание не стоит - лучше в архив :)

> Конечно ожидать, что все будут этот антиквариат поддерживать - наивно. Но, учитывая специфику сети idec, вообще-то не так уж и глупо.

моя нода поддерживала python2.5, и работала на чистом http, нормально подключаясь. я пользовался веб-интерфейсом на windows 9.5 с ie4 и выше (ie3 не поддерживал utf-8).

оригинал php-ноды делался так, чтобы работать на php4.

я не вижу проблемы поддерживать старое, и при этом работать на самом новом.

у меня есть сонерик клавиатурник, весом в 100 грамм, который зайдёт на http-ноду, но не зайдёт на https. и софт там на свежий не обновишь.

> Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...

я с ними на рыбалку хожу

>> Вторая версия python уже года два как ушла в небытие. И, если я правильно помню, то последняя была 2.7, а никак не 2.4.

в debian sarge и etch - 2.4. и с idec-сайтами через http там нет никаких проблем

> Принудительная настройка https, как мне думается - правильное решение.

нет, принудительный https - это маразм. если человек хочет выбрать https - пусть выбирает https, а если http - значит, он хочет http

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

тогда к чему этот выпендрёж с "нет javascript, нет того, нет сего", если там принудительный https? со старых систем не зайти в принципе. а с новых - и что, что нет? я с новых могу зайти из links2 или dillo, и у меня тоже не будет ни javascript, ни остального. убрать для себя javascript я могу, выбрав нужный браузер. а убрать отсутствие https - нет, если автор его насильно приколотил. поэтому преимущество "плаин html" превращается в недостаток, ибо там, где оно наиболее уместно, а именно старые системы, до него не достучишься. а остальным оно особо и не надо, кому надо - тот и из links зайдёт.

shaos> Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)

shaos> Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...

О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал. Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Конечно ожидать, что все будут этот антиквариат поддерживать - наивно. Но, учитывая специфику сети idec, вообще-то не так уж и глупо.

P.S. Извините, что влез не в своё дело, но слишком часто приходится видеть это "а зачем вам всё это надо?". Имеет каждый человек право на свои причуды и интересы. И отнестись к ним с сочувствием или хотя бы с пониманием - ничего ведь не отнимется. У меня самого в углу древний комп стоит, на который ничего новее 2005 года не установишь, а выкинуть жалко.

Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)

https://www.debian.org/releases/etch/index.ru.html

> Debian GNU/Linux 4.0r9 был выпущен 22 Мая 2010. Debian 4.0 изначально был выпущен 08 Апреля 2007.
> ...
> Предоставление обновлений безопасности было прекращено в конце февраля 2010 года.

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

iiii> какая разница, всё остальное тоже работает по https, и нельзя приконнектиться. у меня вон, текстовый клиент гоняется на python 2.4 на debian etch :) к hugeping.tk я могу свободно подключаться, он http

Вторая версия python уже года два как ушла в небытие. И, если я правильно помню, то последняя была 2.7, а никак не 2.4.

Принудительная настройка https, как мне думается - правильное решение. И если что-то совсем древнее, как естесственный отход жизнедеятельности предка слонов, не умеет с оным работать.. Ну что сказать - нет так нет, извиняйте. Могу предложить пользовать тот же hugeping. Кстати web-интерфейс там не в пример лучше. Да и функциональность намного функциональнее.

> Хм. Да, это так. Но разве https - это плохо? Первый раз слышу, чтобы были какие-то проблемы.

Да, есть проблемы. Несовместимость. Поэтому из старых ос на этот сайт не зайти в принципе. Хоть он трижды без javascript и всего остального.

> В любом случае - это всего лишь web-морда станции. И как таковой полезной нагрузки не несёт.

какая разница, всё остальное тоже работает по https, и нельзя приконнектиться. у меня вон, текстовый клиент гоняется на python 2.4 на debian etch :) к hugeping.tk я могу свободно подключаться, он http

iiii> Этот сайт использует ПРИНУДИТЕЛЬНЫЙ https, поэтому я нифига не могу зайти на него со своего Debian Etch. хоть с картинками, хоть без, хоть с js, хоть бе.

Хм. Да, это так. Но разве https - это плохо? Первый раз слышу, чтобы были какие-то проблемы.

В любом случае - это всего лишь web-морда станции. И как таковой полезной нагрузки не несёт.

> Этот сайт НЕ использует cookie. Вообще не использует. Никак.
> Здесь нет рекламы, счетчиков посещений, аналитики и прочей подобной дряни.
> Совсем не используется JavaScript.
> И даже картинок здесь нет. Только текст.

Этот сайт использует ПРИНУДИТЕЛЬНЫЙ https, поэтому я нифига не могу зайти на него со своего Debian Etch. хоть с картинками, хоть без, хоть с js, хоть бе.

С уже наступившим Новым Годом всех !!!

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

2022 год выдался на редкость паршивым. Может быть даже самым паршивым на моей памяти. Тем не менее, хочется надеяться, что следующий год будет лучше.

Поздравляю всех с наступающим Новым Годом! Пусть сбудутся все желания. И самое главное - пусть все будут живы и здоровы.




P.S. Не мастер говорить речи, просто хотелось высказаться.

shaos> https://idec.spline-online.tk/ опять помер - говорит EMPTY...

У него это случается. Поднимаю как только могу :)

Пока нет времени дописать новую реализацию, но она всё равно будет. Теоретически она будет стабильнее и быстрее.

+++ Caesium/0.4 RC1

Ordos> Касательно станции, наверно, не буду здесь спамить. Для этих целей есть локальная конференция, буду отписываться там.

Эта эха как раз для такого общения. А IDEC для того, чтобы объединяться, а не дробиться. Так что лучше бы тут и писал :)

+++ Caesium/0.4 RC1

https://idec.spline-online.tk/ опять помер - говорит EMPTY...

По внешнему виду изменения будут, просто свободного времени не так много, как хотелось бы. Как дойдут руки - сделаю.

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

Касательно станции, наверно, не буду здесь спамить. Для этих целей есть локальная конференция, буду отписываться там.

Настроил :)

http://shaos.net:8085/ii-web.php?echo=bot.habr.rss

Проверил уменьшение окна браузера - прямоугольник с текстом масштабируется в соответствии с размером окошка и это очень хорошо! Значит будет работать в моём недобраузере на ретрокомпах без глюков (единственный глюк это убегание линейки минусов за пределы рамки, если окно браузера становится слишком узким) - можно заменить на тэг <hr>? Он должен работать в текстовых браузерах тоже :)

P.S. Feed показывает лишь 10 последних сообщений и листать никак - можно исправить? ;)

P.P.S. И содержимое эх не посмотреть - раньше вроде можно было не?

P.P.P.S. Надо настроить забирание bot.habr.rss себе :)

Изменения по tgistation.ru. Может кому интересно будет.

Поменялся дизайн web-морды в лютый минимализм без картинок, js и прочего. В результате сайт неплохо себя показывает даже в текстовых браузерах.

Прикручен сбор новостей с хабра. Не всех, в основном, низкоуровневое программирование, микроконтроллеры и т.п.

Открыта свободная автоматическая регистрация без почт и sms. Надеюсь спаммеры не заведутся :)

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

Поторопился отписаться. Уже работает.

Собственно сабж. Пару дней уже как.

> Я просрал домен, как всегда. Так что таверна живёт сейчас по адресу idec.spline-online.tk :)

Привет - всё понятно теперь :)
Поправил настройки у себя, чтобы забирало по правильному адресу

Я немного отовсюду пропал в последнее время - новая работа, много забот и очень мало времени. Надеюсь, скоро это всё устаканится. Пока же занимаюсь сабжем.

Итак, почти закончил godec (нехитрое название да) - библиотеки, реализующей протокол idec на go.

Следующим шагом будет создание нового фетчера на базе этой библиотеки, реализация хранилища (скорее всего на базе postgresql) сообщений, создание узла без веб-интерфейса и, собственно, завершающим шагом будет создание нового веб-интерфейса таверны.

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

После всей этой эпопеи планирую написать таки новый репозиторий instead-games.ru, но это уже для другой эхи и фиг знает когда будет :)

+++ Caesium/0.4 RC1

Ordos> Да. С таверной как-то всё грустно. Может ещё очнётся когда-нибудь. Пока отключил.

Хех. Похоже, я отпал от основной сети. Надо Петра спрашивать :)

+++ Caesium/0.4 RC1

shaos> Спешу сообщить, что мой заокеанский узел IDEC всё ещё существует!

И это ура! Я уж думал, что всё -- ты пропал с радаров, а мониторить состояние сети в данный момент времени не особо есть когда. Так что очень рад, что ты с нами.

+++ Caesium/0.4 RC1

shaos> на lessmore и ping каким-то чудом появляются мои сообщения отправленные с моего узла shaos :)
shaos> получается кто-то кроме spline-online.ml фетчит http://shaos.net:8085/ii-point.php?q=/
shaos> либо tavern сейчас живёт по другому адресу и продолжает меня фетчить и раздавать другим?...

this.

Я просрал домен, как всегда. Так что таверна живёт сейчас по адресу idec.spline-online.tk :)

+++ Caesium/0.4 RC1

Сегодня подключил забирание с tgistation.ru эх idec.talks и zx.spectrum

Да. С таверной как-то всё грустно. Может ещё очнётся когда-нибудь. Пока отключил.

Ordos> Тогда спешу сообщить, что через пару дней станция tgi переезжает на домен tgistation.ru

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

Спешу сообщить, что мой заокеанский узел IDEC всё ещё существует!

Сегодня я добавил второй путь забирания эх через lessmore т.к. существующий адрес tavern не работает как минимум с 14 июля 2022 года (если пойти туда через браузер, то оно редиректит на какие-то списки ссылок). Несмотря на то, что старый адрес tavern не работает, он как будто-то бы продолжает забирать у меня сообщения по старому списку (я сегодня добавил у себя эху idec.test и её в том списке нет). Во всяком случае всё, написанное мной в idec.talks ушло в сеть и появилось как минимум на узлах lessmore и ping.

Список эх, которые я забираю извне:

	["idec.talks", "Сеть IDEC, её работоспособность и софт"],
	["idec.test", "Тестовые сообщения"],
	["lor-opennet.17", "RSS с сайтов linux.org.ru, opennet.ru"],
	["develop.16", "Программирование"],
	["linux.14", "Эха для линуксоидов"],
	["plan.9", "ОС Plan 9"],
	["zx.spectrum", "Speccy и совместимые компьютеры"],

Список локальных эх:

	["z80.coding", "Программирование процессора Z80"],
	["580.vm80a", "Программирование процессора КР580ВМ80А (i8080)"],
	["nedopc.1801", "Обсуждение компьютера nedoPC-1801"],
	["pdp.11", "Обсуждение архитектуры PDP-11 и совместимых машин"],
	["robby.lang", "Программирование на языке Robby"],
	["balanced.ternary", "Обсуждение троичной уравновешенной системы счисления"],
	["english.talks", "Speak English"],
	["silicon.valley.local", "Локальная конференция Кремниевой Долины"],
	["sprinter.computer", "Общие обсуждения компьютера Sprinter"],
	["sprinter.software", "Обсуждение программного обеспечения компьютера Sprinter"],
	["sprinter.hardware", "Обсуждение аппаратного обеспечения компьютера Sprinter"],
	["sprinternet.io", "Обсуждение сети для компьютера Sprinter"],
	["circuits.cc", "Эха про сайт circuits.cc"],
	["nedopc.org", "Эха про сайт nedopc.org"],
	["shaos.net", "Эха про сайт shaos.net"]

Короткий линк веб-интерфейса моего узла: http://idec.shaos.net

Могу взять благоразумных пойнтов - пишите на me@shaos.net ;)

Shaos

на lessmore и ping каким-то чудом появляются мои сообщения отправленные с моего узла shaos :)

получается кто-то кроме spline-online.ml фетчит http://shaos.net:8085/ii-point.php?q=/

либо tavern сейчас живёт по другому адресу и продолжает меня фетчить и раздавать другим?...

У меня чото ни с сабжем, ни с idec.spline-online.ml связи нету :(
В живых вижу только 3 узла IDEC (ну кроме моего):
https://dynamic.lessmore.pw
https://club.hugeping.ru
https://tgistation.ru

Рад сообщить, что в таверне появился клуб эсперантистов. Заходите в eo.klubo -- поболтаем :)

+++ Caesium/0.4 RC1

Восстановлена связь с сабжем. По техническим причинам в таверну не ходили сообщения с 9 апреля.

Сисопы, имеющие станцию Мира в аплинках, проверьте связь. Пока что она шлёт мусор на запросах несуществующих эх. У себя я обнаружил запрос несуществующих ifiction.15 и python.15.

+++ Caesium/0.4 RC1

Текстовый клиент, который не так давно отметил своё восьмилетие (первый из существующих клиентов) обновился до версии 0.9

* поддержка загрузки некоторых эх с других станций
* нумерация файлов в каталоге 0001.txt вместо 1.txt

Размер архива вырос на 55 байт :( и теперь составляет 3911 байт. Поддерживается python от 2.4 до 2.7.
(разные версии тестировались на первом пентиуме с Debian Sarge, Etch, и OpenBSD 4.2, 5.0 и др.)
(это сообщение создаётся на третьем пентиуме, правда с новейшей OpenBSD 7.1)

@base64: ii-txt-0.9.tar.gz
H4sICPqmcmICA2lpLXR4dC0wLjkudGFyAO0ca2/cxtGf+SvWdgSS8R3voZPkslVat3HioHWT
Ok6bQBEc6m55YsQjWZInnRwE8COuYySN66ABCrRoi37pp6KyY9nyS/4LvH/UmVk+705SmliK
7HBhmeTu7OzOc2d2ybOsajgIq3XtR0f2rdTrrfrczAxcqYxe6b7Rak63ZpqNRnMO6huNVn3m
yMyRAyj9IDR8GNJ33XA3uLVlzu0jL1yxUvnX6m4/3G/5N+Zm6vnruPxnsb7RbMzVD1b+/YD7
u8Pt3v5iyL+mtd2+Ez5bUuuNen221dpF/o1R+5+ea8weqZfy3/dSP1KWH3LJ27+3vu/r/97+
X9h/s95olf7/wOVf6/B9CAH28v+N6dkx+c/MzpX+/wDKW+/Ne+vhsutIpuuzVWY5rKm14G8G
/mbhb441pY4rWSb7QAC+tMqqv2XNVxgoy2rN6dv2B1K4zB0pRfXSqmRa0MnhpX99zuzftJyO
w9e0Z7oU7GH/YOytUfuHBaOM/w6iHGfVl6us7XYsp6uzfmhWT2KNJFk9z/VDbOHtoMJc+Gub
XUnqcJNBokBpgqLqEoNisXkWhL5iQZXrcUeRNa2YTsiq5nOjo6jqiYZKfXaAq8hrALvmWyFX
AK+A9XnY9x2WQk8FGlxkNsUsifwWN9Bxwfw0204mZQchTGthwBBggO1uoNlWEHYsnwaeChAD
N1QGzk0GrZcRaLBIvbGT2Qu6WAWYBEosAAdoBVu0lIipIEancKOC/dSKjMQQQ1PitcCzrdC2
HB4oaopxGdq4D0gB9YKO1gdGyAeKLKuLKRBM0YaxBKzK5udZM5sTlqW+ieRyY5GdQExpI7fH
+07v3nehobfwdkH+mc+90NUFbdhSX0xgWno2uzw7MuVAWWYsiGUqv+/I2oeu5SgwqsoyNoB0
fN5zV/kODFWl0lvvu//vrYTaM08D9or/mnNj8d90s9Us/f8h8P/BOjj+JSPgsy1cBIS7NdEr
Qotm+N1VcBaLwp2EA/Ai5APMxONRfZsaBBJtabbFHfQXCsLn1gIT/IqshW4QFBYB6BwDoX9w
jB5XzIp5QgaXIKul/T5j+wfHDox9xi5gr/hvrlkf3/8r7f/QxX+h1eMiAOwYIe8qnYoZx1px
gIYAGgSCJt6AmYqKbo8eMTjsqLCME4YLnuFfVHBdFxi8i+AiUPXGQqSeCy0dqx3Gz3E0411U
2U/YSZ0dB8/SYT0edNNQIp7OryEDjf1LiOi9ixC+iAEUuSYn6LW+h/QoYpCLlqcg/IKuNxcr
dNfAWzWJVdABWhcqDvpA7vR73MfOiszby64BXg+8F6KDC5Bj+m4P7oxOxxcVoQvXoL/0oayq
WRCGAbR14UQjrei5C86imLK1GM9zgXwe1mYxFLSf1BfVFIJGRhDkdlZRCKN7LnjxCTFsbPvg
DuRC5EYuv0cBtAAVgJOjWj2TmRBxYRToFod1vUnxcSpg6H90nuSX8ShAUlAVSPcy2iryVKc2
1atNrbOpM/rUWTkLKUVc28OFBTgGl5iJJJVFUa1gPSYv2EZyWlSxRWWihUaFZ/b62fPq+w6J
UGc5ZCDRxeIIJN64rjCunEXMZry8yRCNTwUQk+9QGDELuqfqhYiRsBg9DAAS0tq2G3Dl/4+R
R/y/FywfePzXqM9Oj8d/063S/x8C/9/3bdtaqmAYCEtAugPguUFoKkFs7mAjBhiagNXgEkd4
H8khar3OgorsGf1wGW4xSYc/8MQfC0M9/tGxX7iQ+zthNVz3+DGdHTM88ChtI7Rcpzaorq2t
VcEF9aop4s6xj6lrvzAouZgEfYPszwMfCd6MJljwgf0kPhXOzd4poA2TiLZnF0JaSHLROxMX
ACp1XFCvoUKFwZoVLpPDY+6KnHP1WZoLKKU0QSeEYO3YYcnqHpWzHp4PRDD59Llzb57T2Sr3
1xECV7zA6HKm2FbPCnU221pRj8rjGJHvjPu+6++M9NQ758+kfQO+E9jvzrz3U7lMw1/g+N/n
sGgH/ED3f5vg9sf2fxv16dL/H8L4P7cL3OXhhSQqUTAxj71c6K/ro6G4CP8QOo7/CH7HbVE+
aHMvHMMiy99/+vGc5BKw+u2VTeyaK+ydbuSyiZE9eJ9WYcO2uZEcEJjMcUNc+zwjXNb4wArC
oLgJX1ghe8YK71j+CIiY2DrMqKB6uIMP4y/EG/cTd+cpqyEsxdQmJ4ReUQi99d3ys4KOf+eM
Z5LKF3UPRTNfr8RaMC/LFVQDvJIexDd4QX2Aq/qC5k0TD14S6eJZAZ1DqdpF07JtpaVOPITA
k4dvl4lZE5IvgeTbJmCHa/1fM599+rfX+j9dn54Zy//qM+X7H4cn/2tmZwC0/J87/ZtfvXEW
fARINg0GTMVOVlORNZg8bC8z4f1sYSbgQNjbITR333iTxUMkz2KlEHVdWDrjVeb3fU4nufFM
tHOiRrHVPIAGLuiCOOFU5FNt9KVVShYBNSSAMiKUkx6B5zoBz+FMsscYWZrOJaCa5ZguBCpA
pSIn2erpBD0dqYoRMv+NHhSrtNfhv9csGwIS+M8F55zQq2To48VAnZCBIZ4ELr/ummkGu1cs
9t1isKQ3LK80UsA9xQYvy735Zj0eJT1h9w2ny5V6BTdobZWgcqvousXtDrMXBvrgBDbFGPuO
l+4kxINlZ0Xg7emsCLNmzzba4Ker4M9P0AoaV1yACgjBWMyLDl/qOx1gOK4GuRlSlBVM2K2k
pdbqVFbcDp7CJ1GdLlcauePp0eUcOuSOqZAI6K+OdsixG6YD2XjaAxDEy99on2SDtTIZmh0X
5BCQIHnNsFcucBvP3mOaOG7IyPKPQZvg5qOPi1ygbYqJfMBXITR6EcIpxiKE0ClW2fTKwHwS
eqVbD9zQJwBqhgfkdRSnED9yO95RwrxTAUOsGF6FJ55E7LOQc5GnAp68EyDAUnsBkDwHUlpF
SMrtnJjXCToAOx6NITMpdGx8TWTk5RFBw0JVuD59ETk1oKgWGhFtbm8X+nTElhIYi8BWadXV
IlOCHGG9PGEMlFmE2x1bzU2LplbQbUkSXMs2vXKdk7dh1Ep6JwL1fmUkUl+1kvA7FkLFqCwY
i+ULFz/A9z+C7rMf49u8/z1bb5bvfx+8/NEhHgr5z02X8v8e5B+HHvuW/33T7z+nW/gd4EHK
v/z+E+WP4cB+nv8mci/Y/0yrOSb/xlzzcMn/BbV/EHhyxInbaW3XMS0KJnd4aZlidV8xC/H5
wmIxvcBYtJkcolLBFwDNJPJPEo1BMSDGpCROEQaFFAEaxLi0pQyNhVxxkOZruqziuS+mMHBP
L3NTMs0Gonuub7whncKlaW4MCiFxHnYCXH5U0Sd79TyG8TGtkJ4b+z93+tSrZ09rfj842P2/
1iT7r2O8UK7/+16i/wyvRBts+OnwyvBq9BBuo6fDS9F2tDn8Q7Q1vASVm8MrzLJqVoe3q8PL
+Dj8nEVPsNcn0Ub0IHoE4HeGV4dfMGjeGl4GjJvR4+HVCovuwL9oK7obbTKqfUitCP7Z8Fqh
P4u2GFxvQ8P16Ak143RwdgTwNQJpkhT9EypuR9vUgFMD5BvRPRzgMhPfn9EXbIDxVb5kGQ47
jbuQgP1tw8fXJd45/1r1ZIV54EoCDqY7Pw9I/wzTBNLvA6qnQMllHJqIoGnCI/BkC5pgUB2z
di0glAE4K7gFQp/CXC4hWdEDfNiOHgGa6/EUEzqHnyFLkAHE4gesyogQ5PgGzODR8CbCazgf
uM8j2gSGb2HVE5DIPXxkxMhHw89hrtvI5s3odhXQ3AVkm8AL6LAND58Bz44ikwhhfrSHQEA1
QYjihG43hrcYiojmR9qwkU54C9mDWhFtVVA226KeBB89BnjEsp2f9FamKmJ+wElgBGoCzAq4
gmgfo5AJH0zlE8D+dbRBDN1OJoIKEW1Dh9zEqpMnJmUMELp6CQdGguGxSvKl5+Gn0OOL4Q3o
87ha69ek4R+H16KNkQuiAu6g6j0ooMMuuh5DSbUai24R1ltICc0cdHYTmA5CA80E/4dKtE36
fUPIEvXkDiMUmxqL/oozQYYJJQSdRmRA8U0Eo2OZWFX/TXIHOyHGwmhbyNWE02AkaLxM1INy
gGAqmZC3xTzu0wDU5U6uMXo8anObqe5WRM+7xIR7AHQjpeEyilaMiRqXSml4FTcpNSZFf8u0
YxPZyWiIh2TzSMR9ND+cj06fLknRP9LZg+oArdT+hbB2dDXXEr8C9OqS9HLstWLvUiRflxLr
BBw3R9SblBU7oP6hz5JStULgKiOVvR3dq0jUjbwfmSa6CSRjeBP6oA8CUwS1yjs6UHKdJoay
hRlIp2wbmfFV9F8WfRn9Bcz870Dsv1Bdh1ckQQiaFSrZFZ3tMnFI0qzOmFLBXGJzS81TsCNB
KjzSp8PPx+jMGFCgM0f+dayEXrdA0Ynub8aEUR7MTV+0f/7L/snZZsM4df7MzNsrZ1qSa3e8
tnSO6yzkAUR7SALSc50Mdvso8ganywSrYP4Fl0b8wj53Yx3YINquJxqPtKFGXCL7EJo/GOCx
MSow3IHWgYJfFSTEfivH7y2GJ9x6hcXH2Ki3d/IrmmAxLZlXRsbJmdcmaXbsHQrmm3j3TG3R
B24li7HwYTgP0u+v0aaH1wVD7kCHWyz16lu0JDwhq388anYF/y+oVJCjSHMyVjojhm8OqrFi
0BTv0qIVL3oS+iMW/QlU4ApoyAZQCRCMfNSXDL/TJPUcXqPhngxvov3GDg1dxsjSRwoM6z4t
5KNaDQ7yq3iWY350BNEWei7kIfJ3M3M0gkRRJQQNGltYtZDFm0JNY0cqBPjuu/i1Kb6YCTIX
DySa+8QTcri5yIHkj90SNj038X+W+x1s/F/Hd/1G4//per2M/w+gaNJyGHp6rbbc73LPcrpa
uILxUBB2tKQqAfGa2kwjhASxBukABkDgtTWvXR6ivBj7fyKt2Ycx0P532/9vNsb3/1vl778c
SDl+tLZkOTVczo+vzoMaSFK7w+qQbWhMw58Dkl5h8aGA9NJb78WZCN5lr4rTY/rlKPbXIPK1
TIrlWDVg2Zdl4pdibB4UKk2rPGr+/u0/DlgO3v4b4/t/zdlWuf93wPY/Yvdo1NnPAdGj+HUI
lvwMy8sYClOD+Gww14Cf8ceOoLSxspSlLGUpS1nKUpaylKUsZSlLWcpSlrKUpSxlKUtZylKW
spSlLGUpS1nKUpb9LP8D2f11hQB4AAA=

> Ну если начинать наворачивать вебинтерфейс, то да. Но чисто обмен и хранение пишется часа за 4 +-. По крайней мере на ЯВУ :)

Там мелочей всяких больше, чем на 4 часа, ну да ладно - не суть...

> Какие проблемы решает добавление бинарных данных в рассылки? :)

Ну сообщение становится самодостаточным (если приаттаченные файлы маленькие и влезают вместе с текстом сообщения в лимит)

> А есть такая необходимость? Ведь есть файлэхи :)

Не все узлы подписаны на все файлэхи и глобального поиска по идентификатору нет ;)

> А надо фильтровать?

Ну если будут сообщения разного типа, то да

>> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.
shaos> Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).

А есть такая необходимость? Ведь есть файлэхи :)

>> Реализация всё ещё пишется за несколько часов :)
shaos> Это далеко не так ;)

Ну если начинать наворачивать вебинтерфейс, то да. Но чисто обмен и хранение пишется часа за 4 +-. По крайней мере на ЯВУ :)

>> Да и не повод дальше усложнять.
shaos> Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)

Пока не понял как :)

>> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
shaos> Ну для начала - добавляет бинарных данных в рассылки.

Какие проблемы решает добавление бинарных данных в рассылки? :)

>> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.
shaos> Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)

А надо фильтровать?

>> А найти и прочитать сообщение в общем случае это O(1).
shaos> Скорее O(n)...

Сдаётся мне, что это зависит от реализации. Например, в цезии формат простой, заточенный на линейное чтение базы сообщений. Тут O(n), согласен. А если хотя бы по сообщению на файл, то уже всё таки O(1).

Тогда спешу сообщить, что через пару дней станция tgi переезжает на домен tgistation.ru.

Не суть какое событие, но для порядка отписать обязан.

Не прошло и двух месяцев, как я собрал актуальный нодлист.

Лежит в таверне на публичных фреках. Налетай!

P.S.: Доступен через веб-интерфейс http://idec.spline-online.ml/ без регистрации и SMS.

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

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

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

Всех обитателей IDEC сети поздравляю с Новым 2022-м Годом! Желаю IDEC в новом году разростись до немыслимых размеров и подмять под себя ну скажем всех Спринтеристов (и даже частично Синклеристов), а если получится, то и ещё кого-нибудь в придачу ;)

Вот кстати здравая мысль. И фича полезная и ничего не ломает. Я - за.

А кстати небыло мыслей сделать специальный вызов в 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

И после этого можно будет строить топологию сети автоматически :)

> ii подмножество idec. Если речь про ii, то всё-ещё так. :)

ii более несуществует - есть только idec ;)

и он чуть более сложный...

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

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

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

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

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

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

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

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

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

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

>> Реализация всё ещё пишется за несколько часов :)

shaos> Это далеко не так ;)

ii подмножество idec. Если речь про ii, то всё-ещё так. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.

Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).

> Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)

и это тоже можно сделать ;)

ну или по классике - в теле письма писать URL на ii-объект:

ii://1KpcmGrc9pUtZQ6Puv1z[*][*]

> Реализация всё ещё пишется за несколько часов :)

Это далеко не так ;)

> Да и не повод дальше усложнять.

Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)

> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)

Ну для начала - добавляет бинарных данных в рассылки.

> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.

Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)

> А найти и прочитать сообщение в общем случае это O(1).

Скорее O(n)...

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КБ. Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)

>> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
shaos> Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)

Реализация всё ещё пишется за несколько часов :) Да и не повод дальше усложнять. Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)

>> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
shaos> Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).

С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею. А найти и прочитать сообщение в общем случае это O(1). Другое дело, что в зависимости от конкретной платформы и конкретной реализации в абсолютных величинах это может быть долго. Я догадываюсь куда именно ты клонишь.

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

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

> Касательно рассуждений о хэше для сообщений, пришла мысль, что 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 может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
> Мне кажется такую функциональность проще реализовать в виде варианта запроса
> индекса, который будет возвращать (кроме идентификатора и закодированного
> сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение
> метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет
> то, как клиент будет отображать полученное содержимое.

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

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

Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)

> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?

Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).

Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC это практически контентно-адресуемая сеть и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений.

> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения

Мне кажется такую функциональность проще реализовать в виде варианта запроса индекса, который будет возвращать (кроме идентификатора и закодированного сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет то, как клиент будет отображать полученное содержимое.

shaos> Всем привет

shaos> Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):

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

Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?

Когда доползу до компа, постараюсь ответить более развёрнуто.

Всем привет

Я познакомился в 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/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:

msgid:{!"#$%&'()*+,-...}
msgid:{0123456789...}
msgid:{ABcded...}

где в фигурных скобках будет ascii85+ сообщений (этот алгоритм не является url-safe, поэтому в других местах API где надо url-safe останется всё тот же base64url).

3) Идея, что msgid является хэшом сообщения, с моей точки зрения является в ii ключевой, поэтому редактировать сообщения, сохранённые узлом (а тем более переданные на другие узлы) ни в коем случае нельзя! Ведь это поменяет контент и хэш уже не будет совпадать! Если же контент константен, то всегда можно восстановить msgid по самому сообщению, если вдруг msgid оказался утерян. Кроме того на стороне клиента (либо другого узла после фетча) можно проверить целостность сообщения, посчитав его хэш и сверив с msgid - если оно не совпадает, то либо это старое сообщение (отредактированное на узле, где это можно было делать, или посчитанное в стародавние времена, когда хэши в ii считались иначе), либо подменённое или испорченное новое сообщение - можно просто подсветить такое сообщение особым образом на клиенте и читатель сам будет решать, что ему с таким сообщением делать.

4) Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения - например сервер принимая от клиента текстовое сообщения классического вида добавит в его список тэгов новый тэг trick/0 и посчитает хэш сообщения - елси хэш не начинается скажем с символа '0', то алгоритм инкрементирует значение в этом тэге (trick/1) и считает хэш ешё раз - если опять не стартует с '0', то инкрементируем ещё раз и т.д. пока хэш не станет начинаться с нуля (в среднем на подготовку "красивого" msgid должно уходить порядка 32 вычислений хэша - иногда меньше, иногда больше) - в этом случае все узлы точно будут знать, что все "новые" сообщения с msgid вида 0... являются новыми "обычными" сообщениями (чтобы отличить от старых сообщений с именами случайно начинающимися с 0 можно проверить наличие тэга trick в заголовке сообщения - если он есть, то это новый тип сообщения с возможными вложенными файлами). Если каждая точка системы точно знает, что это новое сообщение, то она также может проверить целостность сообщения пересчитав его хэш и сверив с msgid ( ведь новый стандарт должен будет явно запретить редактирование или подмену сообщения уже сохранённого узлом ; ). Старые узлы и клиенты будут передавать такие сообщения как самые обычные (если не запнутся на неизвестном тэге trick).

5) Тип сообщения 1... может обозначать закодированный бинарный файл, когда в теле сообщения нет текста, а сразу идёт блок ascii85+ {...}. При посылке такого сообщения отправляющий клиент может задать новое ключевое слово @crc32:0xFFFFFFFF для указания контрольной суммы, которая при сохранении сообщения будет вставлена узлом в строку тэгов в виде .../crc32/0xFFFFFFFF и которую принимающий клиент может проверить после восстановления файла. Размер такого сообщения по понятным причинам будет ограничен - может быть даже придётся уменьшить текущий лимит 87кб до 32кб, чтобы эта реализация была совместима с ограниченными размерами памяти недокомпьютеров, которые могли бы участвовать в работе сети - в этом случае размер самого большого бинарного файла, который можно таким способом отправить, будет составлять порядка 26кб. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые.

6) Тип сообщения 2... может обозначать составной объект, когда ранее отправленные сообщения типа 1... на самом деле являются кирпичиками, из которых строится большое сообщение. В теле такого сообщения могут перечисляться как блоки {}, так и ссылки на внешние сообщения типа 1:

~1gjkwui4iuwqrezD56az
~1ui4iuwqrezD56azFejs
~{......}|это вставка блоба ascii85+ (комментарий после | до конца строки)
~1uwqrzFejsDSGFeekjkd|это ссылка на другой объект, который должен быть вставлен при сборке
{....}=666.bin|это объявление именованного блоба (без вставки)
~666.bin
~666.bin
~666.bin|это вставка копии именованного блоба (всего 3 копии подряд)

в примере выше показано как можно повторять несколько раз бинарный кусок, объявленный в том же сообщении (666.bin). Такой тип бинарного сообщения снимает любые ограничения на размер передаваемого объекта, который перед передачей может быть порублен на кусочки. При отправке такого сообщения также может быть использовано ключевое слово @crc32, которое как и в предыдущем случае будет вставлено узлом в строку тэгов при сохранении. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые (как в примере выше). В случае реализации сообщений 1 и 2 типов на уровне сети для передачи бинарных данных отпадёт необходимость в поддержке файлэх, которые выглядят несколько неестественно применительно к ii (например они не приспособлены для пересылки через последовательные каналы передачи данных, в то время как все остальные подсистемы IDEC представлены в текстовом виде и могут быть использованы через интерфейс терминала).

7) В будущем при отправке сообщения от поинта узлу к ключевым словам можно будет добавить ещё и подпись @sign:0xFF...FF по алгоритму скажем HMAC-RIPEMD-160-96 (с одним секретным ключом известным отправляющей и принимающей стороне), если достаточно удостовериться в валидности посланного от поинта на свой узел (узел должен знать секретный ключ поинта - точно также как сейчас он знает пароль) и далее при сохранении сообщения на узле (после проверки валидности) такую подпись можно опустить, либо (в будущем) по алгоритму Ed25519 (с публичным и секретным ключами), если требуется проверка достоверности сообщения в пределах всей сети на любом узле и любом клиенте (это более тяжёлая реализация, которая требует наличия двух алгоритмов SHA512 и Curve25519, а также способов передачи публичных ключей всех активных участников сети на все вовлечённые узлы) - в этом случае sign/0x... переедет в строку тэгов для проверки достоверности послания в любой точке сети (и также для проверки целостности данных вместо CRC32), а старые узлы и клиенты просто будут игнорировать этот тэг, как неизвестный.

8) Когда сеть разрастётся, возможно придётся отказаться от хранения всех сообщений на каждом узле (в идеале - когда все фетчат всех) - узлы могут быть разбиты на группы (с избыточностью) для хранения разных наборов объектов (скажем в зависимости от значений 2го и 3го символа в msgid). Существуют разнообразные алгоритмы распределённых хэшей, которые можно применить в данном случае для поиска объектов по хэшу (msgid) на сети ненадёжных узлов. В этом случае сеть можно будет использовать как распределённое хранилище подписанных объектов, которые можно будет задействовать при построении распределённых сайтов, мультиплеерных игр, криптовалют и т.д. Для старых узлов можно предусмотреть механизм, когда они подписываются на специальные скрытые эхи, в которые будут транслироваться копии объектов по группам - в этом случае эти узлы будут продолжать работать в старой парадигме IDEC, но в то же время они будут полезными в рамках новой распределённой сети объектов, раздавая сохранённые на них объекты при необходимости по запросу.

Shaos

пишу тестовое сообщение

> Добавил в блеклист.

Да - теперь в логах чисто - СПС!

shaos> Наверное если они невалидные их надо в чёрный список, не?

Добавил в блеклист.

Существует 2 пустых сообщения в idec.talks, которые вызывают ошибку при фетче из ii-php:

fetch http://idec.spline-online.ml/u/e/idec.talks/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum
idec.talks
fetch http://idec.spline-online.ml/u/m/HaYwRbvCz0HDMhN2IrOU/ymc21433dohplAzblytS
invalid message: HaYwRbvCz0HDMhN2IrOU
error saving HaYwRbvCz0HDMhN2IrOU
invalid message: ymc21433dohplAzblytS
error saving ymc21433dohplAzblytS

Наверное если они невалидные их надо в чёрный список, не?

Ну и от меня держите :)

{
    "nodename": "shaos",
    "client": " http://shaos.net:8085/ii-point.php?q=/",
    "web": " https://shaos.net:8085/ii-web.php",
    "sysop": "shaos",
    "contacts": {
        "email": "me@shaos.net",
        "phone": "+1xxxxxxxxxx",
        "web": " http://shaos.net"
    },
    "description": "shaos.net IDEC node",
    "uplinks": [
        [
            "tavern",
            "15m"
        ],
    ]
}

Запустил таки ii-php у себя на доменном имени на специально выделенной машине PowerMac G4 400МГц с Debian-линухом на борту, стоящей у меня дома в Пало-Альто, штат Калифорния :)

Пожалуй это будет первый узел ii/idec-сети, расположенной на американском континенте (и возможно первый узел на неинтеловской архитектуре?)

Беру с таверны несколько эх, а также создал заглушки для своих эх ( в частности silicon.valley.local ; )

В будущем планирую на той же машине поднять Gopher-сервер и TNFS-сервер (для компьютеров ZX-Spectrum оснащённых сетевой карточкой Spectranet)

Shaos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ake> Сделал открытую регистрацию поинтов на станции, но с небольшим квестом - форма регистрации находится в gemini - gemini://ake.crabdance.com:1966/enroll/intro/

Прикольная идея. :)

Сделал открытую регистрацию поинтов на станции, но с небольшим квестом - форма регистрации находится в gemini - gemini://ake.crabdance.com:1966/enroll/intro/
С одной стороны, думаю, это снизит риски автоматических регистраций и прочих злоупотреблений (а вдруг?), с другой, это будет не особенно большим препятствием, и процедура остаётся автоматической.

{
    "nodename": "ake",
    "client": "http://gears.headake.win/idec/",
    "web": "http://gears.headake.win/idec/ui2/",
    "sysop": "ake",
    "contacts": {
        "email": "kdeisacake@mail.ru"
    },
    "description": "Ake station",
    "uplinks": [
        [ "ping", "10m" ],
        [ "tavern", "10m" ],
        [ "tgi", "10m" ]
    ]
}

{
    "nodename": "mira",
    "client": "https://ii-net.tk/ii/ii-point.php?q=/",
    "web": "https://ii-net.tk/ii/ii-web.php",
    "sysop": "vit01",
    "contacts": {
        "email": "me@ii-net.tk",
        "phone": "+7xxxxxxxxxx",
        "web": "https://github.com/vit1-irk/"
    },
    "description": "Станция мира",
    "uplinks": [
        [
            "instead-club",
            "10m"
        ],
        [
            "tavern",
            "10m"
        ],
        [
            "dynamic",
            "10m"
        ],
        [
            "md0",
            "10m"
        ]
    ]
},
{
    "nodename": "alicorn-archive",
    "client": "https://alicorn.tk/ii-old/ii-point.php?q=/",
    "web": "https://alicorn.tk/ii-old/",
    "sysop": "vit01",
    "contacts": {
        "email": "me@ii-net.tk",
        "phone": "+7xxxxxxxxxx",
        "web": "https://github.com/vit1-irk/"
    },
    "description": "Архив сетей ii и idec",
    "uplinks": []
}

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

{
    "nodename": "tgi",
	"client": "https://idec.textgamesinfo.ru/",
	"web": "https://idec.textgamesinfo.ru/",
	"sysop": "Ordos",
	"contacts": {
		"email": "ordosp@gmail.com",
		"phone": "+7xxxxxxxxxx",
	},
	"description": "Станция tgi",
	"uplinks": [
		[
			"tavern",
			"20m"
		],
		[
			"mira station",
			"20m"
		],
	]
}

{
    "nodename": "ping",
	"client": "https://club.hugeping.ru/",
	"web": "https://club.hugeping.ru",
	"sysop": "hugeping",
	"contacts": {
		"email": "gl00my@mail.ru",
		"phone": "+7xxxxxxxxxx",
		"web": "https://hugeping.ru"
	},
	"description": "Станция ping",
	"uplinks": [
		[
			"tavern",
			"5m"
		],
	]
}

Кроме этого, у меня стоит забор:
echo "difrex.blog" | ./ii-tool -lim=-16 fetch https://dynamic.lessmore.pw/idec
Не знаю, как это отобразить.

Начинает чувствоваться потребность в сабже.

Просьба скинуть или сюда или на spline1986@yandex.ru информацию о своих узлах сети в следующем формате:

{
    "nodename": "tavern",
	"client": "http://idec.spline-online.ml/",
	"web": "http://idec.spline-online.ml/",
	"sysop": "Andrew Lobanov",
	"contacts": {
		"email": "spline1986@yandex.ru",
		"phone": "+7xxxxxxxxxx",
		"web": "https://github.com/spline1986/"
	},
	"description": "Уголок уютного общения",
	"uplinks": [
		[
			"instead-club",
			"5m"
		],
		[
			"mira station",
			"5m"
		],
		[
			"tgi",
			"5m"
		]
	]
}

Большая просьба написать именно в таком формате, а не "у меня ничего не изменилось".

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

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

Что-то у меня сабж сломался. Кто-то может дать доступ пользователю spline1986? Либо актуализируйте информацию по instead club. Там до сих пор старый адрес.

Сабж! Эха zx.spectrum посвящённая одноимённому компьютеру, совместимым с ним машинам, программному обеспечению и эмуляторам, создана в таверне. Просьба прокинуть к себе, так как есть шанс завлечь часть синклеристского сообщества :)

> Больше спектрумов, хороших и разных!

Безусловно :)

> Лучше нам завести под это дело отдельную эху, наверное. Я предлагаю общую
> спектрумовскую пока завести, чтобы подходила под любые спектрум-совместимые
> обсуждения :)

Я планирую поднять свой узел IDEC и там создать несколько специализированных эх по темам касающимся Спринтера, а тут действиетльно можно пока общую эху zx.spectrum завести ;)

> Кстати, в IDEC любой поинт может создать эху на уровне своего аплинка.
> Достаточно просто написать в несуществующую конференцию и она создастся
> (по крайней мере в таверне так). А там уже можно кинуть анонс сюда, мы
> прокинем по всей сети её :)

Попробовал послать сообщение в эху zx.spectrum - получил Error: 500 Internal Server Error ;)

shaos> Я свой Спринтер (в виде материнской платы Sp2000) получил по почте в начале 2002 года, когда ещё жил в Екатеринбурге - и эта плата до сих пор со мной и даже работает :)

Увы, я свой пентагон протерял давным давно. Конечно, эта машинка по современным меркам ни о чём, но очень уж я любил этот текстолитовый ящик :)

shaos> Существует 2 эмулятора компьютера Спринтер - эмулятор поновее, написанный на сишарпе zxmak2 (плугин Спринтера для него появился в 2012 году), который работает только на современной винде, но эмулирует Спринтер более точно используя образы ПЗУ и образы гибких и жёстких дисков, и эмулятор постарее (но активно обновляемый) - мой Zpring написанный на C/C++ (ранее известный как SPRINT, который я начал писать в феврале 2002 года ещё до того, как получил на руки реальный Спринтер):
shaos> https://gitlab.com/nedopc/zpring

Спасибо за развёрнутый ответ. Обязательно ознакомлюсь.

shaos> P.S. Можно сказать, что Эволюшин родился на развалинах экосистемы Спринтера, заброшенного создавшей его компанией в 2004 году - родился, чтобы заполнить временно возникший вакуум 2005-2008 годов, когда народ требовал современный спектрум-клон, а таковых уже не предлагалось - с тех пор Эволюшин таки стал королём спектрум-сцены (и в данный момент его теснит Next со своими клонами). В данный момент Спринтер снова возрождается и показывает, что во многом он всё ещё лучше и даже "современнее" Эволюшина, а в чём то даже лучше некста :)

Больше спектрумов, хороших и разных!

Лучше нам завести под это дело отдельную эху, наверное. Я предлагаю общую спектрумовскую пока завести, чтобы подходила под любые спектрум-совместимые обсуждения :)

Кстати, в IDEC любой поинт может создать эху на уровне своего аплинка. Достаточно просто написать в несуществующую конференцию и она создастся (по крайней мере в таверне так). А там уже можно кинуть анонс сюда, мы прокинем по всей сети её :)

> Всегда интересно узнавать историю таких проектов. Я в железе имел максимум самопальный пентагон,
> а в начале нулевых (как раз 2000-2002 года) пересаживался с него на 486. Ну и информационный голод
> в глубинке тогда ещё был. Найти информацию тогда практически не представлялось для меня возможным.

Я свой Спринтер (в виде материнской платы Sp2000) получил по почте в начале 2002 года, когда ещё жил в Екатеринбурге - и эта плата до сих пор со мной и даже работает :)

> Кстати, хотел спросить, но не помню в итоге спросил ли: есть эмулятор для linux-систем?
> Было бы интересно хотя бы так познакомиться с этой машинкой.

Существует 2 эмулятора компьютера Спринтер - эмулятор поновее, написанный на сишарпе zxmak2 (плугин Спринтера для него появился в 2012 году), который работает только на современной винде, но эмулирует Спринтер более точно используя образы ПЗУ и образы гибких и жёстких дисков, и эмулятор постарее (но активно обновляемый) - мой Zpring написанный на C/C++ (ранее известный как SPRINT, который я начал писать в феврале 2002 года ещё до того, как получил на руки реальный Спринтер):

https://gitlab.com/nedopc/zpring

Эмуль построен вокруг GPL-ного ядра эмулирующего процессор Z80, взятого мной из опенсорсного проекта FUSE, собирается под Linux, MacOS, Windows (причём сборка работает во всех версиях начиная с Win95 и кончая десяткой) и даже DOS ;)

Исторически мой эмуль не работает с образами ПЗУ Спринтера, а эмулирует все вызовы API биоса и дисковой подсистемы на уровне точек входа - поэтому он работает непосредственно с файлами хост-машины (есть кое-какая защита, чтобы программы запущенные в эмуляторе не могли произвольно лазить по файлам) и у меня достаточно легко получилось добавить сетевой API, который я придумал только в этом году.

P.S. Можно сказать, что Эволюшин родился на развалинах экосистемы Спринтера, заброшенного создавшей его компанией в 2004 году - родился, чтобы заполнить временно возникший вакуум 2005-2008 годов, когда народ требовал современный спектрум-клон, а таковых уже не предлагалось - с тех пор Эволюшин таки стал королём спектрум-сцены (и в данный момент его теснит Next со своими клонами). В данный момент Спринтер снова возрождается и показывает, что во многом он всё ещё лучше и даже "современнее" Эволюшина, а в чём то даже лучше некста :)

shaos> Приветсвую! Спасибо за поинта ;)

Всегда рады новым людям!

>> В 90-х был разработан довольно интересный спектрум-совместимый компьютер сабж. Сообщество его живо до сих пор и даже что-то разрабатывают в аппаратной части.

shaos> На самом деле текущая версия материнской платы была разработана в 2000, а пик официальных продаж пришёлся на 2002 - сейчас всё опенсорснуто (открывалось постепенно в 2007-2009 годах автором компа Иваном Макарченко, который к сожалению покинул наш мир в 2012 году) и сейчас народ делает свои модификации плат и свои расширения железа (я например делаю сетевую карточку SprinterNet на базе модуля WizNet W5100).

Всегда интересно узнавать историю таких проектов. Я в железе имел максимум самопальный пентагон, а в начале нулевых (как раз 2000-2002 года) пересаживался с него на 486. Ну и информационный голод в глубинке тогда ещё был. Найти информацию тогда практически не представлялось для меня возможным.

>> А вот что эхотажно, так это то, что вчера мне в личку написал разработчик SprinterNet (сервис такого специального прокси между спринтером и интернетом, грубо говоря) имеет рабочий стек http (не факт, что в полном объёме, но это и не столь важно) и желание создать idec-клиент (а может и сервер в перспективе) для спринтера.

shaos> Я думаю, что сетевая карточка SprinterNet может таки обойтись без сервера-шлюза для непосредственной работы с IDEC серверами - в данный момент я сымитировал весь требуемый API сокетов в эмуляторе и пишу экспериментальные сетевые программы там (например уже работают http-клиент и gopher-клиент), но железная карточка для реала по сути тоже уже готова - надо только наполнение для ПЗУ написать в кодах процессора Z80 и после этого все написанные сетевые программки начнут работать и на реальном железе ;)

Здорово.

Кстати, хотел спросить, но не помню в итоге спросил ли: есть эмулятор для linux-систем? Было бы интересно хотя бы так познакомиться с этой машинкой.

PS: С эволюшеном я познакомился пока только в эмуляторе и мне в целом понравилось. Но спринтер, насколько я понял, более интересная машинка.

Приветсвую! Спасибо за поинта ;)

> В 90-х был разработан довольно интересный спектрум-совместимый компьютер сабж. Сообщество
> его живо до сих пор и даже что-то разрабатывают в аппаратной части. Это, конечно, интересно,
> но не эхотажно.

На самом деле текущая версия материнской платы была разработана в 2000, а пик официальных продаж пришёлся на 2002 - сейчас всё опенсорснуто (открывалось постепенно в 2007-2009 годах автором компа Иваном Макарченко, который к сожалению покинул наш мир в 2012 году) и сейчас народ делает свои модификации плат и свои расширения железа (я например делаю сетевую карточку SprinterNet на базе модуля WizNet W5100).

> А вот что эхотажно, так это то, что вчера мне в личку написал разработчик SprinterNet
> (сервис такого специального прокси между спринтером и интернетом, грубо говоря) имеет
> рабочий стек http (не факт, что в полном объёме, но это и не столь важно) и желание
> создать idec-клиент (а может и сервер в перспективе) для спринтера.

Я думаю, что сетевая карточка SprinterNet может таки обойтись без сервера-шлюза для непосредственной работы с IDEC серверами - в данный момент я сымитировал весь требуемый API сокетов в эмуляторе и пишу экспериментальные сетевые программы там (например уже работают http-клиент и gopher-клиент), но железная карточка для реала по сути тоже уже готова - надо только наполнение для ПЗУ написать в кодах процессора Z80 и после этого все написанные сетевые программки начнут работать и на реальном железе ;)

> Это примерно то, о чём писал Рома ещё 7 лет назад %) Технология для небольших сообществ.

Да - это всё очень круто конечно - спасибо, что существуете и развиваете эту интересную технологию эдакого "микрофидо" :)

Alexander Shabarshin aka Shaos

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

А вот что эхотажно, так это то, что вчера мне в личку написал разработчик SprinterNet (сервис такого специального прокси между спринтером и интернетом, грубо говоря) имеет рабочий стек http (не факт, что в полном объёме, но это и не столь важно) и желание создать idec-клиент (а может и сервер в перспективе) для спринтера.

Это примерно то, о чём писал Рома ещё 7 лет назад %) Технология для небольших сообществ.

AL> А насколько этот сервер будет сложнее gemini?

Я не зря упомянул "HTTP-сервера, аналогичного по функциям gemini-серверу", т.е. для паритета по функциям протокола достаточно будет обработки начальной строки запроса/ответа и аж целых двух заголовков - Host и Content-Type. Завернуть в TLS по вкусу и гонять внутри хоть text/x-gemini, хоть gophermap'ы.

AL> А это новая сеть?

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

AL> Или просто ещё один протокол в той же сети, коих и так каждый день плодится море?

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

AL>> Веб с его протоколами и серверами уже слабо пренадлежит сообществу.
ake> А когда он принадлежал сообществу? Напоминает чепуху про "интернет создан DoD, значит им управляется" - интернет (и веб в том числе) это не нечто консистентное, даже сейчас. ИМХО сейчас возможность держать собственный сервер более доступна. Разработка HTTP-сервера, аналогичного по функциям gemini-серверу не потребует большего числа ресурсов, при этом он будет совместим с прорвой клиентов, от современных до IE/NN. Вполне есть всякие сообщества внутри, которые культивируют независимый web, вроде indieweb, или авторский, вроде neocities.

А насколько этот сервер будет сложнее gemini?

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

А это новая сеть? Или просто ещё один протокол в той же сети, коих и так каждый день плодится море?

AL>> Причём в gemini есть гейты и их можно читать и из того же хромиума. Причём gemini очень простой и потому пренадлежит сообществу. Тебе не нужна большая команда классных специалистов, несколько лет и несколько миллионов вечнозелёных (думаю, всё дороже), чтобы построить полностью свою реализацию.
ake> Потому что эти время и деньги уже были потрачены на проектирование спецификаций и разработку библиотек для URL/URI и TLS, на опыт HTTP и Gopher. Можно почитать, кстати, в рассылке, как оригинальная идея использования TOFU (trust on first use), в качестве политики сертификатов, наткнулась на реальность и про другие подводные камни "простоты".

Так надо искать и находить, а не идти на поводу.

ake> Ну и silo-узлы всегда будут, ибо так банально оптимальней с точки зрения масштабирования и ресурсов, и снижает технический ценз (предвижу недовольный технарский снобизм) для неофитов. Даже в том же gemini они присутствуют в виде различных pubnix'ов.
ake> Ну и чтобы не казалось, я не могу сказать, что отрицательно отношусь к gemini, просто хочу критически посмотреть на всё это.

Да нормально общаемся :)

ake> Ну и чтобы не казалось, я не могу сказать, что отрицательно отношусь к gemini, просто хочу критически посмотреть на всё это.

Хотел было привести свои аргументы, но передумал. :) Меня всё устраивает. Это как с велосипедными дорожками. Меня устраивает текущая ситуация, когда их нет или они построены не там и неправильно.

Так что gemini меня полностью устраивает и технически и просто как место, которое привлекает специфический контингент. Главное, чтобы не стали "расширять" дальше, как это часто бывает. Но вроде бы пока к этому нет тенденции.

Критиковать можно, но я не вижу никакого позитивного выхлопа от этой критики. :)

AL> Веб с его протоколами и серверами уже слабо пренадлежит сообществу.

А когда он принадлежал сообществу? Напоминает чепуху про "интернет создан DoD, значит им управляется" - интернет (и веб в том числе) это не нечто консистентное, даже сейчас. ИМХО сейчас возможность держать собственный сервер более доступна. Разработка HTTP-сервера, аналогичного по функциям gemini-серверу не потребует большего числа ресурсов, при этом он будет совместим с прорвой клиентов, от современных до IE/NN. Вполне есть всякие сообщества внутри, которые культивируют независимый web, вроде indieweb, или авторский, вроде neocities.

AL> Причём то, что ты в вебе, по сути ничего не изменит.

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

AL> Причём в gemini есть гейты и их можно читать и из того же хромиума. Причём gemini очень простой и потому пренадлежит сообществу. Тебе не нужна большая команда классных специалистов, несколько лет и несколько миллионов вечнозелёных (думаю, всё дороже), чтобы построить полностью свою реализацию.

Потому что эти время и деньги уже были потрачены на проектирование спецификаций и разработку библиотек для URL/URI и TLS, на опыт HTTP и Gopher. Можно почитать, кстати, в рассылке, как оригинальная идея использования TOFU (trust on first use), в качестве политики сертификатов, наткнулась на реальность и про другие подводные камни "простоты".

Ну и silo-узлы всегда будут, ибо так банально оптимальней с точки зрения масштабирования и ресурсов, и снижает технический ценз (предвижу недовольный технарский снобизм) для неофитов. Даже в том же gemini они присутствуют в виде различных pubnix'ов.

Ну и чтобы не казалось, я не могу сказать, что отрицательно отношусь к gemini, просто хочу критически посмотреть на всё это.

ake> Аналогично, в WWW уже есть всё, что есть в gemini, а остальным можно не пользоваться, например, ограничив себя использованием lynx или NetSurf. Зачем gemini?

Веб с его протоколами и серверами уже слабо пренадлежит сообществу. Да, ты можешь написать свой обрезанный движок для браузера, но он или будет монстром или будет не лучше вообще отдельной сущности в силу своих ограничений. Причём то, что ты в вебе, по сути ничего не изменит. Те, кому интересно то, что на твоём сайте, не остановятся перед установкой gemini(любого другого)-клиента, а те, кто может использовать исключительно хромиум, не зайдут и так. Им нужен условный фейсбук/ютуб.

Причём в gemini есть гейты и их можно читать и из того же хромиума. Причём gemini очень простой и потому пренадлежит сообществу. Тебе не нужна большая команда классных специалистов, несколько лет и несколько миллионов вечнозелёных (думаю, всё дороже), чтобы построить полностью свою реализацию.

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

Около того. Секта (idec, точнее) туда же. Это просто весело делать и использовать. Хотя проще взять какой-нибудь telegram или даже бота для почтовой рассылки. Просто idec простой и реализуется за вечер в минимально достаточном для общения виде на практически любом стеке технологий.

ake> Аналогично, в WWW уже есть всё, что есть в gemini, а остальным можно не пользоваться, например, ограничив себя использованием lynx или NetSurf. Зачем gemini?

Мне лично gemeni нравится таким, каким он есть. Регулярно смотрю. Интересный для меня контент там есть. Часто просто вбиваю в поисковик какое-нибудь слово и читаю блоги. Успокаиваюсь. Я рад, что таких людей -- не я один. На фоне остальных "альтернатив" -- gemini оказался прямо в тему.

Я кстати и netsurf и eww и прочим таким тоже пользуюсь, но gemini -- это всё-таки другое.

Ordos> Эдак ты сразу половину всея Интернета описал. Не сегодняшнего, скорее того старого доброго n-дцать лет наз. Насчет гейтов спорный вопрос, а по остальному претензий нет - вся ценность-то как раз в авторской информации (персональные сайты/блоги), либо редкие файлы.

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

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

Это как раз мне в таких сетях и не нравится. Вроде и открыто, но всё-равно получается какой-то walled garden. Как бы выбрал сугубо техническую вещь, ан нет - держи ещё некоторую идеологию. И ещё такой парадокс получается - если есть некое сформировавшееся сообщество, то без разницы, какой сетью/протоколом/каналом связи его участники пользуются, но когда сообщество сформировалось вокруг сети, то смена этой сети разваливает сообщество.

Ordos> Проще говоря, можно напихать в тот же gemini всякого и запилить какие-нибудь соц. сети, например, но чем она тогда будет отличаться от остального инета?

Аналогично, в WWW уже есть всё, что есть в gemini, а остальным можно не пользоваться, например, ограничив себя использованием lynx или NetSurf. Зачем gemini?

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

ake> фактическим наполнением оказываются гейты к обычным сайтам, файловые архивы разной степени полезности и персональные сайты/блоги

Эдак ты сразу половину всея Интернета описал. Не сегодняшнего, скорее того старого доброго n-дцать лет наз. Насчет гейтов спорный вопрос, а по остальному претензий нет - вся ценность-то как раз в авторской информации (персональные сайты/блоги), либо редкие файлы.

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

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

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

P.S. Пардон. Что-то меня понесло.

> Потыкал я этот gemini, потыкал... Мысль-то хорошая, но интересных тамошних сайтов полторы штуки. Привлекает только простота и некий "возврат к изначальному" что ли.

Ну это, по-моему, обычная проблема разных "smallnet"ов - при декларации приверженности "полезному" контенту и "правильной" форме без всяких изъянов "большой" сети, фактическим наполнением оказываются гейты к обычным сайтам, файловые архивы разной степени полезности и персональные сайты/блоги (из которых получается что-то вроде аморфной социальной сети без формализованных связей). Как мне кажется, это сродни слабой распространенности искусственных языков, вроде эсперанто.

Ordos> Потыкал я этот gemini, потыкал... Мысль-то хорошая, но интересных тамошних сайтов полторы штуки. Привлекает только простота и некий "возврат к изначальному" что ли.

Тут как с сектой. Чтобы было что почитать, нужно начать писать :)

AL> Вроде как Lagrange под виндой нормально себя чувствует. Пробовал?
Вышел из по положения по-другому. На винду ничего не стал ставить - она для игр в основном и прочих окно-зависимых вещей. Под линух - собрал lagrange, да. Хороший клиент, все красиво и удобно. Правда бывает графические артефакты иногда пролетают, но не критично. Под andriod - Ariane.

Потыкал я этот gemini, потыкал... Мысль-то хорошая, но интересных тамошних сайтов полторы штуки. Привлекает только простота и некий "возврат к изначальному" что ли.

ake> Новые станции это хорошо, добавил у себя для фетча. Странновато, что фетчер отрапортовал о 7 новых сообщениях, видимо, что-то из глубины времён.
ake> Небольшой оффтопик: что случилось и куда пропал idec.spline-online.tk?

Я в очередной раз провафлил домен. idec.spline-online.ml.

Новые станции это хорошо, добавил у себя для фетча. Странновато, что фетчер отрапортовал о 7 новых сообщениях, видимо, что-то из глубины времён.

Небольшой оффтопик: что случилось и куда пропал idec.spline-online.tk?

EP> Вообще странно как я этот баг проглядел - ни один клиент не ругается на такое - просто молча игнорируют.

Рома Яковлев заложил идеи, что всё должно работать в самых неадекватных условиях. Мои фетчеры просто игнорируют корявые данные и продолжают работать. Надо будет в новой библиотеке сделать возможность или лог писать или ещё чего. Чтобы ловить такие моменты.

> Скорее всего, присутствуют пустые строки в выдаче.
Абсолютно верно. Действительно в выдаче были пустые строки. Битых сообщений нет, это неправильная обработка списка перед выводом (у меня все генерируется на лету). Поправил, больше не должно такого быть. В любом случае буду посмотреть.

Вообще странно как я этот баг проглядел - ни один клиент не ругается на такое - просто молча игнорируют.

AL> Хорошо, что я свой фетчер писал, ориентируясь на то, что аплинк может выдавать произвольный мусор :)

Мой тоже в итоге работает (пропуская эти строчки), но я старался делать его строгим, чтобы потенциальные проблемы ловить.

hugeping>> Попробовал сделать fetch с https://idec.textgamesinfo.ru/
hugeping>> Не получилось, часть сообщений как буд-то битые... Что именно, пока не разбирался.
hugeping> Скорее всего, присутствуют пустые строки в выдаче. Например:
hugeping> https://idec.textgamesinfo.ru/u/m//EzHkw1q46MIQgxvT6p5G/eQbQUoX5AMe2Lmz4zncF
hugeping> В выдаче встречаются пустые строки, на которые мой фетчер ругается.

Хорошо, что я свой фетчер писал, ориентируясь на то, что аплинк может выдавать произвольный мусор :)

hugeping> Попробовал сделать fetch с https://idec.textgamesinfo.ru/
hugeping> Не получилось, часть сообщений как буд-то битые... Что именно, пока не разбирался.

Скорее всего, присутствуют пустые строки в выдаче. Например:

https://idec.textgamesinfo.ru/u/m//EzHkw1q46MIQgxvT6p5G/eQbQUoX5AMe2Lmz4zncF

В выдаче встречаются пустые строки, на которые мой фетчер ругается.

Попробовал сделать fetch с https://idec.textgamesinfo.ru/
Не получилось, часть сообщений как буд-то битые... Что именно, пока не разбирался.

EP> P. S. Пользуясь случаем, выражаю благодарность Andrew Lobanov за разъяснения непонятных из документации вещей и помощи в тестировании.

Да не за что. Обращайся :)

EP> А можно поподробнее про кучу серверов и клиентов? На досуге ознакомился с этим делом. Пробовал найти хоть один нормальный клиент под, прости Господи, винду 10. Дак нет же. Всё в каком-то полусыром виде - то собирать с бубном надо, то ошибки сыпятся, то вообще не работает. Нет ли чего-то готового, чтоб просто запустил и работает?

Вроде как Lagrange под виндой нормально себя чувствует. Пробовал?

Продолжаю славную традицию "каждому пользователю сети по станции". На днях увидела свет станция tgi (https://idec.textgamesinfo.ru/). Станция была создана исключительно из научного интереса и в целях более глубокого изучения idec. Так что глобальных планов на данный момент нет. Для начала предполагается держать несколько новостных конференций, касательно работы самой станции и всего с этим связанного, а так же небольшой блог для складывания в него умных и не очень мыслей.

На данный момент проверена работа станции с несколькими клиентами. В том числе и отправка сообщений. Веб интерфейс отсутствует как класс - руки ещё не дошли. Более подробно о ходе работ отписываю в tgi.station.

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

P. S. Пользуясь случаем, выражаю благодарность Andrew Lobanov за разъяснения непонятных из документации вещей и помощи в тестировании.

А можно поподробнее про кучу серверов и клиентов? На досуге ознакомился с этим делом. Пробовал найти хоть один нормальный клиент под, прости Господи, винду 10. Дак нет же. Всё в каком-то полусыром виде - то собирать с бубном надо, то ошибки сыпятся, то вообще не работает. Нет ли чего-то готового, чтоб просто запустил и работает?

w201403> Айм хере

Привет! Шевелится сетка!

hugeping> Привет! Тут тихо. Но, надеюсь, IDEC ещё шевелится. :)

Шевелится, хотя в последнее время его населяют, в основном, роботы.

Айм хере

ake> Тогда ведь получается, что по существу IDEC, как протокол, и как сеть, практически ортогонален этим применениям.

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

ake> Я даже не столько о стандарте, хотя там тоже можно много чего придумать и сделать, а о сообществе. Всё-таки в сети с десятком пользователей можно хоть TCP over avian carriers брать, было бы что обсуждать.

В разное время здесь была разная активность. Сейчас всё выглядит полумёртвым, если честно. Но я в основном сконцентрирован на своём проекте/блоге, так что меня это не сильно беспокоит. Ну как и присутствие в gemini -- мне нравится и этого достаточно.

> Ну, я лично получил от idec то, что хотел и даже без оглядки на наличие других станций. Моя нода ii-go стала единым источником данных для gemini капсулы и моего блога в вебе.

Тогда ведь получается, что по существу IDEC, как протокол, и как сеть, практически ортогонален этим применениям. Да, в комплекте получаем неплохо продуманную распределённую архитектуру и клиентские приложения, но всю IDECовость (или ii-шность) можно легко заменить на что-то самописное или какой-нибудь ActivityPub (чтобы можно было чем-то готовым пользоваться).
Тут можно провести аналогию с XMPP, который присутствовал/присутствует во многих огороженных "walled garden" проектах, например, тот же WhatsApp раньше использовал его в качестве основы для своего протокола, если не ошибаюсь; какие-то рудименты ещё остались у Google/Facebook с открытых времён, вроде возможности достать адрес сервера и подключиться обычным клиентом. Или с локальным почтовым демоном - если почтовый сервер недоступен извне, ну нет никакого большого смысла в том, что уведомления от cron и прочих приходят в локальный почтовый ящик, а не только пишутся в какой-нибудь лог.

ake>> А есть ли какие-то мысли о его перспективах и, страшно сказать, развитии?
> Иногда возникают разговоры о развитии стандарта, например, добавить личные сообщения.

Я даже не столько о стандарте, хотя там тоже можно много чего придумать и сделать, а о сообществе. Всё-таки в сети с десятком пользователей можно хоть TCP over avian carriers брать, было бы что обсуждать.

>> Тут тихо. Но, надеюсь, IDEC ещё шевелится
ake> Не было бы это шевеление конвульсиями, будет жалко.

Ну, я лично получил от idec то, что хотел и даже без оглядки на наличие других станций. Моя нода ii-go стала единым источником данных для gemini капсулы и моего блога в вебе. А также для телеграмм каналов. И все это просто текст.

ake> А есть ли какие-то мысли о его перспективах и, страшно сказать, развитии?

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

ake> Но чем дальше думал, тем менее обоснованной казалась идея (несмотря на концептуальную близость сетей) - писать сообщения из gemini не выйдёт;

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

> lagrange пишет, что срок действия сертификата истёк.
Обновил. Web-интерфейс тоже уже сделал в некотором виде - http://gears.headake.win/idec/ui2/ функционально пока отличается только возможностью отправки сообщения и ссылками на ответы.

> Тут тихо. Но, надеюсь, IDEC ещё шевелится
Не было бы это шевеление конвульсиями, будет жалко.
А есть ли какие-то мысли о его перспективах и, страшно сказать, развитии?
Когда я начинал ноду делать для gemini, одной из задумок было, что, мол, неплохо было бы создать единое idec-пространство и в вебе, и в gemini (можно ещё gopher подключить), рассказать в их рассылке, может кого-нибудь заинтересовало бы (там в рассылке, кажется, уже встречались проекты для автоматической агрегации постов с разных узлов). Но чем дальше думал, тем менее обоснованной казалась идея (несмотря на концептуальную близость сетей) - писать сообщения из gemini не выйдёт; портировать протокол легко, только нет gemini-клиентов (можно конечно предложить всем поднимать ноды, что будет даже круче, но чего-то удобного в этом качестве тоже нет).

ake> Следуя девизу "каждому пользователю сети по станции" организовал собственную.

Привет! Тут тихо. Но, надеюсь, IDEC ещё шевелится. :)

ake> Пока нет веб-интерфейса, можно использовать gemini-гейт - gemini://ake.crabdance.com:1966/

lagrange пишет, что срок действия сертификата истёк.

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

Оригинальных эх пока никаких нет, кроме локальной тестовой. В идеях для развития был/есть шлюз для одного "почти форума" и организация "форумообразного" фронтенда для idec. Постинг от поинта работает, но по поводу регистрации пока нет четких идей, ибо без своих эх и связи с другими нодами она ещё не имеет смысла. В перспективе - всё-таки сделать веб-интерфейс (чисто статический и, возможно, API + SPA) и как-то спозиционировать ноду (эхи, регистрация).

Собственно адрес станции для клиента - http://gears.headake.win/idec/
Пока нет веб-интерфейса, можно использовать gemini-гейт - gemini://ake.crabdance.com:1966/ (прокси - https://portal.mozz.us/gemini/ake.crabdance.com:1966/ )

Да здравствует static.lessmore.pw!

На самом деле я не справился с javascript, точнее с его экосистемой. Это не язык плохой, а я ленивый, если что. Мне больше нравится когда я могу пол года не обновлять свой код, а потом
когда опять будет всплеск энтузиазма к какому-то проекту, то обновить я все смогу легко и ничего не поломается. Это я про Go сейчас.
Ну и приятнее мне все же писать на Go, а не typescript :). Опять же на работе у меня таких проблем нет, т.к. все проекты, в которые я коммичу, довольно акутальные и там обновляется все нормально.

Так вот!

== Что будет с нодой dynamic.lessmore.pw

* Репозиторий на github/gitea будет отправлен в архив
* Веб-интерфейс какое-то время еще будет доступен, потом будет сделано перенаправление на static.lessmore.pw
* Нода продолжит работать по прежнему url https://dynamic.lessmore.pw/idec/
* Прямой доступ к API поиска elasticsearch будет закрыт
* Фетчинг всего со всего из list.txt продолжится. dynamic останется главным источником для фетча для static
* UI будет трансформирован в поисковую систему, как уже когда-то было, но под другим именем и с нормальными фичами, типа автодополнения. Будет объявлено позже.

== А что со static.lessmore.pw?

Нода:

* Строка для подключения клиентом https://static.lessmore.pw/
* В бэкенде по прежнему Elasticsearch
* Фетчатся только некоторые эхи. В данный момент это:
* pipe.2032
* idec.talks
* linux.14
* develop.16
* std.club
* std.hugeping
* game.rogue.14
* difrex.blog
* music.14
* plan.9

Веб:

* Новый полностью статический SSR интерфейс доступен по https://static.lessmore.pw
* В процессе написания интерфейса на шаблонах Go получилось что-то типа микрофреймворка с переиспользуемыми компонентами - прикольно :)
* Основная ориентация по тредам по времени. Будет возможность смотреть треды без привязки ко времени, а по колличеству на страницу, как везде, но потом
* Т.к. я фетчил не все, то в веб-интерфейсе не видны все треды - есть сообщения без топ-поста. Но они доступны в IDEC API и все новые треды будут отображаться нормально.

== Поиск

На static теперь есть полностью работающий поиск!

Можно искать просто "linux". А можно сделать что-то поинтреснее, типа

message:"Поставил в qemu 9front" AND author:"hugeping"

то будет искаться только фраза целиком в сообщении от @hugeping. Для простого поиска по любому из слов - просто воткните их туда через пробел.
Ну и в кавычках можно искать по всему по любой фразе. Важно: слова должны боть полными и без опечаток. т.е. "жопа" найдется, а вот "жипа" уже нет - это штука не такая умная, как яндекс :)
А в целом там синтакс Lucene, так что, можно конструировать довольно сложные запросы.

Исходники в скором времени будут выложены - это все та же самая нода.
Постинг с регистрацией тоже в скором времени прикручу.

Ах да. Пока что интерфейс абсолютно не оптимизирован для мобилок. Так-то на мобилках есть IDEC Mobile, но работу на мобилках я тоже сделаю ^_^.

Пишите про баги.

> С форматированием проблем нет.

Я имел в виду, что если, например, смотреть сообщения в виде ленты и показывать сообщения как есть, то когда какое-нибудь сообщение содержит # заголовки, это превращает ленту в неоднородную кашу (на мой взгляд), и цитирование в gemtext'е только одноуровневое и не имеет синтаксиса с указанием автора. То есть всё равно либо нужно делать небольшой слой для форматирования, либо можно обернуть текст сообщения в преформатированный блок, что я и сделал.

> А на чём проект написан?

На python. С фетчером всё просто - requests + sqlite. Интерфейс для gemini на самодельном фреймворке ( http://code.headake.win/serpens-framework ), но он очень сырой и это по сути первое его осмысленное применение. С фреймворком изначально идея была сделать примитивный WSGI-сервер для gemini, но транслировать запросы, чтобы можно было взять существущие фреймворки, оказалось для меня сложно, поэтому сделал примитивные хост-сервер с протоколом "в духе" WSGI и flask/bottle-подобный модуль для приложений.

Вообще, круто! Сам хотел что-то делать подобное, но времени на всё не хватает.

А на чём проект написан?

> С отображением сообщения есть особенность - текст сообщения завернут в преформатированный блок, чтобы разметка не ломалась,

С форматированием проблем нет. Я писал себе форматер, он как раз берёт мои сообщения из idec и постит в виде блога на gemini://hugeping.tk

Вот этот код: https://github.com/gl00my/ii-go/blob/master/ii-gemini/main.go#L49

Доброго времени суток.

Сделал интерфейс для просмотра эх IDEC в gemini.
gemini://ake.crabdance.com:1966/
https://portal.mozz.us/gemini/ake.crabdance.com:1966/ - через HTTP-прокси

Реальная нода на сервере ещё в планах, пока лишь самописный фетчер, сообщения тянутся с club.hugeping.tk и idec.spline-online.tk. С отображением сообщения есть особенность - текст сообщения завернут в преформатированный блок, чтобы разметка не ломалась, правда, в некоторых клиентах при этом теряется автоматический перенос строк.

Новый адрес: club.hugeping.ru или club.hugeping.tk

По hugeping.ru/hugeping.tk будет мой личный блог.

Если кто-то фетчит, поменяйте пожалуйста.

P.S. Edited: 2021-03-13 20:21:37

Привет!

Погрузился тут в gemini и понял, что эта технология отлично дополняет idec.
А вы как думаете?

Написал пост на эту тему в ii://std.hugeping[*][*]
ii://p1c3ltDDAoaFciX04W2I[*][*]

Веб ссылка: http://hugeping.tk/p1c3ltDDAoaFciX04W2I/1

Суть технологии в двух словах.

* Как допиленный gopher;
* UTF-8;
* Есть куча серверов и браузеров.

hugeping> Интересное совпадение. У меня работала и на eeepc и на thinkpad и на настольном PC...

А у меня даже в виртуалбоксе при обновлении все время зависала намертво. А на комп ее ставить я не пробовал.

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

Интересное совпадение. У меня работала и на eeepc и на thinkpad и на настольном PC...

btimofeev> Haiku или OpenBSD выглядят интереснее.

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

Haiku, кстати, в своем составе имеет некоторые компоненты из FreeBSD, например, драйвера сетевых карт (из того что я видел в исходниках).

Я в 2007 году много "игрался" c kolibri. Она у меня даже в дуалбуте стояла. Но сейчас кажется, что ОС на ассемблере это тупик. Только если хочешь изучить и попрактиковаться в ассемблере, либо есть какой-то совсем древний комп.

Haiku или OpenBSD выглядят интереснее.

hugeping> Создал новую эху, посвящённую Plan 9.
hugeping> Не знаю, будет ли жить, но пока так. Раздаётся пока с http://hugeping.tk.

Эха доступна в таверне.

Создал новую эху, посвящённую Plan 9.

Не знаю, будет ли жить, но пока так. Раздаётся пока с http://hugeping.tk.

Привет. В виртуалке когда-то смотрел и колибри и менуэт.
Восхищает, примерно как восхищает демосцена.
Но в практическом смысле - не применял.

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

В принципе не переношу всплывающие уведомления. Особенно от сайтов.

Кто-то пробовал http://kolibrios.org/ ?
Операционка размером 1.4 Мб, написана на ассемблере, имеет графический интерфейс и все такое)

В wordpress еще относительно неплохо сделано. И на github - серединка на половинку.

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

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

Всегда выключал их, потому что они ужасно надоедливые. А на новостных сайтах их никогда включать не стоит, потому что начинают заливать спамом и чернухой

// Вообще, для RSS не так сложно сооружать парсеры

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

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

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

Принципиально не использую. Раньше когда-то случайно где-то нажал и сильно задалбывало.

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

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

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

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

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

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

> git clone git://github.com/idec-net/new-docs.git

что-то я не догадался в etch проверить: думал, рабтотать не будет

оказывается, работает

конечно, не html и требует git, но всё равно совет хороший, надо будет добавить комментарий

>> Документация нет доступной без https, но есть в гите.

> github тоже требует https

git clone git://github.com/idec-net/new-docs.git

Ну, и где тут https?

Вот еще по http зеркало dynamic http://ideclubzduruedpzzrxxbt2hk6apecuhni5vnjlsqg2t3gdet26fjyid.onion/ но в TOR :)

А вот на Таверну залил документацию http://idec.spline-online.tk/s/download/idec/docs.tar.gz из master гита

Ещё вариант: как то вести отдельно список отредактированных сообщений, и тогда те, кто поддерживают такую фичу, просто скачают эти сообщения повторно и добавят в свои списки... Ну, списки сделать как u/e, ещё одну схему...

Привет, All!

Как думаете, есть ли смысл думать а внесении в стандарт возможности редактирования сообщений?

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

Может быть, есть смысл сделать что-то вроде такого:

- Редактирование, это создание нового сообщения, с новым msg id;
- В тегах этого сообщения прописан msgid сообщения, которое оно заменяет.

Тогда клиенты, которые не поддерживают этой фичи просто получат новую копию.

Но что делать с отображением этих двух (или больше) сообщений? Скрывать при визуализации "заплаточные", но раздавать их по fetch? Как-то странно...

Что думаете? Есть ли смысл думать в эту сторону, или это только усложнит простую технологию?

Мне кажется, это всё слишком сложно для идеи ii, но может у кого-то будут ещё варианты? Редактирование сообщений, всё-таки, полезная вещь в быту...

> Документация нет доступной без https, но есть в гите.

github тоже требует https

> Еще Таверна по http работает http://idec.spline-online.tk/

если не считать отсутствующих шрифтов-иконок, отлично смотрится в Epiphany на Debian Etch :)

Документация нет доступной без https, но есть в гите.

Еще Таверна по http работает http://idec.spline-online.tk/

Какие www-сайты и сервисы, кроме станции hugeping.tk, доступны сейчас по
чистому http, без https? Есть ли документация по сети, доступная по http?

oldpc> Я путаю, или когда-то был клиент caesium на python2? Если был, то поделитесь ссылочкой, где можно найти.

Путаешь. Я на python2 никогда не писал.

Я путаю, или когда-то был клиент caesium на python2? Если был, то поделитесь ссылочкой, где можно найти.

+++ Caesium/0.4 RC1

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

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

Извините. :)

vit01> Просьба отписаться всем остальным, кто пользуется клиентом, каков расход батареи
Расхода нет.
vit01> ну и доп. инфа, что за мобила, какая версия ОС и.т.п.
SM-n900, Android 7.1.2, LineageOS-14.1-20200911-unofficial-ha3g

johnbrown> Заметил довольно большой расход заряда - чуть больше 6% на дефолтных настройках.

Просьба отписаться всем остальным, кто пользуется клиентом, каков расход батареи

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

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

Заметил довольно большой расход заряда - чуть больше 6% на дефолтных настройках.

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

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

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

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

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

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

Пофиксил, фетчу тебя :)

Сделал исправление тоже, поставил на тебя фетч (blog.difrex). Ожидаю взаимного фетча. ;)

> У меня тоже. Но это все таки данные не совсем для человека.

Ну как, curl можно автоматизировать. Я так и делал, когда переносил данные с ноды, генерировал скриптом запросы, парсил вывод. Удобнее с \n это делать.

> Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

Лучше я промолчу о том, что я делаю с сообщением поинта, а то вы меня тут заклюёте =)

> // Newline в конце добавлю, но фетчер у меня умеет и так и так.

Угу, отпишись тогда, я от тебя хочу взять fetch difrex.blog (ну и назад забирай тогда её у меня =)

> У меня даже emacs в файлах в конце '\n' ставит :)
У меня тоже. Но это все таки данные не совсем для человека.

Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

// Newline в конце добавлю, но фетчер у меня умеет и так и так.

Difrex> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

В стандарте вроде про newline ничего не сказано, поэтому предусматривается, что "\n" - это лишь разделитель списка, и в конце он необязателен

В нодах и клиентах принято использовать логику, по которой принимают и то, и другое. Но, думаю, для лучшей совместимости с unix-утилитами стоит явно закрепить в стандарте, чтобы newline в конце присутствовал

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

Difrex> Ну, в общем давай подождем остальных, что скажут. По мне так '\n' в конце списка эх необязателен, т.к. не относится к данным.

'\n' в конце это однозначное и ожидаемое поведение. Мне кажется, что делать стоит единообразно. У меня даже emacs в файлах в конце '\n' ставит :)

> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

Мой довод, в основном, будет таким.

В UNIX все текстовые файлы традиционно заканчиваются на \n.

https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

Стандарт POSIX определяет строку так:

> 3.206 Line
> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Зафиксируем это и не ошибёмся. :)

Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

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

> В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?
Это справедливо только для имен эх, а вот id сообщения всегда можно понять прочитался ли он полностью.

Ну, в общем давай подождем остальных, что скажут. По мне так '\n' в конце списка эх необязателен, т.к. не относится к данным.

> А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

Почему так, вопрос, который я тоже могу задать: "Разве ты не делаешь просто Printf каждого из id? Зачем вырезать последний \n?

Дело в том, что я старался писать строго. Строка с переводом строки - это однозаначность. Например, пустая строка - это тоже пустая строка и \n.

В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?

Например, вот функция, которая используется везде при работе с сетью:

func http_req_lines(url string, fn func(string) bool) error {
	resp, err := http.Get(url)
	if err != nil {
		return err
	}
	defer resp.Body.Close()
	reader := bufio.NewReader(resp.Body)
	for {
		line, err := reader.ReadString('\n')
		if err != nil && err != io.EOF {
			return err
		}
		line = strings.TrimSuffix(line, "\n")
		if err == io.EOF {
			break
		}
		if !fn(line) {
			break
		}
	}
	return nil
}

Обрати внимание, что if err === io.EOF стоит ПЕРЕД fn(line).

А вот правка, чтоб сработало с твоей нодой:

                if err == io.EOF {

			if line != "" { /* no eol in last line? broken node? */
				fn(line)
			}
                        break
                 }

Если же я перенесу fn(line) перед err == io.EOF, то fn(line) будет вызываться для последнего \n у других нод, которые делают \n в каждой строке.

Я лично считаю, что \n быть должен, но в как бы мы не решили, это должно быть прописано в стандарте, кмк.

> Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный.
А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

messages := make(map[string][]string)
echoList := strings.Split(getBody(resp.Body))
var currentEcho string
for i := range echoList {
  if echoList[i] == "" {
    continue
  }
  if isEcho(echoList[i]) {
    currentEcho = echoList[i]
  }
  if isMessage(echoList[i]) {
    messages[currentEcho] = append(messages[currentEcho], echoList[i])
  }
}

> Хм, вот про newline в конце интересно. Это у нас нигде не описано, но и проблем ни у кого не возникало

Нужно решение комитета. )
Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный. Заметил только благодаря адаптивному фетчу, который делает пробы по 1 id. Так бы просто последнее сообщение бы не взял и всё.

Хм, вот про newline в конце интересно. Это у нас нигде не описано, но и проблем ни у кого не возникало

hugeping> Достаточно ли замены:

hugeping> ====
hugeping> msg = strings.Replace(msg, "-", "+", -1) /* if it is URL base64 */
hugeping> msg = strings.Replace(msg, "_", "/", -1) /* make it base64 */
hugeping> ====

hugeping> И потом декодировать стандартным base64? Но там вроде еще есть заполнение в виде ===?

Должно быть достаточно. А заполнение как было знаками равно, так и должно вроде как остаться таковым

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

> Fixed
Теперь есть другая проблема. Возможно, с моим фетчером.
В выводе у тебя нет последнего перевода строки. То-есть, на запрос -1:1, к примеру, приходит MsgId без \n. Как к этому относиться? Нужно ли мне переделывать?

Fixed

Хм. Это я сломал что-то в базовом протоколе :).

Работает только со смещением сейчас

curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog/-250:250
difrex.blog
2fDZ67P8JkchA9Rh4If4
2NszlFTgvhakzz7dIfvc
ML8cpSyzyOKaFA6Lx1NF
8TtPHu5T7oo3GSXdDYc5
U6ZYZxgYz2sq01L96zZz
igt9lCsui5qE9AICtdgP
mTWsJXVOAljita3sgDOK
V0hj3Z0QjFxpluaaiKvI
b91aGfRgRLJWfB1q60bg
pNfzXBddGbSy7AW7slpz
4fmEizz5kjk4UcQf7VIJ
OxdmEiQJIZqrqjCUNp2i
ojRAXNp7wzVIF9GBetZn
z5UV57mUeyhAmFsaMUq0

Спасибо, поправлю.

Достаточно ли замены:

msg = strings.Replace(msg, "-", "+", -1) /* if it is URL base64 */
msg = strings.Replace(msg, "_", "/", -1) /* make it base64 */

И потом декодировать стандартным base64? Но там вроде еще есть заполнение в виде ===?

> Да, именно так, надо детектить, но это просто делается: всего лишь прогоняешь строку через замену символов, заменяя спецсимволы по словарю.

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

Можно рассказать алгоритм?

hugeping> Это про msgid речь же. А вопрос вроде касался того, в каком формате поинт шлёт бандл на ноду (POST или GET, не важно). И в каком формате отдают/получают бандлы ноды.

Для поинтов политика такая: если пересылает через GET, значит обязательно urlsafe. Если через POST, то поинт может выбрать любой вариант, какой захочет, ведь нода обязана поддерживать и тот, и другой

hugeping> В стандарте есть такая фраза: (все серверы обязаны принимать как обычный, так и urlsafe-словарь, генерируются же бандлы в формате обычного base64)

hugeping> Для меня эта фраза непонятна. Бандлы вроде в обычном base64, но принимать я должен в любом? Надо детектить тип base?

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

То есть ещё раз: принимать нужно оба формата одновременно, но генерировать на отдачу желательно (как необязательная рекомендация) в обычном base64

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

>> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.

Это про msgid речь же. А вопрос вроде касался того, в каком формате поинт шлёт бандл на ноду (POST или GET, не важно). И в каком формате отдают/получают бандлы ноды.

В стандарте есть такая фраза: (все серверы обязаны принимать как обычный, так и urlsafe-словарь, генерируются же бандлы в формате обычного base64)

Для меня эта фраза непонятна. Бандлы вроде в обычном base64, но принимать я должен в любом? Надо детектить тип base?

Я так и не понял, в каком варианте base64 я должен принимать и отдавать бандлы нодам и принимать бандлы от юзера. В итоге имеем такие варианты:

Мой:
1) Я принимаю и отдаю нодам бандлы в обычном base64 (не считая msgid, который подвергается преобразованию описанному в стандарте)

2) принимаю post/get запросы от поинтов в urlsafe base64

И вроде это работает, по крайней мере со станцией Андрея.

difrex:

1) принимает от поинтов обычный base64 но предварительно заэскейпченный

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

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

Наконец-то исправил, чтобы норм отображалось.

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

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

Цитирую: https://ii-net.tk/idec-doc/?p=standarts

> Id сообщения (msgid) - уникальный номер, который генерируется станцией, как 20 первых символов base64 sha256-bin хэша сообщения.

> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.

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

> Предлагаю прописать font-family: sans-serif в body-блок CSS-ки. Это сработает на всех платформах, и разница станет заметна невооружённым глазом. Попробуй хотя бы ради эксперимента

Вообще, я пробовал. Но тут такое дело. Я не хочу навязывать sans/sans-serif. Я сам из тех, кто долго верил в теорию вреда "шрифтов с засечками". А потом попробовал засечки, и мне понравилось. Поэтому я не хочу навязывать стиль шрифта. Пусть отображается дефултная настройка браузера. Те, если у тебя стоит в дефолте шрифты с засечками, ты их и увидишь. Есть вопрос с мобильными браузерами, там такой настройки нет... Ну, что поделать.

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

AL> Лицензионные вопросы важны.

Здесь я ничего не навязываю, а просто предложил дискуссию и вижу проблему в распылении ресурсов. Если юзкейс каждой из либ слишком специфичен, то мержить и правда не имеет смысла

vit01>> 2. Лично мне хотелось бы не новой ноды, а нормального десктопного клиента. С избранными, с черновиками, с красивым современным интерфейсом...
AL> Всё от того, что ты хочешь пальцетыкательный интерфейс на десктопе, что, очевидно, моветон.

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

На Андроиде это хорошо сделано в стандартном емейл-приложении (или в GMail, где тот же интерфейс). На десктопе - Thunderbird, Apple Mail, Outlook, и.т.п. Просто в плане общения IDEC слишком похож на Email, чтобы избежать такого сравнения

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

Это, конечно, грубо сказано было (и весьма в лоровском стиле, к сожалению), но тут тоже проблема просматривается и как раз объективная.

Особенность шрифтов без засечек - это то, что они не замыливают глаза и делают возможность "чтения по диагонали", что очень важно для контролов и других вспомогательных элементов интерфейса. А шрифты с засечками используют в книгах, потому что текст с ними сильнее въедается в мозги и вроде как лучше усваивается, но зато напрягает глаза

В современном веб-дизайне не просто так сложился консенсус, что шрифты без засечек лучше использовать по максимуму, а потому что это действительно читаемее. Кроме того, важен и размер шрифта, но это уже совсем другая история.

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

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

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

Окей, вопрос в каком-то смысле исчерпан

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

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

Эмм, да, но у браузера даже для стандартных шрифтов есть опции.

Предлагаю прописать font-family: sans-serif в body-блок CSS-ки. Это сработает на всех платформах, и разница станет заметна невооружённым глазом. Попробуй хотя бы ради эксперимента

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

Хотел было забрать блог difrex, но:

$ curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog
difrex.blog
error: Internal error

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

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

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

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

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

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

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

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

Лицензионные вопросы важны.

vit01> 2. Лично мне хотелось бы не новой ноды, а нормального десктопного клиента. С избранными, с черновиками, с красивым современным интерфейсом. Прямо сейчас пишу сообщение с IDEC Mobile в андроид эмуляторе, и это некомфортно: нельзя менять размер окна, приходится писать не с клавиатуры, а с графического планшета (т.к. с русским языком тут проблемы), да и сам этот эмулятор занимает гигабайта 3. Пытался накидать похожий интерфейс на Qt+QML и залип из-за их сложности, пытался на Flutter (кстати, хорошая штука), но понял, что надо будет заморачиваться с базой данных, и отложил это дело. Потихоньку пытаюсь попиливать Python-библиотеку в приватном репозитории, чтобы реализовать какое-то подобие клиента на Jupyter Widgets, но прогресс идёт слабо

Всё от того, что ты хочешь пальцетыкательный интерфейс на десктопе, что, очевидно, моветон.

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

Перепутал вкусовщину с объекьтивностью.
vit01> +++ GNU/Linux, Android, physics, MLP:FIM

hugeping> В общем, я поднял свою ноду - персональный арт-проект: http://hugeping.tk
hugeping> Прошу всех, кто с меня фетчит, переходить на http://hugeping.tk и отписаться о возникновении проблем.

Так, я тут как всегда самый медленный по ответам. Фетч настроил на hugeping

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

Что касается гошной библиотеки и новой ноды как таковых:

1. Нужно всё-таки объединять усилия, приходить к некоторым компромиссам и пилить одну библиотеку на всех. А аргумент "хочу другую лицензию" хоть и имеет смысл на существование, но на благо проекта точно не пойдёт. Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

2. Лично мне хотелось бы не новой ноды, а нормального десктопного клиента. С избранными, с черновиками, с красивым современным интерфейсом. Прямо сейчас пишу сообщение с IDEC Mobile в андроид эмуляторе, и это некомфортно: нельзя менять размер окна, приходится писать не с клавиатуры, а с графического планшета (т.к. с русским языком тут проблемы), да и сам этот эмулятор занимает гигабайта 3. Пытался накидать похожий интерфейс на Qt+QML и залип из-за их сложности, пытался на Flutter (кстати, хорошая штука), но понял, что надо будет заморачиваться с базой данных, и отложил это дело. Потихоньку пытаюсь попиливать Python-библиотеку в приватном репозитории, чтобы реализовать какое-то подобие клиента на Jupyter Widgets, но прогресс идёт слабо


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

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

> Да. Все что после него это base64. Вообще, может быть стоит сделать по другому. Я сделал как было проще...

Вообще, я думал про начало/конец тега base64. И в веб версии это будет шикарно, в том числе и для картинок. Но если такое внедрять в консольные клиенты, всё-таки, одно сообщение - один base64 аттач - это более понятная и простая схема...

В любом случае, если назреет какой-то стандарт на эту тему, попробую поддержать. :)

> Главное, чтобы в x/c правильно отображалось :)

Очень надеюсь, что багов не будет. Хотя опыт показывает, что когда всё работает сразу, это означает наличие скрытых багов. :)

btimofeev> У тебя почему-то в топиках количество сообщений выводится на одно меньше, чем сообщений в топике на самом деле, т.е. существуют топики с нулем сообщений. Я тебе об этом в чате писал, но ты наверное пропустил, либо это фича, а не баг.

Главное, чтобы в x/c правильно отображалось :)

> Фетчу тебя. Пока все идет нормально.

Отлично! :)

>> @base64: имя файла - всё, что после этой строки берется как base64 аттач демка тут
> Т.е. этот тег должен находится в конце тела сообщения?

Да. Все что после него это base64. Вообще, может быть стоит сделать по другому. Я сделал как было проще...

> Просто тогда в колонке это надо назвать не посты, а ответы, наверное.

Согласен, завтра сделаю.

hugeping> Я специально вычитаю 1. Как это сделано на punbb форуме. Типа это ответы на пост. Не считая заголовок. 0 - нет ответов.

hugeping> В принципе, фича, но можно поменять в коде....

Просто тогда в колонке это надо назвать не посты, а ответы, наверное.

> У тебя почему-то в топиках количество сообщений выводится на одно меньше, чем сообщений в топике на самом деле

Не заметил в чате.

Я специально вычитаю 1. Как это сделано на punbb форуме. Типа это ответы на пост. Не считая заголовок. 0 - нет ответов.

В принципе, фича, но можно поменять в коде....

У тебя почему-то в топиках количество сообщений выводится на одно меньше, чем сообщений в топике на самом деле, т.е. существуют топики с нулем сообщений. Я тебе об этом в чате писал, но ты наверное пропустил, либо это фича, а не баг.

> Прошу всех, кто с меня фетчит, переходить на hugeping.tk и отписаться о возникновении проблем.
Фетчу тебя. Пока все идет нормально.

> @base64: имя файла - всё, что после этой строки берется как base64 аттач демка тут
Т.е. этот тег должен находится в конце тела сообщения?

Написал базовую документацию. На этом пока всё, буду потихоньку развивать ноду, но уже не так экстемально. :)

Если кого-то будут интересовать детали, расскажу или дополню доку.

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

В общем, я поднял свою ноду - персональный арт-проект: http://hugeping.tk

Сейчас идёт синк с http://club.syscall.ru , но я буду его закрывать...
Прошу всех, кто с меня фетчит, переходить на http://hugeping.tk и отписаться о возникновении проблем.

Испытываю по живому. :)

За одно сливаю теперь свои материалы с разных источников. Хочу, чтобы хранилось всё в одном месте.

Новое на стенде: Появились ЛС! Как реализовано?

Эха, которая начинается с . (.private - на сервере). Это такая эха, в которой пользователь видит только свои сообщения, сообщения написанные ему и сообщения адресованные All

Такие эхи отдаются на фетч только по строке: /point/authstr/u/e/список эх

Список эх может включать не только приватные эхи, но и другие

В веб это смотрится довольно гармонично!

Итого, из моих планов -- осталось только шлифануть порефакторить и написать документацию :)

С аватарками есть проблема. Как именно идентифицировать пользователя?
Сначала, я сделал по адресу. Потом по полю From. Оба решения не ахти.
Мне кажется, пока у нас нет отдельных register серверов, аватарки можно делать только кустарно-индивидуально. А так, мне тоже аватарки нравятся. )))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Мой прототип можно пошатать здесь: http://club.syscall.ru:8080

> Можно и нужно его пошатать, если кому-то есть на это время/интерес. )

Только, конечно, не подключайте фетч на свои боевые ноды! Сейчас там тестирование. Можно ломать. :)

Мой прототип можно пошатать здесь: http://club.syscall.ru:8080

Можно и нужно его пошатать, если кому-то есть на это время/интерес. )

> Давно я не трогал этот клиент, хотя и пользуюсь сейчас только им. Пётр вдохновил и я снова взял в руки шашку.

Отлично! Надо будет заценить.

У меня тоже процесс идёт хорошо. Скоро будет нода моей мечты. :))

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

Список изменений:

* Исправлена ошибка на странице настроек, возникающая при неудачной попытке получить списки конференций с сервера.
* Добавлена страница списка сообщений в эхе.
* На главной странице и странице отдельного сообщения добавлена кнопка ответа.
* На главной добавлена ссылка на сообщение.

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

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

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

Прикольно :)

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

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

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

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

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

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

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

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

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

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

Угу, ошибся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cd ii-go/ii-tool
go build

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

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

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

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

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

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

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

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

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

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

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

В обновлении от сегодня починены краши из-за конфликта версий ACRA и AndroidX

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

Пока я поменял несколько сообщений, в сабжекте которых упоминался тот, чьё имя нельзя упоминать )

> Теперь он мне пишет, потому что на сайте instead клуба мессаги ещё висят, а с тобой он не может связаться,
> потому что твоих контактов нигде нет

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

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

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

vit01> А циклические крэши, скорее всего, из-за того что Email-клиент не установлен. Обычно если раз 10 нажать "Отмена", то клиент, как правило, оживает.

Да нет, установлено два клиента было.

Difrex>> Тогда нужно будет и id сообщений править, иначе он не будет вычисляться.
vit01> По стандарту id не обязан напрямую вычисляться из сообщения, он лишь должен удовлетворять требованиям по длине, набору символов и уникальности в базе

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

Difrex> Тогда нужно будет и id сообщений править, иначе он не будет вычисляться.

По стандарту id не обязан напрямую вычисляться из сообщения, он лишь должен удовлетворять требованиям по длине, набору символов и уникальности в базе

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

Тогда нужно будет и id сообщений править, иначе он не будет вычисляться.

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

я у себя так сделал

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

Вот че спрашивает тепере:

> I see. But is there any way to hide that message? I mean not make those message display when I search my name?

Как с ним поступим?

Так вот же ты в него отвечаешь =)

А где этот тред вообще? Я наверное эту эху не тяну?

Опять пишет. Уже хочет, чтобы мы снесли вот этот самый тред. Погуглил законы РФ. Так вот по ним хотя имя с фамилией и относятся к персональным данным, но физическое лицо не может требовать от оператора(т.е. нас) удаления их, т.к. это обезличенная информация. Если бы вместе с именем был бы еще и номер телефона или адрес домашний, тогда были бы обязаны. Сейчас нет. Попробовал ему это разъяснить.

Difrex> Тут на меня вышел автор игры GRANDIOSE DELUSIONS и попросил удалить сообщения с упоминанием его имени - я удалил.

Мне он тоже написал. Грохнул сообщения. Спасибо.

Потёр упоминание, но там вроде никаких данных не было

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

Тут на меня вышел автор игры GRANDIOSE DELUSIONS и попросил удалить сообщения с упоминанием его имени - я удалил.
Удалил не сразу, сначала с ним попереписывался, он запруфал, что он действительно автор, я удалил.
Он пошел писать владельцам остальных узлов, если что.

Сообщения, которые он попросил грохнуть:

* KxywR6BzZ320THNHMj8e
* rS7Ezecbv31yD6VzV4e6


Нечто подобное, я помню, кто-то уже кому-то писал.

btimofeev> Выключаю в настройках встроенный редактор сообщений -> пробую ответить на любое сообщение -> приложение падает -> при попытке отправить отчет оно начинает падать циклически и эти крэши можно остановить только переустановкой.

Дошли руки, починил баг с встроенным редактором, можно обновляться.
А циклические крэши, скорее всего, из-за того что Email-клиент не установлен. Обычно если раз 10 нажать "Отмена", то клиент, как правило, оживает.

+++ IDEC Mobile в виртуальной машине
+++ GNU/Linux, Android, physics, MLP:FIM

Выключаю в настройках встроенный редактор сообщений -> пробую ответить на любое сообщение -> приложение падает -> при попытке отправить отчет оно начинает падать циклически и эти крэши можно остановить только переустановкой.

Difrex> Сабж. Ругается на регекспы https://github.com/idec-net/ii-php/blob/master/iiweb.inc.php#L23

Спасибо за внимательность. Регэкспы пришлось менять из-за обновления на php 7.3, для основной станции я это сразу сделал и закоммитил в гит, а про архив забыл

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