shaos> Вот чего я родил

«...А глянешь — мамочка моя! Эт чё? О чём? А набуя?» ©
Не, прочесть-то можно (хотя да, этот код напомнил, почему я пых терпеть не могу), но вот это как раз тот уровень сложности, от которого я стараюсь держаться подальше. Могу в отдельном сабже сделать разбор сего шындевра. Но у меня в ноде такого не будет точно.

shaos> а вот от msgid и далее делать неохота ибо оно криво будет работать т.к. порядок может быть чуть разный на разных нодах...

Такого, кстати, быть не должно.

doesnm> Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)

Да что ж везде одни теоретики... /dev/tcp только для клиентских соединений работает. Сервер сугубо на нём не сделаешь.

tuple> 🙄😬🧒👩‍🚀🙆‍♀️👩‍👦‍👦👩‍👦👒🤷‍♀️👩‍❤️‍💋‍👩🧛‍♀️☝️👻💂‍♀️🤫🍉🍰🥣🥡🍨🍢🏣

А почему не в idec.test?

shaos> Возможно revoltech берёт сообщения Ромы прямо с blcat.ru и отвечает на них через меня

Я сейчас опрашиваю ноды в таком порядке: 1) https://sprinternet.io/iii, 2) https://hugeping.tk, 3) http://ii.blcat.ru, 4) http://idec.spline-online.ru. Соответственно, если его ответов на твоей и у пинга нет, то они выкачиваются и добавляются в локальную базу с ii.blcat.ru.

shaos> а revoltech по-видимому читает сразу всех и часто

Не так уж и часто. У меня фетч чисто в ручном режиме по кнопке на данный момент. Но порядок чтения уже написал.

AL> Всё там же, где он лежит уже чёрт знает сколько лет. Ты же с ним сюда и приходил. Если ты про стандарт ii, то за этим к Роме.

Да я уже запутался. Наверное, про стандарт ii. Короче, про то, что было до ребрендинга в IDEC и появления той доки на гитхабе.

AL> У него должен быть, ведь не может же быть такого, чтобы это великолепие да осталось без описания.

Ну надеюсь. А то если окажется, что вместо описания остался только кривой референсный код, то совсем печаль.

Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.

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

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

Согласен.

ahamai> Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают. А ещё у меня там будет автопереключение транспортов — по одному и тому же порту можно будет запрашивать как HTTP, так и Nex/Gopher. И потом ещё после стандартной реализации IDEC будет сбоку приделан совсем несовместимый с ним протокол, ещё более простой и при этом решающий ровно те же задачи, но куда более красиво, компактно и всего пятью эндпоинтами.

ahamai> Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор.

Не в выводе, а на входе. Это существенная разница.

ahamai> Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату.

А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

ahamai> Единственный вариант, когда там может быть мусор - это СБОЙ.

Или сознательная атака. Если твоя нода при этом будет падать от малейшего чиха, толку от неё мало. У меня вон VPS-ку всякие васяны постоянно по SSH брутить пытаются, судя по логам. И обламываются на корню.

ahamai> то есть, тебя собирается атаковать собственный аплинк.

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

ahamai> кстати, к народному фольклору. какую эху можно посмотреть клиентом но нельзя в большинстве веб-интерфейсов? эху list.txt

А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.

ahamai> Да и пойнт тебе с u/e ничё не сделает.

Без фильтрации айдишников — ой как сделает.

ahamai> а где попасть на сабж? ссылки на http в gopher у меня на том сайте не открываются :(

https://git.luxferre.top/tii/file/README.html

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

ahamai> мне не нравится, когда все фетчат всех

Почему? Это ведь максимизирует надёжность доставки.

tuple> А покажи демку, пожалуйста, как с ним работать в каком-нибудь asciinema. Для наглядности, чтобы не лезть в мануалы. :)

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

Вкратце — создаёшь stations.txt а-ля такого содержания:

https://sprinternet.io/iii 389
https://hugeping.tk 10000
#https://tgistation.ru 12
http://ii.blcat.ru 4238
http://idec.spline-online.ru 380

Запускаешь фетчер: ./tiifetch.tcl
Запускаешь GUI-клиент: ./tiix.tcl

В выпадающем списке эхи, справа фильтр по сообщениям (0 — читать все), ну а дальше, думаю, разберёшься.

revoltech> ну а дальше, думаю, разберёшься.

А, ну да, ещё auth.txt для постинга нужен. Формат тот же: на каждой строке урла станции и пароль через пробел.

