RSS
# Нодлист
idec.talks
Andrew Lobanov(tavern,1) — All
2022-01-24 05:31:03


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

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

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

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


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

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

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

# Re: Александр Столяров о творчестве
std.hugeping.micro
vvs(ping,12) — hugeping
2022-01-16 14:24:10


hugeping> Мысль о том, что когда-нибудь мы все вдруг проснёмся, кажется не такой уж и неверотяной... ;)

Бывает такое ощущение, иногда до боли. Для киберпанка - "Матрица", "13-й этаж". А для религиозных людей - страшный суд?

# Re: Александр Столяров о творчестве
std.hugeping.micro
hugeping(ping,1) — vvs
2022-01-15 16:34:11


vvs> Вспоминается ещё анекдот:
vvs> ... Очнувшись, он с ликованием подумал об удачном исходе столь трудного и опасного опыта и, дрожа от нетерпения и пережитого, поспешно развернул бумажку с драгоценной записью. На ней он прочел; “Банан велик, а кожура еще больше...”

Забавно! Не раз испытывал похожее во сне. Когда "гениальная мысль" оказывается бредом. :) Тем удивительней контраст по сравнению с ощущением озарения во сне. Мысль о том, что когда-нибудь мы все вдруг проснёмся, кажется не такой уж и неверотяной... ;)

# Re: Александр Столяров о творчестве
std.hugeping.micro
vvs(ping,12) — hugeping
2022-01-06 22:43:01


hugeping> Смотрю фильм про Александра Столярова (знаю его по фильму "Старец Паисий и я, стоящий вверх ногами").

Ещё один Столяров? ;)

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

Это всё так, но есть нюансы. Или, как гласит известное высказывание, дьявол кроется в деталях. А так, с философской точки зрения, конечно, на все сложные вопросы всегда существует один общий ответ: "все там будем" или "все под Богом ходим" (C)

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

Вспоминается ещё анекдот:
Как-то раз американский физик-экспериментатор Р.Вуд (1868—1955), довольно эксцентричный человек, любитель всяких острых ощущений, решил проделать на себе рискованный опыт — испытать действие наркотика. С большим трудом раздобыв опиум, он накурился этого зелья и вскоре впал в забытье. Придя через некоторое время в сознание, он вспомнил, что, находясь в одурманенном состоянии, напал на какую-то чрезвычайно глубокую и важную научную идею, но на какую именно — начисто вылетело из головы. Тогда Вуд решил повторить опыт в надежде, что ему посчастливится вновь обрести ускользнувшую мысль.
И действительно, как только начало сказываться наркотическое действие опиума, забытая мысль не замедлила возникнуть в уме ученого. Чувствуя, что сознание вот-вот покинет его, Вуд сумел в последний момент сконцентрировать волю, записать идею на бумажке и впал в беспамятство. Очнувшись, он с ликованием подумал об удачном исходе столь трудного и опасного опыта и, дрожа от нетерпения и пережитого, поспешно развернул бумажку с драгоценной записью. На ней он прочел; “Банан велик, а кожура еще больше...”

# Александр Столяров о творчестве
std.hugeping.micro
hugeping(ping,1) — All
2022-01-06 19:24:13


Смотрю фильм про Александра Столярова (знаю его по фильму "Старец Паисий и я, стоящий вверх ногами"). И тут такой забавный пассаж про творчество:

https://www.youtube.com/watch?v=RQ0HKYOR3c8&t=1221s

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

# 2022
idec.talks
shaos(shaos, 2) — All
2022-01-02 04:23:09


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

# Re: Актуальный нодлист
idec.talks
Ordos(tgi,1) — shaos
2021-12-24 10:31:59


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

# Re: Актуальный нодлист
idec.talks
shaos(tavern,34) — shaos
2021-12-24 07:12:14


А кстати небыло мыслей сделать специальный вызов в API, который возвращал бы uplinks?
Типа /fetches.txt
http://idec.spline-online.ml/;idec.talks/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum;15
https://.....;something.something;60
Ну и было бы неплохо иметь возможность через API спросить у нода как он называется, а то я сейчас не вижу как по http://idec.spline-online.ml понять, что это tavern

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

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — hugeping
2021-12-24 06:58:03


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

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
hugeping(ping,1) — shaos
2021-12-23 09:11:45


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

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

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

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


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

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

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

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

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


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

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

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

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


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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

# Re: IDEC identity
idec.talks
shaos(tavern,34) — Difrex(mobile)
2021-12-22 09:14:47


