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

Тогда правда наша сеть превратится в эдакий распределённый двач и потонет в море треша…

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

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

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

point.py. потом был целый квест, где надо было убежать из лап интернета в ii :) и только потом приделал простую регистрацию. приделал, даже не проверив, как она работает :) для нас приход нового юзера уже праздник.

Ненадо регцентры - зачем регцентры? У нас децентрализованная структура - каждый сисоп работает как регцентр :)

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

> А когда все пишут со всех, то непонятно чей вообще пойнт и с кого вообще спрашивать.

Ну эту идеологию можно оставить - пользователь изначально регается на какой-то ноде и её сисоп за него как бы «отвечает», однако пользователь генерирует пару секретный ключ / открытый ключ, публикует свой открытый коюч через своего сисопа и начинает писать откуда угодно, однако если он накосчил, то его сисоп отзывает его открытый ключ (всё это делается через специальную эху) и юзер теряет способность писать откуда угодно - в общем как-то так…

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

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

А всё - нашёл. Ну главное что сам хэш тот же:

def hsh(s,l=20):
    a = base64.urlsafe_b64encode(hashlib.sha256(s).digest())
    a = a.decode('utf-8')
    a = a.replace('-', 'A').replace('_', 'z')[:l]
    return a

По идее это у меня может пойти в категорию KINDA и подсветится жёлтым цветом как частично сходящееся...

ahamai> point.py. потом был целый квест, где надо было убежать из лап интернета в ii :) и только потом приделал простую регистрацию. приделал, даже не проверив, как она работает :) для нас приход нового юзера уже праздник.

Где можно найти этот квест? Интересно почитать

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

ahamai> Спецификация, в смысле. В сети кризис контента а не кризис безопасности. И я не понимаю смысла цепляться за ценность аккаунта, я даже когда имя меняю, всем понятно, что это я пишу.

Да. А еще для ключей нужна криптография. И это сразу опустит порог вхождения в написание клиента/сервера и список поддерживаемых машин (тут же есть любители писать с старых компов xD)

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

Думаю, уже нигде.

Я планирую написать поддержку ключей Ed25519 в кодах i8080A (с возможностью работы на Z80), но начну с хешей RIPEMD-160 и аутентификации HMAC-RIPEMD-160-96 - это всё будет основой моей сети ретромашин Sprinternet, за транспорт в которой будет отвечать протокол ii :)

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

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

Я много раз предлагал node.json

https://sprinternet.io/node.json

Там описывается что прописывать в клиентов для фетча и с каких нод оно берёт эхи и как часто

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

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

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

Поместил в чёрный список у себя:

24Xw9nsjvT2hm9gkBsXA
245llSgDdz3A7excreyy
24YAW8JCCC7NEqEpQkBw
24uelcnvUDNl2hnWzidU
24Oz1A72GzRCl8fDNghq
24327ZxAyX49cJHtDDor
24O1nCfU9UzCtnsnpkbM
24ZrIxeup1gAOARJICWz
24eO5NuTdCxsHrMQPcTA
24xcZUEoAqxQL46Mzh78
24LlK2C3OHSIdAIMGNoA
242AhxwwBojqLCUJLFO2
24GJCodjSWFrsp6geJiw
24cqro688HyaUu5ANu8c

Это в какой эхе?

Другого способа представлять разношерстные данные (которые не укладываются в одну таблицу) в текстовом виде нет - скажи спасибо, что не XML :)

Ну вот он даёт имя сервера, а автомат вытягивает node.json оттуда с именем ноды, роутингом и т.д. и встраивает ноду в общую топологию сети :)

lor.opennet

А понятно - я её обратно не забираю - по идее она у меня read-only (пока только административно), поэтому у меня всё чисто.

P.S. Ну теперь когда проблема контента решена пора начинать решать проблемы безопасности :)

foxears> lor.opennet

А почему туда вообще разрешена запись (вопрос к ahamai)? На картинке просто кот кстати

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

А почему туда нельзя писать, кстати? Как и в любую другую эху? Чёт я такого в фидо не припомню :)

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