ahamai> без контента сеть мертва.

Ну дык инглиш, мазафака, ду ю спик ит? У меня, например, конента сколько угодно, но на более широкую аудиторию в основном за пределами чебурнетов. Внезапно даже мой гофер какую-то обратную связь даёт: со мной на днях связался какой-то пакистанец, нагугливший по совершенно неожиданному поисковому запросу веб-зеркало моего гоферного блога. И в итоге я от него получил материал (пару дампов), необходимый для успешного завершения одного из моих исследований. Сам в шоке до сих пор. Но я к тому, что через ii/IDEC в его нынешнем состоянии он бы на меня не вышел никогда даже с веб-зеркалами. Он только английский, урду и арабский знает.

ahamai> а о чём мы, три с половиной сисопа ещё можем поговорить, и с кем ещё?

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

ahamai> проблемы привлечения к написанию нового софта (как я называл это в 2014, любительское программирование)

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

ahamai> когда с крупного узла запрашиваешь разом все эхи, он сильно задумывается

Раз Шаос тут свой монстрокод кидал, могу и я свой кинуть (правда, это ещё не окончательный вариант, а в репе этого файла пока вообще нет и ещё долго не будет) чисто по обработке /u/e со стандартным слайсингом:

            e {
              set erange [lrange $pathparts 3 end]
              if {[llength $erange] > 0} {
                set limit 0
                set offset 0
                set lastel [lindex $erange end]
                if {[string match *?:?* $lastel]} { # slice detected
                  set sparts [split $lastel :]
                  set offset [expr {int([lindex $sparts 0])}]
                  set limit [expr {int([lindex $sparts 1])}]
                  set erange [lrange $erange 0 end-1]
                }
                # validate the rest of the echo list
                set erange [lmap ename $erange {expr {
                  [validecho $ename] ? $ename : [continue]
                }}]
                if {[llength $erange] > 0} { # recheck length after validation
                  repdata $sock $ishttp [indexechos $dbfile $erange 1 $offset $limit]
                } else {
                  reperror $sock $ishttp "invalid request"
                }
              } else {
                reperror $sock $ishttp "invalid request"
              }
            }

Но это не самое интересное. Самое интересное — процедурка indexechos:

# echo indexer for /e and /u/e
proc indexechos {dbfile echolist includenames offset limit} {
  set rdata {}
  set oquery {ORDER BY `id`}
  if {$limit > 0} { # trigger limiting logic only with positive limit value
    if {$offset >= 0} { # normal limiting flow
      append oquery " ASC LIMIT $offset,$limit"
    } else {
      set reallimit [expr {-$offset}]
      set realoffset [expr {$reallimit - $limit}]
      if {$realoffset >= 0} {
        append oquery " DESC LIMIT $realoffset,$reallimit"
      } else { # invalid limit, falling back to full query
        append oquery " ASC"
      }
    }
  }
  set query {SELECT CONCAT(`echoname`, ':', GROUP_CONCAT(`msgid`,'|' ORDER BY `id`)) AS `rowcat` FROM (}
  foreach echo $echolist {
    append query "SELECT * FROM (SELECT `id`, `msgid`, `echoname` FROM `msg` WHERE `echoname` = '$echo' $oquery) UNION ALL "
  }
  append query {SELECT NULL,NULL,NULL) GROUP BY `echoname` ORDER BY `echoname` ASC;}
  sqlite3 db $dbfile -readonly true
  db eval $query echorow {
    if {$echorow(rowcat) ne ""} {
      set eparts [split $echorow(rowcat) :]
      set ename [lindex $eparts 0]
      if {$ename ne ""} {
        if {$includenames > 0} {
          append rdata $ename \n
        }
        append rdata [join [split [lindex $eparts 1] "|"] \n] \n
      }
    }
  }
  db close
  return $rdata
}

Вот и с чего бы такой обработчик долго задумывался, если он все эхи (после валидации) в один проход запрашивает?

shaos> Ну тут у тебя SQLite по ходу? Это читерство ;)

Да, он самый, как и на клиенте. Меня групконкат спасал ещё на мускуле в бытность вебдевом (период моей жизни, в который я не хочу даже в воспоминаниях возвращаться), выручит и теперь. Очень мощная вещь. И из того же периода я вспомнил трюк с долбаными юнионами, кстати.

shaos> Настоящие пацаны БД на текстовых файлах держат ;)

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