По поводу общих поинтов - PGP/GPG тяжеловат потому как многообразен - надо что-то одно широко известное выбрать и поддержать, но только цифровую подпись - без шифрования (которое в IDEC по-моему противопоказано), например можно взять отданный в общенародное достояние алгоритм Ed25519, существующий уже 10 лет и не подпадающий ни под какие патенты - в нём есть 32-байтовый публичный ключ и 64-байтовый секретный ключ (половина из которого это копия публичного ключа). Публичные ключи распространяются по всем узлам и клиентам (например посредством специальной эхо-конференции от имени пользователя как поинта своего узла) и идентифицируют глобальных пользователей (которые всё также могут оставаться поинтами на своих узлах). К сообщению подписанному цифровой подписью Ed25519 цепляется 64-байтовя signature (в строке тэгов после тэга signature/ например как 128-символьная шестнадцатиричная строка либо как 103-символьная строка в кодировке BASE32 либо как 86-символьная строка в кодировке BASE64URL, либо как 80-символьная строка в кодировке ASCII85 где символ / подменён скажем на | - хотя наверное надо таки использовать BASE64URL как родной способ кодирования бинарных данных в IDEC). Чтобы проверить валидность сообщения, по имени пользователя (msgfrom) берётся его публичный ключ (предварительно распространённый) и по телу сообщения проверяется его цифровая подпись, чтобы удостовериться, что письмо не подменено или не подписано поддельным ключом.

Подробнее про внедрения Ed25519: https://ianix.com/pub/ed25519-deployment.html

P.S. Правда надо ещё придумать процедуру восстановления identity если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-22 08:02:49


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

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

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

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

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

ii://1KpcmGrc9pUtZQ6Puv1z

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-22 07:54:13


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

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

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

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

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

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

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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-22 05:09:30


shaos> Несколько комментариев к моему изначальному сообщению.
shaos> - Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).

ii-go это анархическая реализация. Взять хоть редактирование сообщений :)

shaos> - При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-22 05:09:30


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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — shaos
2021-12-22 02:18:44


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

- Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).

- При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — ake
2021-12-22 01:47:34


> Касательно рассуждений о хэше для сообщений, пришла мысль, что 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 определяет
> то, как клиент будет отображать полученное содержимое.

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

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-22 01:38:43


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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
ake(ping,30) — shaos
2021-12-21 18:34:00


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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-21 17:41:54


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

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

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

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

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

# Мысли про возможное будущее IDEC
idec.talks
shaos(shaos, 2) — All
2021-12-21 08:13:05


Всем привет

Я познакомился в 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

# тестовое сообщение
idec.talks
shaos(shaos, 2) — All
2021-12-19 11:01:22


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

# Re: Два пустых сообщения в idec.talks
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-20 09:47:45


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

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

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
Andrew Lobanov(tavern,1) — shaos
2021-12-20 09:35:42


shaos> а почему ZX80? это же тормозная недоделка
shaos> программировать надо ZX-Spectrum (aka ZX82)

Похоже, смешались воедино ZX-Spectrum и Z80 %)

# Re: Два пустых сообщения в idec.talks
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-20 09:35:42


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

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

# Два пустых сообщения в idec.talks
idec.talks
shaos(tavern,34) — All
2021-12-20 07:46:43


Существует 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
Наверное если они невалидные их надо в чёрный список, не?

# Re: Актуальный нодлист
idec.talks
shaos(tavern,34) — ake
2021-12-19 12:37:02


Ну и от меня держите :)
{
    "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"
        ],
    ]
}

# Новый узел IDEC http://shaos.net:8085
idec.talks
shaos(tavern,34) — All
2021-12-19 12:35:00


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

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

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

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

Shaos

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
shaos(tavern,34) — hugeping
2021-12-19 11:41:25


а почему ZX80? это же тормозная недоделка
программировать надо ZX-Spectrum (aka ZX82)

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


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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

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


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

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

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

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


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

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

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

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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

# Re: Анонс станции
idec.talks
hugeping(ping,1) — ake
2021-12-15 19:24:52


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

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

# Re: Анонс станции
idec.talks
ake(ping,30) — ake
2021-12-15 18:36:49


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

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — hugeping
2021-12-15 17:15:11


https://github.com/breakintoprogram/lib-spectrum Z80 Library Routines
http://oldmachinery.blogspot.com/2014/04/zx-sprites.html ZX sprites (интересная статья)
http://sebastianmihai.com/libzx.html libzx
https://vtrd.in/book.php Много разных книг

P.S. Edited: 2021-12-15 17:54:47

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — hugeping
2021-12-15 16:34:39


https://zxpress.ru/book.php?id=18 Программирование в машинных кодах и на языке ассемблера