у node.json формат кривой, не даёт использовать дополнительные поля. нахрена массив вместо словаря? почему нельзя продумать на предмет дополнительных полей? уж проще нормально plain text спроектировать.

Это так мило :) Ну это не то, что 27000 сообщений в 2014. Удалять я это не буду, в масштабах автогенерируемой эхи это вообще не заметно. Но прикольно.

В эху spnet.uplink? Заодно и познакомимся

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

Ну каждая нода имеете node.json а затем кто-то их забирает по цепочке начав с какой-то одной ноды и строит nodelist - вроде всё прозрачно :)

Ну человек типа архивную ноду поднял где фетчит всё со всех - что в этом плохого?

Да у нас как-то не принято в ботоэхи писать…

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

ну для архива и такое сохранить не жалко. это мило :)

Ну ты же забанил этого милого человека или пусть и дальше развлекается? ;)

ahamai> В эху spnet.uplink? Заодно и познакомимся

Чтобы писать в эху spnet.uplink, надо уже быть поинтом. Я же предлагаю автокоординатор. Куда можно будет (не являясь ничьим поинтом!) в автоматическом режиме постить урлы, а он проверяет, являются ли эти урлы валидной нодой, и добавляет их в список, откуда другие мимокрокодилы могут о твоей станции вообще узнать.

shaos> Ну каждая нода имеете node.json а затем кто-то их забирает по цепочке начав с какой-то одной ноды и строит nodelist - вроде всё прозрачно :)

Не, я вообще не о том.

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

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

Например мой "автокоординатор" это spnet.stats - я именно там заметил траффик от foxears.su ещё до того, как автор той ноды мне е-мейл написал ;)

> зачем так сложно? Для автоматической проверки того, что запощенная урла является нодой, достаточно пройтись по /list.txt, /e и /u/e без слайсов.

И как ты оттуда узнаешь имя ноды и кого она фетчит?

Теперь о том, как автодискавери можно реализовать технически без завязки на внешний мир типа почт или форумов. Чисто один из вариантов.

1. Ноды, которые соглашаются на роль автокоординатора, открывают специальную эху node.list и специального пользователя с auth-строкой nodediscovery, который может писать только в эту эху.
2. При постинге в эту спецэху те ноды, согласившиеся на роль автокоординатора, обязаны валидировать поступающие URL на предмет наличия API /list.txt, /e и /u/e с проверкой доступности первой попавшейся в list.txt эхи. Все посты, которые не проходят валидацию, не должны попадать в спецэху.
3. Если конкретный URL уже был запощен в спецэху, валидацию он также не проходит.
4. Эха node.list синхронизируется между всеми узлами так же, как и все остальные (idec.talks, например).
5. Обычные поинты читают эту эху и находят новые для себя станции.

shaos> И как ты оттуда узнаешь имя ноды

А зачем? Имя ноды — вообще понятие эфемерное. Оно появляется только тогда, когда через ноду кто-то пишет. Для дискавери важна только урла.

shaos> и кого она фетчит?

Это интересует сисопов, а не юзеров, ищущих, кого бы ещё почитать.

shaos> Например мой "автокоординатор" это spnet.stats - я именно там заметил траффик от foxears.su ещё до того, как автор той ноды мне е-мейл написал ;)

Мы опять о разных вещах говорим. Поставь себя на место человека, который не может/не хочет регистрироваться ни через веб, ни через другие внешние каналы. Что ему делать? Создавать свою ноду. Как ему дать знать о её существовании другим участникам сети, не упираясь в поиск внешних контактов и языковой барьер, допустим? Статистика трафика — не аргумент, нода может вообще в .onion находиться, по трафику её не найдёшь.

Без фичи автокоординатора сеть не самодостаточна, вот что я хочу донести.

1. Это надо создавать узлы с разными правами пользователей - пока таких в природе не существует

P.S. А как это Re: Автодискавери, но без repto?

shaos> 1. Это надо создавать узлы с разными правами пользователей - пока таких в природе не существует

Блэт, серьёзно? Я один до поля acl в таблице auth додумался?..

2. Я вручную поле на All поменял.