ahamai> причём здесь обработчик. я про нагрузку на сервер, когда с него опрашивают сразу все эхи разом.

Ну приведённый мной обработчик реагирует на запрос всех эх разом ровно так же, как и на запрос одной: формирует составной SQL-запрос с учётом срезов (если есть) и запрашивает инфу в базе. Откуда здесь дополнительная нагрузка на сам сервер возьмётся? Просто вложенных селектов будет больше, да. Но это уже проблема базы, хотя скулайт такие вещи обрабатывает крайне шустро. Не те объёмы, чтобы париться.

ahamai> и мне неинтересно болтать по английски.

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

ahamai> мне интересно по-фидошному :)

Что даёт фидошность? Широкие массы вот это понимают: есть проблема — есть исходящая из неё задача — есть решение. Здесь же какая задача для решения какой проблемы решается? Вот и донеси это до людей, если знаешь ответ на этот вопрос.

Для меня, например, ii/IDEC решает задачу цензуроустойчивости и распределённости при сохранении доступного и легковесного протокола. Поэтому я бы хотел его видеть вместо всяких форумов, мейлинглистов и прочих гуглогрупп как минимум. Везде. На всех языках. Хотя бы в нынешнем виде.

ahamai> раньше хоть малое сообщество было, сейчас вообще сверхмалое

Ну с таким подходом неудивительно.

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

Так это следствие мною указанного неосиляторства.

ahamai> нет инфраструктуры для заинтересовывания пользователей

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

hugeping> У меня появилась ГИПОТЕЗА.
hugeping>
hugeping> 1) revoltech фетчит себе куда-то локально эхи из разных мест
hugeping> 2) revoltech сфетчил сообщение ahamai с ноды blcat
hugeping> 3) revoltech формирует в своём клиенте ответ на сообщение и отправляет его spnet. reply указывает на сообщение с blcat
hugeping> 4) spnet НЕ ПРОВЕРЯЕТ reply вообще и берет это сообщение (считаю, должен был отбросить)
hugeping> 5) ЗАТЕМ spnet забирает сообщение на которое был ответ с blcat
hugeping>
hugeping> Это всё объясняет. revoltech? shaos? я прав?

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

Нода почти готова (на первое время будет с регистрацией вручную), но /u/push пока решил не реализовывать. У меня вообще нода от клиента структурно отличается только парой новых таблиц в скулайте, которые на клиенте не используются — для авторизации и публичного списка эх.

Существуют ли какие-то реальные юзкейсы у /u/push?

AL> У нас столько эх нет, чтобы оно тормозило.

«Нет? Будут!» © Операция Ы/Напарник

Другое дело, что при запросе именно большого количества эх в /u/e можно опять уткнуться в тот же лимит на GET-запросы, что и в /u/m. Надо бы подумать, что с этим делать. Теоретически длина имени в эхе может быть и 120 символов, дык что, максимум |8000/121| = 66 эх за раз запрашивать?

ahamai> Юпуш вообще для закидывание на 10 бесплатных хостингов и резервирования на них

А что, по старинке скрипт + файлик с базой закидывать — уже не вариант, обязательно нужно какое-то хитровыдуманное апи для этого?

Нет, я правда не понимаю, какие реальные задачи это решает.

AL> revoltech> Существуют ли какие-то реальные юзкейсы у /u/push?
AL>
AL> Да.

Борода. Какие, например?

И что должно произойти, если не у всех сообщений в бандле будет то же самое имя эхи, что и в поле echoarea? Зачем там это поле вообще нужно?

AL> Например, узел в изолированной сети без внешнего адреса.

Если сеть действительно изолирована, оттуда и пуш не пройдёт. В противном случае gsocket, zerotier и прочее решают.

AL> А где в бандле имя эхи, если не в поле сообщений?

В каждом сообщении в одном из полей (строчка номер два) есть имя эхи. Что произойдёт, если в поле echoarea в POST /u/push будет указана не та эха, что в теле сообщения в бандле? Что должно произойти?

1) Такое сообщение отбросится?
2) Содержимое поля echoarea в POST-запросе проигнорируется?
3) Сообщение перепостится и туда, и туда?

doesnm> 4. В эхе указанной в push будут сообщения как будто из другой эхи

Ни хрена в этом случае не понял. Связь msgid и эхи однозначна. Что значит «как будто из другой эхи»? Это либо перепост с новым айдишником (пункт 3), либо дублирование айдишника, что ломает вообще всю логику ноды.

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