# Re: Актуальный нодлист
idec.talks
ake(ping,30) — Andrew Lobanov
2021-12-15 05:42:15


{
    "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" ]
    ]
}

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
vvs(ping,12) — hugeping
2021-12-14 16:22:38


hugeping> К сожалению, очень многие тулзы написаны только для Windows.

Это очень зависит от того, кто именно преобладает в данном сообществе. А в Линуксе, напротив, гораздо больше серверов и средств разработки. Бывает даже интересно сравнивать.

Моё личное впечатление, что это характерно именно для игровых платформ и их эмуляторов и у виндузятников там больше любителей, использующих какой-нибудь Бейсик или C#. А, например, в научных кругах, как правило, используют MacOS или Линукс, а языки совсем другие.

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
Andrew Lobanov(tavern,1) — hugeping
2021-12-14 11:36:30


hugeping> К сожалению, очень многие тулзы написаны только для Windows.

Потому что самая распространённая операционка на десктопах же. Всё логично. Эмуляторы тоже под линь есть не все, увы.

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — hugeping
2021-12-14 10:57:43


К сожалению, очень многие тулзы написаны только для Windows.
В крайнем случае можно запускать в wine. Например, zx-paintbrush работает: https://sourcesolutions.itch.io/zx-paintbrush

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — hugeping
2021-12-14 10:09:49


http://multipaint.kameli.net/ - multipaint - для создания графики
https://github.com/errorcalc/zx_starter_pack - starter pack для виндузятников (не наш путь, но можно подсмотреть тулзы)

# Re: Актуальный нодлист
idec.talks
vit01(mira, 1) — Andrew Lobanov
2021-12-14 08:03:42


{
    "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

# Re: Актуальный нодлист
idec.talks
Ordos(tgi,1) — Andrew Lobanov
2021-12-13 11:58:05


{
    "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"
		],
	]
}

# Re: Эха про спектрум
zx.spectrum
Andrew Lobanov(tavern,1) — hugeping
2021-12-13 11:14:54


hugeping> Может стоило вообще про ретрокомпы эху создать? Всё-таки нас тут полтора человека...

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

# Re: Эха про спектрум
zx.spectrum
hugeping(ping,1) — shaos
2021-12-13 10:39:51


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

# Re: Актуальный нодлист
idec.talks
hugeping(ping,1) — Andrew Lobanov
2021-12-13 10:34:21


{
    "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
Не знаю, как это отобразить.

# Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — All
2021-12-13 10:27:28


В детстве у меня была БК0010-01 и у неё был классный ассемблер (PDP-11). Не так давно я его даже освежил, портируя Boulder Dash на instead: https://instead-games.ru/game.php?ID=197 Это практически полная калька, но на Lua.

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

1) книг для начинающих
2) кросс-ассемблеров
3) что-то ещё?

В общем, информацию, которая могла бы помочь начинающим программистам на спектруме :)

Пока нашёл это:

https://zxpress.ru/book.php?id=2 (Как написать игру на ассемблере для ZX Spectrum)
https://k1.spdns.de/Develop/Projects/zasm/Distributions/ (zasm)
https://github.com/sjasmplus/sjasmplus (sjasmplus)

Если есть что подкинуть, кидайте!

# xpeccy
zx.spectrum
Andrew Lobanov(tavern,1) — All
2021-12-13 10:05:22


Очень полюбился мне этот эмулятор в последний год, но наткнулся на интересную особенность: если в настройках Qt выставить scale rate отличный от единицы, то он влияет и на эмулируемую картинку. Привет, пиксели разного размера и соотношения сторон!

Есть возможность поправить этот момент средствами настройки Qt или стоит связаться с разработчиком и задать этот вопрос ему лично? :)

# Re: Эха про спектрум
zx.spectrum
shaos(tavern,34) — Andrew Lobanov
2021-12-13 08:34:03


> Обсуждаем speccy и совместымые компьютеры, софт, эмуляторы, мероприятия и всё-всё-всё.

Отлично - всеми руками за :)

# Эха про спектрум
zx.spectrum
Andrew Lobanov(tavern,1) — All
2021-12-13 08:27:11


Обсуждаем speccy и совместымые компьютеры, софт, эмуляторы, мероприятия и всё-всё-всё.

# Актуальный нодлист
idec.talks
Andrew Lobanov(tavern,1) — All
2021-12-13 10:03:22


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

Просьба скинуть или сюда или на 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"
		]
	]
}

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

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

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

# Доступ к idec-net на github
idec.talks
Andrew Lobanov(tavern,1) — All
2021-12-13 10:03:21


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