revoltech> Теперь о том, как автодискавери можно реализовать технически без завязки на внешний мир типа почт или форумов. Чисто один из вариантов.

Это все хорошо, но что будет если через автодискавери попадет вредоносная нода которая будет подделывать сообщения? Что-то подобное в yarn уже было: https://lyse.isobeef.org/tmp/burglary.png (первое сообщение подделано)

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

> Я один до поля acl в таблице auth додумался?..

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

shaos> Это чего такое? Надо же чтобы в разных эхах разные права были

Это как раз оно самое. Если пустая строка — ноль прав, если * — можно постить во все эхи, если список эх через запятую — разрешённые эхи для постинга. Всё.

doesnm> Это все хорошо, но что будет если через автодискавери попадет вредоносная нода которая будет подделывать сообщения?

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

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

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

Да, а что в этом сложного? Один UPDATE-запрос с CONCAT.

Вручную? ;)

shaos> Вручную? ;)

Какая разница, скриптом или вручную? Запрос-то всё равно один, независимо от количества таких пользователей.

А что, если вообще оставить только /list.txt, (опционально) /blacklist.txt, /e, /m и /u/point? Тогда всё, кроме постинга, ложилось бы на физическую файловую структуру и его можно было бы сервачить хоть статикой.

revoltech> А что, если вообще оставить только /list.txt, (опционально) /blacklist.txt, /e, /m и /u/point? Тогда всё, кроме постинга, ложилось бы на физическую файловую структуру и его можно было бы сервачить хоть статикой.

Звучит прикольно, но очень неоптимизированно. Я тут хотел сделать конвертер который создаст эху с 37к+ сообщениями. Насколько долго будет получать индекс и сообщения?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Звучит прикольно, но очень неоптимизированно. Я тут хотел сделать конвертер который создаст эху с 37к+ сообщениями. Насколько долго будет получать индекс и сообщения?

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

Условно, алгоритм таков: выкачали индекс из /e/echo.name, сравнили с локальным содержимым того же файла, недостающие айдишники в цикле скормили /m, после успешного выкачивания перезаписали локальный индекс эхи.

revoltech> В первый раз будет долго (хотя зависит от канала у ноды и клиента), потом быстро. Мы же не перекачиваем вообще все сообщения каждый раз, а только те, которых не оказалось на клиенте.
revoltech> Условно, алгоритм таков: выкачали индекс из /e/echo.name, сравнили с локальным содержимым того же файла, недостающие айдишники в цикле скормили /m, после успешного выкачивания перезаписали локальный индекс эхи.

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

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Мы не перекачиваем сообщения, но мы перекачиваем индекс. Сколько он будет весить с без адаптивного фетча?

777к. Если по HTTP с gzip, то гораздо меньше. Надо тестить.

doesnm>> Мы не перекачиваем сообщения, но мы перекачиваем индекс. Сколько он будет весить с без адаптивного фетча?
revoltech> 777к. Если по HTTP с gzip, то гораздо меньше. Надо тестить.

Что еще прикольно: это идеально ложится на тип базы txt (так и задумано изначально?)
Так что можно использовать утилиты из ii-db-utils и прочее

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Что еще прикольно: это идеально ложится на тип базы txt (так и задумано изначально?)
doesnm> Так что можно использовать утилиты из ii-db-utils и прочее

В глаза не видел этих утилит, но да, я ж говорю, если оставить только /list.txt, /e и /m, то всё можно сервачить статикой. А динамической только логику постинга через /u/point сделать.

revoltech> В глаза не видел этих утилит, но да, я ж говорю, если оставить только /list.txt, /e и /m, то всё можно сервачить статикой. А динамической только логику постинга через /u/point сделать.

Я про эти утилиты: https://github.com/idec-net/ii-db-utils
Тут даже есть скрипт чтобы конвертировать почту в ii формат

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

revoltech> В глаза не видел этих утилит, но да, я ж говорю, если оставить только /list.txt, /e и /m, то всё можно сервачить статикой. А динамической только логику постинга через /u/point сделать.

Либо если упороться, то кидать сообщения через rsync по ssh немного переделав https://github.com/idec-net/iissh
Кто сказал что мы обязаны постить только через /u/point ?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

