fox :: from/ake

Re: tgi всё?

ake — 2026-01-30 10:09:32

ake -> nnii

===
62.181.53.175
===

Re: tgi всё?

ake — 2026-01-28 14:58:05

ake -> nnii

Кажется, домен истёк. Я нашёл старый IP, по нему станция доступна.

Re: NEW STATS

ake — 2026-01-24 21:40:03

ake -> shaos

Реализовал у себя в фетчере адаптивную загрузку индекса по несколько сообщений вместо загрузки его полностью. Стал почти в 10 раз меньше грузить, так что перестану занимать первое место в spnet.stats

Re: рутинг

ake — 2025-11-25 16:23:30

ake -> shaos

Есть же ещё реализация автоматического обнаружения с /nodes.txt, которую предложил foxears (ii://cobdA9fxXEwmR7mich2a). Я её у себя на ноде добавлял и тестировал.

Re: Я живой. Обсуждение микроблоги против форумов

ake — 2025-09-16 10:02:34

ake -> shaos

Кажется, старый сервер tgistation сменил владельца, т.к. сейчас по адресу, на который указывает tgistation.ru, находится какой-то сокращатель ссылок с другим доменом.

Re: И снова здравствуйте

ake — 2025-08-13 10:05:14

ake -> shaos

Сегодня обнаружил, что фетчер сломался. Если быть точнее, я на нём не сделал нормальную обработку таймаутов и он застревал на ii.yester.link, который доступен, но при этом почему-то работает как tarpit. Поэтому пока отключил фетч с этой ноды.
Если бы случайно не решил проверить, так бы и думал, что это всё отток из-за отключения tgistation.

Скрипт для автоматизированной эхи из gemini-лент

ake — 2025-02-25 13:08:18

ake -> All

По аналогии с ботами для RSS, сделал скрипт, который забирает список постов с узлов gemini, которые поддерживают спецификацию gemini://geminiprotocol.net/docs/companion/subscription.gmi и постит в определённую эху. Сама спецификация используется в gemini примерно для того же, что и RSS (автоматизированное получение списка новых постов) и много кто её использует/поддерживает - и персональные капсулы, и местные порталы, например, у BBS можно подписаться на подфорумы (gemini://bbs.geminispace.org/s/Gemini?feed). Пока сообщение содержит только дату, полный заголовок и ссылку, думаю потом добавить и содержимое страницы по ссылке (целиком или частично).

Сам скрипт - https://bitbucket.org/Keyreach/workspace/snippets/q7zg78

Re: И снова здравствуйте

ake — 2025-02-16 10:35:08

ake -> shaos

Странно, у меня доступен и по https и по http (на 1110)

Re: Форматирование

ake — 2025-02-12 11:30:06

ake -> doesnm

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

Форматирование

ake — 2025-02-11 11:23:43

ake -> All

Начал у себя в веб-интерфейсе добавлять поддержку ссылок в сообщении и обнаружил, что они у нас могут встречаться в совершенно разных видах - просто в виде URL, в виде markdown, в одном сообщении даже в виде HTML. Решил глянуть в документацию (https://github.com/idec-net/new-docs/blob/master/text-decoration.md), но там определены только блоки цитирования, преформатированного текста и внутренние ссылки. Сейчас в сети есть отдельные сообщения целиком в markdown (как минимум, использующие заголовки и ссылки), есть картинки в XPM (как понимаю, работающие только в ii-go), нет указаний на то надо ли сохранять все переносы строк или разбивать на параграфы пустыми строками. Получилась ситуация, когда каждый оператор (или разработчик) ноды реализует форматирование сообщений по-своему и ориентируется на свою же реализацию.

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

1. Как обрабатывать переносы строк в теле сообщения?
2. Нужно ли добавить в стандарт тег "+++" для подписей?
3. Нужны ли новые теги для форматирования текста (курсив, полужирный, списки и т.д.)?
4. Нужны ли теги для ссылок в тексте и какие?
5. Нужны ли дополнительные заголовки, "##" или "=="
6. Может ли быть HTML в сообщении и как его обрабатывать?
7. Что делать с XPM-картинками?

Re: Автодискавери

ake — 2025-02-07 15:00:44

ake -> foxears

Добавил у себя на ноде поддержку /nodes.txt и /d запроса, который пока только добавляет в список и не фетчит. Забавно, что вылез баг из-за того, что не определились с каноническим видом URL'а - со слешем в конце или без (да и я не подумал, а просто решил отдавать их в том виде, как они используются в коде), и при автообнаружении у тебя продублировались ноды.

Re: И снова здравствуйте

ake — 2025-02-07 12:32:49

ake -> doesnm

doesnm> Кто-то уже стянул ii.14 в архив?
Я добавился к foxears, на его ноде теперь тоже есть. Правда, что-то странное с сортировкой сообщений, после 2018 идёт пачка сообщений из 2014

Проверка

ake — 2025-02-06 13:17:40

ake -> All

Получает ли кто-нибудь сообщения с этой станции

Test

ake — 2025-02-06 10:58:04

ake -> All

Test

Изменения

ake — 2021-12-16 10:17:11

ake -> All

Добавил ссылки на ответы при просмотре сообщения в gemini-версии

Идеи

ake — 2021-07-02 08:09:47

ake -> All

Для станции
* регистрация с помощью openid/indieauth
* постинг/регистрация через email бота
* эха по gemini
Глобальные
* эха для репортов на сообщения
* придумать механизм обнаружения станций

Веб-интерфейс

ake — 2021-07-02 20:50:28

ake -> All

Добавил форму для отправки сообщений в эхи

Re: ...

ake — 2021-07-01 20:14:00

ake -> ake

Test 2

Re: Идеи

ake — 2021-07-06 20:45:55

ake -> ake

Бот для thedailywtf.com

Re: веб-интерфейс

ake — 2021-07-06 12:06:23

ake -> ake

Сделал улучшенный интерфейс в стиле некоторого форума - http://gears.headake.win/idec/ui2/

Test 3

ake — 2021-11-17 16:30:32

ake -> All

Test 3

...

ake — 2021-07-01 20:00:46

ake -> All

Test

Веб-интерфейс

ake — 2021-07-02 12:50:25

ake -> All

Запустил в тестовом режиме веб-интерфейс на http://gears.headake.win/idec/ui/ . По существу это порт на Flask гейта для gemini, т.ч. выглядит и работает так же, из достоинств - работает и в lynx, и в IE6.

Re: И снова здравствуйте

ake — 2025-02-06 13:29:06

ake -> ake

Пока поднял ноду на http://akewebdump.ddns.net/idec/ (с веб-интерфейсом на http://akewebdump.ddns.net/idec/ui2/ и шлюзом в gemini на порту 1966). К счастью для цифровой археологии, база со старыми сообщениями сохранились, так что можно почитать потеряную эху ii.14, о которой шла речь в ii://7b0lmkDJnAQlG2w2FvFx (то самое сообщение - http://akewebdump.ddns.net/idec/ui2/message/FGOqT29oVwwBElTJNMjx)

И снова здравствуйте

ake — 2025-02-06 11:14:50

ake -> All

Всем привет. Давно не заходил, а сеть-то ожила. Похоже, надо реанимировать свою ноду.

Re: Актуальные клиенты

ake — 2023-02-10 10:03:17

ake -> Ordos

Ordos> P.S. Интересно как реализована отправка сообщения в гостевые книги, ведь js тут не в почете. Да и вообще форм как таковых нет.

Есть аналог отправки GET запроса с параметрами (или ссылки типа 7 из Gopher'а, если угодно), на нём и делается вся интерактивность. Формы с несколькими полями делаются многошаговыми, где состояние хранится на сервере. Есть ещё неофициальное (хотя в Lagrange, кажется есть поддержка) расширение протокола - Titan, первоначально сделаное автором для реализации wiki, которое добавляет загрузку произвольных данных, вроде метода PUT.

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-23 23:37:43

ake -> hugeping

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

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

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

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-22 22:22:03

ake -> Andrew Lobanov

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

На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху 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

ake — 2021-12-21 22:34:00

ake -> shaos

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

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

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

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-17 18:25:06

ake -> Andrew Lobanov

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

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

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-17 17:29:52

ake -> Andrew Lobanov

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

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

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

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

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

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

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-17 14:58:57

ake -> Ordos

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

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

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

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-17 14:36:50

ake -> hugeping

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

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

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

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

Re: Предложения или "Как нам обустроить idec?"

ake — 2021-12-16 22:43:07

ake -> vvs

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

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

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

Предложения или "Как нам обустроить idec?"

ake — 2021-12-16 20:22:37

ake -> All

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

ake — 2021-12-15 22:36:49

ake -> ake

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

Re: Актуальный нодлист

ake — 2021-12-15 09:42:15

ake -> Andrew Lobanov

{
    "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: gemini:// как дополнение idec

ake — 2021-11-29 21:23:34

ake -> Andrew Lobanov

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

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

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

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

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

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

Re: gemini:// как дополнение idec

ake — 2021-11-17 12:12:06

ake -> Andrew Lobanov

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

ake — 2021-11-16 20:37:24

ake -> Ordos

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

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

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

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

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

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

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

Re: gemini:// как дополнение idec

ake — 2021-11-16 15:42:55

ake -> Ordos

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

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

Re: Анонс станции

ake — 2021-11-15 21:57:49

ake -> Esenin Pavel

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

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

Re: Анонс станции

ake — 2021-07-07 11:42:52

ake -> hugeping

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

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

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

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

Re: Анонс станции

ake — 2021-07-06 21:57:53

ake -> hugeping

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

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

Анонс станции

ake — 2021-07-01 20:48:16

ake -> All

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

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

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

Re: gemini:// как дополнение idec

ake — 2021-03-14 08:48:08

ake -> hugeping

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

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

Re: gemini:// как дополнение idec

ake — 2021-03-13 23:25:04

ake -> hugeping

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

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

Re: gemini:// как дополнение idec

ake — 2021-03-13 19:53:15

ake -> hugeping

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

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

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