# Новая эха
idec.talks
Andrew Lobanov(tavern,1) — All
2021-12-13 10:03:21


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

# Re:instead в Google Play
std.club
hugeping(ping,1) — hugeping
2021-12-13 09:47:22


Борис Тимофеев выложил Re:instead в Google Play. Так что библиотечка парсерного сопротивления стала ещё доступнее. Не забывайте оценивать приложение, если оно вам нравится. ;)

https://play.google.com/store/apps/details?id=ru.hugeping.reinstead

#news

# Re: Спринтер
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-13 08:03:35


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

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

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

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

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

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

# Re: Спринтер
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-13 06:45:54


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

# Re: Спринтер
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-13 06:02:46


> Всегда интересно узнавать историю таких проектов. Я в железе имел максимум самопальный пентагон,
> а в начале нулевых (как раз 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 со своими клонами). В данный момент Спринтер снова возрождается и показывает, что во многом он всё ещё лучше и даже "современнее" Эволюшина, а в чём то даже лучше некста :)

# Re: Спринтер
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-13 05:22:03


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: С эволюшеном я познакомился пока только в эмуляторе и мне в целом понравилось. Но спринтер, насколько я понял, более интересная машинка.

# Re: Спринтер
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-13 05:07:56


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

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

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

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

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

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

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

Alexander Shabarshin aka Shaos

# Re: Бегство от тишины
std.hugeping
vvs(ping,12) — Andrew Lobanov
2021-12-09 13:57:26


AL> Я в учебник Столярова бегло заглянул в первый том. В целом, плохо. Но кое какое представление даёт. Главное, чтобы подопытные понимали, что это не догмат.

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

AL> Одно дело быть хорошим специалистом, совсем другое это уметь хорошо излагать свои мысли на бумаге. Курсы такие я не видел, так что не знаю насколько этот навык развиваем без должного прилежания.

Такой курс читают в некоторых иностранных университетах. Кроме того есть и курс академического английского.

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

Опытный человек вынесет что-нибудь полезное даже из Malleus Maleficarum. Но не у всех студентов есть достаточный опыт для этого.

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

# Спринтер
idec.talks
Andrew Lobanov(tavern,1) — All
2021-12-09 05:17:37


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

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

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

# Re: Бегство от тишины
std.hugeping
Andrew Lobanov(tavern,1) — vvs
2021-12-09 05:17:37


vvs> Ну, не знаю. Моей первой книгой была "Программирование на IBM/360" К.Джермейн. По-моему, она была тогда получше для восьмиклассника. По крайней мере, она меня увлекла на всю жизнь :) Такие книги издавали ещё и в 90-х, например П.Нортон и Р.Журден, но там был, в основном, справочный материал, который больше нигде нельзя было тогда найти. Да и когда то было, сейчас какой год на дворе? Я думал мы уже выросли из подобной литературы.

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

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

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

Таких педагогов у нас много. Лично знаком с двумя :)

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

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

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

Столяров хорошо акцентировал внимание на информационном насилии. Это действительно серьёзная проблема в современном мире. Но это не про эти книги.

vvs> В общем, плач Ярославны :(

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

# Re: Бегство от тишины
std.hugeping
vvs(ping,12) — Andrew Lobanov
2021-12-08 13:46:55


AL> Книга далека от идеала, но лучше на русском языке ничего нет. То есть книги Столярова это такая отправная точка для тех, кто только делает первые шаги в CS. Где-то с перегибами, где-то с недосказанностью, где-то с ошибками. Но свою задачу, мне кажется, она выполняет - даёт представление о компьютере и программировании в достаточном для дальнейшего самостоятельного обучения объёме.

Ну, не знаю. Моей первой книгой была "Программирование на IBM/360" К.Джермейн. По-моему, она была тогда получше для восьмиклассника. По крайней мере, она меня увлекла на всю жизнь :) Такие книги издавали ещё и в 90-х, например П.Нортон и Р.Журден, но там был, в основном, справочный материал, который больше нигде нельзя было тогда найти. Да и когда то было, сейчас какой год на дворе? Я думал мы уже выросли из подобной литературы.

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

AL> Сам же Столяров личность специфическая и фанатическая, что достаточно опасно в его случае, так как он помимо этого учебника ещё и учит живых студентов.

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

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

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

Я-то так и понял. Но знает ли об этом сам Столяров? :) И как воспринимает его аудитория? Здесь, в основном, негативные отзывы. Но ведь кому-то там даже что-то нравится :)