/z а затем и /u был введён потому что по одному слишком медленно было

А изначально и было только e и m

ahamai> /z а затем и /u был введён потому что по одному слишком медленно было

Но при этом зачем-то ограничиваем количество айдишников в /u/m.

> Но при этом зачем-то ограничиваем количество айдишников в /u/m.

я уже объяснял. это принцип разумной достаточности

1. разница между 1 и 20 в 2014 была ощутима, а между 20 и 40 - нет

2. большой запрос ставил колом однопоточный сервер

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

Мой вариант.
1. Станция которая хочет заявить о себе миру делает GET-запрос вида /d/url-to-node/url-encoded-name-of-node на любую известную станцию, второй параметр не обязателен.
2. Станция получившая запрос проверяет что такой url ей не известен
3. Станция проверяет что по адресу из запроса действительно ii-нода
4. Станция добавляет ноду в /nodes.txt
5. Станция добавляет сообщение в эху node.list

Другая станция забирает /nodes.txt после чего повторяет пункты 2-5.

Основой распространия списка становится /nodes.txt. Эха node.list является локальной для каждой станции и не подлежит распространению.

Далее каждая станция раз в сутки проходит по списку нод из /nodes.txt и проверяет доступность (пункт 3), если проверка проваливается 7 раз, т.е. нода не доспутна неделю, то нода из списка маскируется, сообщение в эхе node.list вносится в чёрный список, т.е. новички эту ноду не увидят. В дальнейшем можно наверное раз в месяц просто удалять все замаскированные ноды из списка вместе с сообщениями из node.list

Примерный форман /nodes.txt
url:name
-masked-url:name

урла должно быть два - пойнтовый и веб-интерфейс (если есть)

Я как-то не заметил, а оно ведь сюда аж добежало :)

w21pZ4TPwJz36i5hR5bD

> урла должно быть два - пойнтовый и веб-интерфейс (если есть)

сейчас вроде бы у всех эти 2 урла одинаковые (даже у меня)

У тебя же как-раз разные iii-web.php и iii-point.php
Из-за этого не сразу понял как с тебя сообщения забирать.

Теперь и то, и другое у меня https://sprinternet.io/iii/
Если ввести в браузере без параметров, то оно само перескочит на iii-web.php
А если добить урл параметрами (типа /u/e/ и т.д.), то оно через Rewrite модуль апача перевызовет внутри iii-point.php?q=/хвост (но снаружи оно так и останется /iii/u/e/...)

Надо чтоли какие-то StickyNotes справа от списка эх разместить с инструкциями как к ноде подключаться и что это вообще такое...

Сделал на скорую руку первый этап автодискавери.
Запрос вида /d/$SHEME/url или /d/$SHEME/url/node%20name, где $SHEME = http или https, добавляет строку в nodes.txt после проверки что url это ii-сервер (проверяется наличие list.txt, /u/e/ и /u/m/). Ответ может быть 200 - строка добавлена, 304 - станция уже в списке, 404 - сервер не ii. nodes.txt содержит url и опционально имя, разделённые табом. Парсинг чужих nodes.txt пока не реализован, как и создание сообщений в эхе, и автоудаление отвалившихся.

curl https://idec.foxears.su/nodes.txt
https://club.hugeping.ru
https://tgistation.ru tgistation

У меня имя просто spnet :)

Не вопрос, поправил.

Произошло чудо - я восстановил свою учётную запись на лоре :)

https://www.linux.org.ru/news/internet/17797879?cid=17801681

Последняя моя активность там была в августе 2009 года ;)

tgistation.ru это tgi
hugeping.tk это ping
(судя по заголовкам в генерируемых ими сообщениях)

А самое старое обсуждение моего софта на лоре случилось в ноябре 2002 года (т.е. 22 года назад) с подачи господина cr0acker-a :)

https://www.linux.org.ru/gallery/screenshots/244277

попали в топ10 месяца по лору, сейчас 8е место

ahamai, ты вроде просил на лоре бинарник IDEC Droid? Я однажды собирал успешно под Termux ибо оно на чистой Java, успешно работало
Могу попробовать еще раз и выложить

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