2 AL: спасибо за прояснение ситуации. Сделаю вскоре у себя /u/push без поля echoarea в посте. Также абсолютно согласен с тем, что возможность всех поинтов фетчить со всех нод — краеугольный камень распределённости и поэтому ситуация с ещё несуществующим где-то айдишником в repto вполне штатна. У меня нода (которая ещё в разработке) щас проверяет только то, что там стоит корректно сформированнный msgid (20 символов, латиница, цифры), но не его существование в базе.

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

2 ping: кроме «скатертью дорога», комментировать здесь особо и нечего. Хотя можно вспомнить, как и почему Gab отделился от остального мастодона...

2 ahamai & shaos: ну блин, это ж не форум. Вообще не форум. То, что кто-то делает визуализацию эх в виде форума, не делает их форумом. В моём клиенте, например, выбирается эха и при нажатии Read messages отображается просто лента сообщений. Subj помогает понять, к какой части этой ленты что относится, но это настолько же незначимое поле, как и repto. Потому какие ещё topicid?

В принципе, да, механизм тегов сейчас недоиспользован. Туда можно ещё что-то набросать. Просто не надо это делать чем-то обязательным и уж тем более привязывать базовую логику к визуальщине. Рендеринг тех же списков рассылки и без костылей в виде topicid прекрасно работает, сугубо на сабжах с «Re:».

shaos> я думаю пользователю надо в руки руль, которым он будет выбирать как он хочет видеть сообщения - единым фидом, фидами по эхам, форумом по сабжам или вообще древовидными тредами (я это обязательно поддержу в обозримом будущем)

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

shaos> и topicid никому не мешает - не хочешь собирать сообщения в тему - игнорируй его :)

Хочешь собирать сообщения в тему — есть поле subj. Так испокон веков мейлинг-листы визуализировались. Первое сообщение треда — сабж без Re:, а далее он же, но перед ним Re: стоит. Зачем велосипедировать на пустом месте?

shaos> погляди в режим форума на tgi
shaos>
shaos> https://tgistation.ru/echo/8/
shaos>
shaos> он собирает по сабжам - например он собрал в одну тему сообщения со следующими сабжами

Так это просто кривая реализация. Кривейшая, если она разбрасывает по отдельным словам, а не по всему содержимому поля subj целиком.

Можно ведь и нормально сделать.

shaos> тогда ты соберёшь сообщения test и Re: test из 2024 года вместе с test и Re: test из 2018 :)

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

shaos> Эвристики

Много лет на сабжах и таймштампах всё работало, а тут внезапно это что-то сложное.

shaos> По мне так repto и topicid попроще будет :)

Зачем сюда repto вообще приплетать? Что мешает ответом на сообщение из одной темы начинать другую, просто поменяв поле сабжа?

ahamai> Зачем столько сложного разбора, если можно использовать простой тэг.

В этом разборе ничего сложного нет. Вообще. Не сложнее отображения содержимого /u/e, если уж на то пошло.

shaos> Ничего не мешает - просто технически оно войдёт в старую цепочку :)

А зачем оно в старой цепочке, если тема новая?

ahamai> и я помню, как работал фидошный софт по сабжам. кривые ветки были.

Так это проблема того софта. Все стандарты и протоколы начинают скатываться в УГ именно тогда, когда их начинают затачивать под криворукеров.

ahamai> чем полагаться на ненадёжные источники (тема может быть изменена, могут быть одинаковые темы).

На форумах это ненадёжный источник, да. Здесь же тема изменена быть не может. Зачем форумную логику сюда приплетать?

AL> Сабж. Я тут размышлял над IDEC и её возможностями и пришёл к выводу, что ни IDEC, ни ii нежизнеспособны. Пожалуй, я сворачиваюсь. Таверну я на днях погашу. Разработку нового софта останавливаю.
AL>
AL> Всем удачи.

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

2 shaos: надо что-то делать, я постараюсь в течение недели допилить и где-то стартануть свою ноду. И на ноде же выложить документацию на общепонятном миру языке.