В общем, плач Ярославны :(

# Re: Бегство от тишины
std.hugeping
Andrew Lobanov(tavern,1) — vvs
2021-12-08 04:33:01


vvs> Интервью не смотрел. Столярова не знаю. Отражённые на его сайте взгляды умеренными явно не являются :) Оглавление его книг меня не впечатлило: лично я своё время предпочитаю тратить на более полноценное теоретическое изложение, а документацию предпочитаю читать не в вольном пересказе.

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

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

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

vvs> ====
vvs> Слушайте, ну достали уже одно и то же спрашивать. Текстовый слой сломан намеренно, а любая конверсия и вообще любое изменение тех файлов, которые здесь опубликованы — прямое и грубое нарушение лицензии. Найду — урою.
vvs> И да, к защите от копирования это никакого отношения не имеет. Копировать файлы, как можно заметить, никто и ничто не мешает.
vvs> ====
vvs> Странные у него взгляды, однако :)

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

# Re: Бегство от тишины
std.hugeping
vvs(ping,12) — hugeping
2021-12-08 00:02:07


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

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

И да, к защите от копирования это никакого отношения не имеет. Копировать файлы, как можно заметить, никто и ничто не мешает.
Странные у него взгляды, однако :)
P.S. Edited: 2021-12-08 00:02:31

# Re: gemini:// как дополнение idec
idec.talks
ake(ping,30) — Andrew Lobanov
2021-11-29 17:23:34


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

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

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

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

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

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

# Парсерное сопротивление: новые версии (МП 2.4)
std.club
hugeping(ping,1) — hugeping
2021-11-27 14:24:38


Встречайте большое обновление ПАРСЕРНОГО СОПРОТИВЛЕНИЯ!

Вышли новые версии проектов: МЕТАПАРСЕР, Re:instead и metaparser-js.

https://parser.hugeping.ru
https://instead.hugeping.ru/page/metaparser/

# МЕТАПАРСЕР 2.4

Парсерный движок для создания игр с текстовым вводом. Для использования требуется INSTEAD или Re:instead.

https://instead.hugeping.ru/page/metaparser/

Изменения:

* комната gameover теперь имеет атрибут 'gameover';
* функция getDaemons() -- получить список фоновых процессов;
* комната gameover останавливает все фоновые процессы;
* атрибут 'concealed' удаляется, когда предмет перемещается в инвентарь;
* новый метод obj.is_once() для проверки факта срабатывания obj.once();
* обновление документации;
* исправлены/улучшены некоторые сообщения.

# Re:instead 0.7

Минималистичный парсерный движок для Unix, Windows, Plan-9 и Android. В комплект включён набор игр.

* значительное улучшение кернинга при работе с freetype и libschrift;
* параметры -noautoload/-noautosave;
* новый метапарсер 2.4;
* исправления в игре "Краски октября";
* поддержка клавиши del;
* исправление при изменении размера шрифта;
* исправление смены иконки приложения в Windows;
* возможность делать синонимы команд (conf.cmd_aliases);
* Windows: перенаправлять stdout/stderr в errors.txt только если stdout не доступен;
* команды !script и !debug;
* !stop команда в autoscript.

# metaparser-js 2.4

Реализация парсера на js.

* обновление метапарсера до 2.4;
* команды !ls, !rm, !restart;
* возможность загружать и выгружать сохранения;
* возможность выгружать транскрипт (пока только в пределах одной игровой сессии);
* локализация на английский (язык выбирается по основному языку браузера).

# Re: gemini:// как дополнение idec
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-11-18 04:25:54


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, просто хочу критически посмотреть на всё это.

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

# Re: gemini:// как дополнение idec
idec.talks
hugeping(ping,1) — ake
2021-11-17 08:59:28


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

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

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

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

# Re: gemini:// как дополнение idec
idec.talks
ake(ping,30) — Andrew Lobanov
2021-11-17 08:12:06


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, просто хочу критически посмотреть на всё это.

# Re: gemini:// как дополнение idec
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-11-17 05:43:18


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

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

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

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

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

# Re: gemini:// как дополнение idec
idec.talks
hugeping(ping,1) — ake
2021-11-16 21:32:25


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

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

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

# Re: gemini:// как дополнение idec
idec.talks
ake(ping,30) — Ordos
2021-11-16 16:37:24


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

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

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

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

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

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

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

# Re: gemini:// как дополнение idec
idec.talks
Ordos(tgi,1) — ake
2021-11-16 13:58:56


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

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

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

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

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

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

# Re: gemini:// как дополнение idec
idec.talks
ake(ping,30) — Ordos
2021-11-16 11:42:55


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

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

# Re: gemini:// как дополнение idec
idec.talks
Andrew Lobanov(tavern,1) — Ordos
2021-11-16 11:31:29


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

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