Один товарищ ставил IDEC Mobile на свой ондроед в 2022 году - работало с моей нодой на ура - и чтение, и отправка сообщений. Откуда брал бинарь не помню, но исходники вот тут:

https://github.com/idec-net/idec-mobile

shaos> Один товарищ ставил IDEC Mobile на свой ондроед в 2022 году - работало с моей нодой на ура - и чтение, и отправка сообщений. Откуда брал бинарь не помню, но исходники вот тут:
shaos> https://github.com/idec-net/idec-mobile

Пробую собрать, возникли проблемы с зависимостями:
org.sufficientlysecure:openpgp-api:12.0.
com.takisoft.fix:preference-v7:28.0.0.0.

Мб где-то найду их. Хотя вроде бы где-то в idec.talks лежала ссылка на IDEC Droid от Лобанова

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

Вебархив показывает вот тут линк на некий app-debug.apk, который не сохранился:

https://web.archive.org/web/20211130114237/ https://ii-net.tk/idec-doc/?p=android

doesnm> Мб где-то найду их. Хотя вроде бы где-то в idec.talks лежала ссылка на IDEC Droid от Лобанова

И так что мы имеем:
1. Первая зависимость есть только на репозиториях Spring (судя по mvnrepository.com), а они закрыли их basic auth
2. Вторая зависимость как бы есть на Github, но в логах CI от jitpack.io ошибки сборки, а на Maven Central этот пакет убрали (как и похоже первый)

Как же я ненавижу зависимости, даешь велосипеды

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> shaos> Один товарищ ставил IDEC Mobile на свой ондроед в 2022 году - работало с моей нодой на ура - и чтение, и отправка сообщений. Откуда брал бинарь не помню, но исходники вот тут:
doesnm> shaos> https://github.com/idec-net/idec-mobile
doesnm>
doesnm> Пробую собрать, возникли проблемы с зависимостями:
doesnm> org.sufficientlysecure:openpgp-api:12.0.
doesnm> com.takisoft.fix:preference-v7:28.0.0.0.

Вопрос, нахрена обе зависимости в настолько простом клиенте?

Блин, хоть бери и свой пиши... Хотя я хочу как-нибудь на Hecl запилить, как микроб хотел в 2014. Его можно будет и на симбиане моём пускать, и на андроидах старых. Хотя на них и полноценный тикль в виде AndroWish имеется.

P.S. Shaos, ты с меня фетчишь уже или нет? Ну, то есть, могу ли я со своей ноды уже начинать писать?

> Shaos, ты с меня фетчишь уже или нет? Ну, то есть, могу ли я со своей ноды уже начинать писать?

а уже можно? ну ок - завтра настрою :)

revoltech> Блин, хоть бери и свой пиши... Хотя я хочу как-нибудь на Hecl запилить, как микроб хотел в 2014. Его можно будет и на симбиане моём пускать, и на андроидах старых. Хотя на них и полноценный тикль в виде AndroWish имеется.

А на новых? (Хотя учитывая как часто выходят версии, то уже не особо)
Пишу с Android 10 в Termux через Caesium

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> А на новых? (Хотя учитывая как часто выходят версии, то уже не особо)

Ну у меня только графен щас в ходу, так что тестить, если что, придётся на 15...

вроде сделал - пробуй

shaos> вроде сделал - пробуй

Ну что, мея должо быть видо.

ВИДО

shaos> ВИДО

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

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

Если кому интересно фетчить с моей новой ноды, то вот урла: https://ii.yester.link

Альтернативно можно стягивать по plain HTTP: http://ii.yester.link:1110
По Nex/Gopher урла ровно такая же (сервер мультипротоколен).

Нода пока довольно экспериментальна и новых поинтов не принимает, но до нового года это по идее изменится.

Помимо существующих эх, там будет ещё англоязычный контент в основном. Фетчу избирательно с spnet и foxears.

Добавил тебя в список фетча и в /nodes.txt

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

Выздоравливай

Новости с полей - https://github.com/ptah-alexs/nl-tool