shaos> А вот это кто такой на Go появился из Ижевска? :)
shaos> ====
shaos> 217.114.158.151 - - [12/Nov/2024:18:00:04 -0800] "GET /iii-point.php?q=/x/features HTTP/1.1" 200 4041 "-" "Go-http-client/1.1"
shaos> 217.114.158.151 - - [12/Nov/2024:18:00:04 -0800] "GET /iii-point.php?q=/list.txt HTTP/1.1" 200 1370 "-" "Go-http-client/1.1"
shaos> 217.114.158.151 - - [12/Nov/2024:18:00:04 -0800] "GET /iii-point.php?q=/u/e/iii.nizya/-1:1 HTTP/1.1" 200 202 "-" "Go-http-client/1.1"
shaos> ====
shaos>

А кто сказал, что там нода?

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

shaos> Вроде судя по старым перепискам идея с бонами в сети IDEC не прижилась - ведь каждый сисоп хочет иметь свой набор эх (т.к. каждый имеет свои приоритеты)

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

Другое дело — если вводить бон, то, например, idec.talks по идее должна перекочевать в ru.idec.talks, ну ты понял.

shaos> Да я уже вроде всё слил, что хотел - могу выложить database2 ;)

Если не сложно, выложи, пжлст.

ahamai> Вопрос: кто щас расставляет topicid?

Даже не планирую.

ahamai> А у тебя уже есть станция?

До конца месяца будет, если без форс-мажоров.

Вот думаю, а не прикрутить ли TOTP к ещё не запущенному tiid? Мне это было бы интереснее реализовать даже больше, чем долбаный /u/push.

Как это будет работать? А вот так: будет динамический auth_string. При регистрации будет выдаваться долговременный ключ, который надо будет вбить в какой-нибудь оффлайновый TOTP-клиент (под ПК — тысячи их, под андроид рекомендую Aegis, под мобилы постарее — TOTP ME: https://github.com/kwart/totp-me). Ну и всё, вводим новый код каждые полминуты в качестве auth_string. Во избежание возможных коллизий, правда, нужно будет в auth_string к коду прибавлять юзернейм, а-ля revoltech:012345. Свой клиент (как минимум tiix и tiipost) тоже адаптирую под это дело.

Ну и сделаю это всё, наверное, опциональным: кто хочет, сможет и по статическому паролю постить.

shaos> Каждый раз код вводить это неудобно

Только для тех, кто постит в режиме чата. :)

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

Может, в поле адреса нода будет ещё и добавлять какую-то ЭЦП от себя, исходя из текста сообщения?

foxears> Можно в тэги сообщения добавлять хэш от usernme+authstring или что-то такое.

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

shaos> Хотелось бы, чтобы юзеры стали глобальными - чтобы могли писать в сеть откуда угодно, а не только с той ноды, где они поинты

Ну тогда тем более keys.txt становится важен. А вот к мылу привязываться — так себе идея. Сейчас вообще не очень тот концепт, что сисоп даёт юзеру authstr. Наверное, куда лучше, чтобы юзер сгенерил у себя пару ключей и отправил публичный сисопу. Ну и про постинге, соответственно, подписывал сообщение приватным и отправлял подпись в качестве auth_string.

shaos> Емейл будет нужен для замены скомпрометированного публичного ключа, если пользователь хочет продолжать писать под тем же самым именем. Также наличие подтверждения через другой канал (е-мейл) поможет избежать ситуации, когда некто на новой станции скажет, что он теперь shaos и будет писать везде вместо меня подписываясь своим новым ключом который ко мне не имеет никакого отношения :)


А как без общей между всеми нодами базы ключей некто на новой станции не сможет провернуть такое же с новым мылом?
И обратно: а что делать, если скомпрометирован не ключ, а мыло? Или вообще оба сразу? И как тебе с новым мылом и новым ключом доказать сисопу, что ты — это ты?

Ладно, я пока решил, что запущу ноду без TOTP, без подписей, без авторега и без /u/push. Осталось только несколько организационных моментов порешать. К 1 декабря, думаю, будет готово.

Может, придумать какой-нибудь механизм, позволяющий найти доселе неизвестные ноды? Ну, чтобы, например, человек мог запостить адрес ноды координатору, он в автоматическом режиме проверил, что по этому адресу действительно сервачится ii-протокол (/list.txt, /u/e, вот это вот всё) и опубликовал его в свой список. А другие могли найти эту ноду на странице этого координатора (например, /stations.txt), не шастая по непонятно каким ресурсам.

shaos> Я много раз предлагал node.json
shaos>
shaos> https://sprinternet.io/node.json
shaos>
shaos> Там описывается что прописывать в клиентов для фетча и с каких нод оно берёт эхи и как часто

Вот только JSON must die.