FEDAnet siteWed Nov 20 11:48:38 2024 UTC Наконец-то сподобился поднять сайт для FEDAnet. Сейчас он доступен как http://feda.croco.net и как http://fedanet.croco.net, не знаю, что лучше :-) Кто собирается когда-нибудь запускать свою ноду, можете начинать генерацию ключа для неё, тарбол исходников генератора дают здесь: http://feda.croco.net/download/. Собственно, больше там пока что ничего и не дают, увы. |
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошкова |
☞ From Anonymous from network, which should not be named (unverified) Fri Nov 29 11:51:02 2024 UTC
Для анонимных нод будет запутывание трафика?
Для анонимных нод будет запутывание трафика? Чтобы поинты при подключении к узлу и узлы при подключении к другим узлам могли не указывать нигде свой реальный IP, а строить туннели через другие узлы сети никому не ведомым образом (т.е. чтобы не было ни одного узла, который знает полностью весь маршрут туннеля).
ответить
From Andrey V. Stolyarov Fri Nov 29 12:45:04 2024 UTC
Re: Для анонимных нод будет запутывание трафика?
На первую версию этого не планируется. На одну из последующих версий планируется организовывать связь между нодами из одной страны через ноды в других странах. Совсем "луковичной" маршрутизации я пока не планировал делать, хотя в будущем такое возможно.
Тут дело в чём, всякие tor'ы опираются на бескорыстных фанатиков, просто так отдающих свой трафик и прочие ресурсы на нужды сети. Для FEDAnet я предполагаю другой подход: хоббисты, обладающие соответствующими ресурсами, отдают их другим, но не кому попало, а своим друзьям, которых они лично знают. Релеинг через ноды в другой стране возможен по договорённостями между нодами, в том числе на уровне протокола (типа, ты как насчёт пофорвардить мои пакетики, а я пофорваржу твои), но вот делать как в том же торе три "луковичных" слоя, и чтобы промежуточные релеи не знали, кого и куда они форвардят — это я в сочетании с договорённостями (в отличие от бескорыстного фанатизма) технически себе представить не могу.
ответить
From Parthen (unverified) Fri Nov 29 15:20:22 2024 UTC
Re: Re: Для анонимных нод будет запутывание трафика?
Т.е. это вообще не даркнет в привычном понимании? Люди из трех букв смогут отследить кто там и что написал?
ответить
From Andrey V. Stolyarov Fri Nov 29 16:01:24 2024 UTC
Re: Для анонимных нод будет запутывание трафика?
Ну, теоретически они в любой даркнет могут проникнуть достаточно глубоко, чтобы начать собирать информацию.
А так — для внешнего наблюдателя трафик будет выглядеть как UDP-пакеты с содержимым, похожим на прочитанное из /dev/random (не скажу, что прямо неотличимое от, но похожее). В первой версии будет возможность, сгенерив ключик достаточного ранга, под видом добропорядочной ноды начать устанавливать ассоциации с другими нодами и тем самым собирать сведения, какая нода где (за каким адресом/портом) когда сидела. В более поздних версиях такие сведения можно будет получить только о нодах, находящихся в других странах. Ну и плюс к тому я возлагаю определённые надежды на то, что провайдеры обычно не ведут логов отдельных соединений через их NAT, поскольку это тупо никаких объёмов не хватит для хранения таких логов; это означает, что, как только в очередном NAT-box'е протухла очередная ассоциация, уже никто не сможет сказать, кто изнутри данной сети эту ассоциацию использовал.
ответить
From Parthen (unverified) Fri Nov 29 16:43:23 2024 UTC
Тогда еще пару вопросов
1) Что-то в виде веба предполагается? Или пока еще рано об это думать?
2) Как вот это "в других странах" будет обнаруживаться? Просто сами админы будут локацию указывать?
ответить
From Andrey V. Stolyarov Fri Nov 29 18:00:34 2024 UTC
Re: Тогда еще пару вопросов
> 1) Что-то в виде веба предполагается?
Да можно и просто веб, если есть IP-адреса, то почему на них HTTP не запустить. Вопрос скорее в том, как организовать доменные имена. Ну то есть псевдо-TLD вроде того же .feda — это понятно, и даже имена вроде 49feb618794a8e1e4439.feda (где 49feb618794a8e1e4439 — nodeID) — ну, это тоже понятно, но хочется и чего-то более мнемоничного, но при этом чтобы не возникало никаких центров.
> 2) Как вот это "в других странах" будет обнаруживаться? Просто сами админы будут локацию указывать?
Я думаю, что самим node-мастерам будет предоставлена возможность указать список из одного или более кода страны, известив остальную сеть, на территории каких стран местные власти могут с их нодами "что-то сделать". Например, если сама нода живёт у своего мастера на домашней машине в условной Аргентине, но использует при этом fedaproxy на VPSке в Канаде, то должны быть указаны как минимум AR и CA. Если один из указанных кодов относится к Евросоюзу, то в дополнение к ним ещё и EU. А для верификации будет использоваться привязка IP-адресов в Интернете к странам, т.е. если внезапно некая нода оказывается за IP-адресом страны, не входящей в задекларированный ею список, к ней должны возникнуть вопросики.
ответить
From Parthen (unverified) Fri Nov 29 19:21:43 2024 UTC
Re: Re: Тогда еще пару вопросов
>то почему на них HTTP не запустить
Ну например чтобы туда не протащили JS. Да и CSS убрать можно, вместе с XML-ым гипертекстом. Сделать что-то по типу Gemini, только без шифрования.
Вон, уеб-разработчки умудряются в Tor тонны JS запихивать, говоря при этом о какой-то "анонимности" своих сайтов.
> Ну то есть псевдо-TLD вроде того же .feda — это понятно, и даже имена вроде 49feb618794a8e1e4439.feda (где 49feb618794a8e1e4439 — nodeID) — ну, это тоже понятно, но хочется и чего-то более мнемоничног
А если просто локально сделать? Чтобы человеку при первом заходе на сайт предлагалось, мол, хотите 49feb618794a8e1e4439.feda занести как test.feda?
ответить
From Andrey V. Stolyarov Fri Nov 29 19:57:26 2024 UTC
Re: Re: Re: Тогда еще пару вопросов
> Сделать что-то по типу Gemini, только без шифрования.
Что-то подобное надо делать безотносительно FEDAnet.
> уеб-разработчки умудряются в Tor тонны JS запихивать
Не пускать вебанутых в сеть — идея заманчивая, но я не понимаю, как её реализовать.
> А если просто локально сделать? Чтобы человеку при первом заходе на сайт предлагалось, мол, хотите 49feb618794a8e1e4439.feda занести как test.feda?
Честно говоря, вообще не понимаю, о чём речь. "Предлагалось" — ну вот это чем, кем, как, и в конце концов зачем? Если имеется в виду что-то вроде закладок, так это можно средствами существующих браузеров делать и никакая поддержка для этого не нужна.
ответить
From Parthen (unverified) Fri Nov 29 20:17:31 2024 UTC
Re: Re: Re: Re: Тогда еще пару вопросов
>"Предлагалось" — ну вот это чем, кем
Самим сайтом (его владельцем). Мол, мой сайт называется так, у себя зовите как хотите.
> Если имеется в виду что-то вроде закладок
Скорее что-то вроде /etc/hosts
ответить
From Andrey V. Stolyarov Fri Nov 29 20:21:54 2024 UTC
Re: Тогда еще пару вопросов
Слушайте, вы же не предлагаете браузеру дать доступ на изменение /etc/hosts? Ну то есть вроде бы я от вас такого маразма не вижу причин ожидать, но с другой стороны от ваших слов я не могу в голове устаканить какое-то другое впечатление.
ответить
From Parthen (unverified) Fri Nov 29 20:42:11 2024 UTC
Re: Re: Тогда еще пару вопросов
Нет конечно (да и каким образом, там же запись root-only).
Просто какой-нибудь отдельный файлик в который таким же образом идут записи "ip домен", который FEDA считает приоритетнее /etc/hosts. (И уже в который наш не-веб браузер может что-то записывать с согласия пользователя). Остальной системе будет глубоко пофигу на этот файл.
Я, однако, все еще не окончил главу "про эти ваши интернеты", так что не представляю безопасно ли это вообще, но тут уже на ваше усмотрение.
ответить
From Andrey V. Stolyarov Fri Nov 29 20:59:41 2024 UTC
Re: Re: Re: Тогда еще пару вопросов
> который FEDA считает приоритетнее /etc/hosts
FEDA сама по себе не может ничего считать "приоритетнее /etc/hosts", поскольку сама по себе она вообще не будет никак работать с доменными именами внутри сети. Её дело — пакеты на IPv6-подсетку FEDA::0/16 корректно роутить через какой-нибудь tun0. Доменные имена её будут интересовать разве что при старте, чтобы найти в Большом Интернете бутстрапные ноды (такие, которые сидят на фиксированных ip-адресах и всем рассказывают, кто где).
Даже имена вида 49feb618794a8e1e4439.feda резолвить будет не сама FEDA, а какой-то DNS-сервер, видимо, специально для неё заточенный.
ответить
From Artem (unverified) Fri Nov 29 20:04:32 2024 UTC
Re: Re: Для анонимных нод будет запутывание трафика?
>> UDP-пакеты с содержимым, похожим на прочитанное из /dev/random
Смущает сие, очень сильно. Я почти уверен, что если натыканные у абсолютно всех провайдеров в России ТСПУ ещё не режут ни на что не похожий трафик чисто на всякий случай, то скоро непременно начнут.
А если в трафике FEDA всё же найдут уникальный паттерн (это может быть и не содержимое пакетов, а их размеры, к примеру), то можно будет тупо запретить эту сеть и вызывать на беседу в отделение каждого, кто решит в неё заглянуть.
ответить
From Andrey V. Stolyarov Fri Nov 29 20:17:41 2024 UTC
Re: Re: Re: Для анонимных нод будет запутывание трафика?
> ещё не режут ни на что не похожий трафик
Если будет набор разрешённых протоколов, а всё остальное запрещено, это уже не будет интернетом. Возможно ли это? Наверное, да, но пока что такого нет даже в Китае. Впрочем, для таких вещей тоже есть решения.
Иной вопрос, что я не готов пытаться создать решатель всех проблем.
В принципе тот транспорт, который я намерен сделать, может не быть единственным. Общий принцип тут — вот ключи, вот хеш, определяющий ранг, а вот подсетка адресов IPv6, которую можно использовать, которая точно не пересечётся с другими (там я в какой-то момент считал, если в FEDAnet за всё время её существования будет миллиард нод, то вероятность ОДНОЙ коллизии за всё время её существования составляет что-то около одного к миллиону). А связать ноды между собой можно как угодно, хоть телепатически, лишь бы пакеты ходили. Т.е. от FEDAnet можно брать одну только адресацию, это уже больше чем ничего.
> можно будет тупо запретить эту сеть
Можно и интернет запретить. И даже компьютеры.
ответить
From Anonymous (unverified) Mon Dec 2 21:31:38 2024 UTC
Резня и mesh сети
Некоторые "рандомные" для РКНа протоколы уже режут [JS]. Например, Shadowsocks, который может быть как TCP, так и UDP. [...skip...]
Надеюсь дожить до момента, когда люди допрут, что wifi интерфейсы в устройствах (хоть тех же смартфонах) можно использовать для обмена пакетами без посредников в виде роутера или кабеля, особенно на улице, что актуально в случаях значительных, эээ... "собраний", когда режут всё, что ни попадя, пока не утихнет. Короче говоря, неплохо бы просвещать людей о концепции mesh сетей и дать простой инструментарий для этого, пусть даже для ведроида, будь он трижды неладен (вообще, на современных смартах есть wifi hotspot'ы, но это проприетарщина).
К слову, перед началом лекции в Монтелиберо Андрей Викторович говорил об отсутствии приемлемых способов постоянного доступа к Сети, и предложил (как вариант) именно mesh сети. Хотел бы задать ему вопрос -- является ли таковой FEDAnet? Если я верно понял, mesh -- это когда между любыми 2 узлами (которые физически в принципе можно соединить и хотят быть частью сети) есть хотя бы 1 маршрут, а при потере узла/канала маршруты перестраиваются, чтобы вновь любые 2 узла имели маршрут. Однако, при потере ноды её поинты никак в Феду не вернутся (если сами нодами не станут), и нет такого, чтобы при обнаружении новых устройств они автоматом становились участниками Феды. Вероятно, я что-то не так понял, и хотел бы, чтобы Андрей Викторович меня поправил.
ответить
From Andrey V. Stolyarov Tue Dec 3 05:58:13 2024 UTC
Re: Резня и mesh сети
> Некоторые "рандомные" для РКНа протоколы уже режут
Вот именно что не рандомные, а конкретные. Пока что там не режут по принципу "всё кроме явно разрешённого". Если начнут — это, как я уже сказал, будет не интернет, а недоразумение, но, пардон за цинизм, лично меня это уже не касается.
> К слову, перед началом лекции в Монтелиберо Андрей Викторович говорил об отсутствии приемлемых способов постоянного доступа к Сети, и предложил (как вариант) именно mesh сети. Хотел бы задать ему вопрос -- является ли таковой FEDAnet?
Я говорил об отсутствии приемлемых способов доступа к Сети с мобильных устройств. FEDAnet вообще не про это. Совсем. И нет, она не является mesh-сетью, она является (точнее, будет) p2p-сетью.
Заниматься мобильными устройствами в нынешних условиях я вообще не имею никакого желания, поскольку всё, что сейчас на эту тему есть из железа, годится только для расшибания об асфальт.
Единственное направление, которое мне кажется до какой-то степени перспективным — это попытаться сделать мобильное (ну, скорее portable) устройство на основе разновсяческих SBC вроде Orange Pi. Результат вряд ли можно будет носить на себе (аккум тяжеловат будет), но, скажем, при перемещении на автомобиле или мотоцикле — запросто. Можно, кстати, будет сделать такие специфические ноды FEDAnet, которые к себе пускают пойнтов от других нод (просто по действующему сертификату, выданному нодой с достаточным рангом мастер-ключа), выдают им динамический адрес в своей подсети и релеят до всех, до кого дотянутся, в том числе друг с дружкой вяжутся по принципу той самой mesh-сети. Только, извините, лично я сам в этом направлении копать не буду, невозможно решить все проблемы мира в одну харю.
На всякий случай: в последнее время развелось много желающих осчастливить мир чем-то этаким, существующим исключительно в виде мобильного приложения. С подобной публикой мне обсуждать нечего, кроме разве что способов совершения суицида.
ответить
☞ From Anonymous from network, which should not be named (unverified) Fri Nov 29 11:47:34 2024 UTC
Надо сделать возможность внести правки в протокол
Надо оставить возможность изменить шифрование, чтобы в далеком "светлом" будущем квантовые компьютеры не угробили сеть к чертям.
Пока можно не менять, надо не менять.
ответить
From Andrey V. Stolyarov Fri Nov 29 12:50:25 2024 UTC
Re: Надо сделать возможность внести правки в протокол
Придумывайте свой проект и там решайте, что "надо" и что "не надо". В моём проекте ничего подобного не будет, и дискуссии на эту тему не будет тоже. Тех, кто придумал SSL/TLS, следует четвертовать, а с теми, кто из этого мрака не вынес основной урок — что криптография не имеет права быть не-фиксированой — мне обсуждать нечего.
ответить
From Artem (unverified) Fri Nov 29 13:51:05 2024 UTC
Re: Надо сделать возможность внести правки в протокол
>> квантовые компьютеры
В принципе, если только я правильно понимаю смысл сего явления, можно было бы заменить здесь "квантовые компьютеры" на "покемоны в покеболах", и смысл бы не изменился совершенно.
ответить
☞ From Алексей (unverified) Wed Nov 27 18:07:43 2024 UTC
Права доступа
Здравствуйте, Андрей Викторович!
Правильно же я понял, что только мастер узла выдаёт доступ, ключ? Т.е. если кто-то получил ключ от мастера, он не сможет его передать третьему лицу, чтобы оно получило доступ внутрь "периметра", верно?
Пытаюсь представить, смоделировать общение с несколькими группами людей разного уровня доверия и приватную переписку один на один.
СИТУАЦИЯ #1: Например, для семьи, самого близкого круга одна нода/узел. Тут всё понятно, все и так знают друг друга. В этот "огород" я больше никого не хочу пускать.
СИТУАЦИЯ #2: Для круга друзей, лично знакомых - второй отдельный узел. В привычной терминологии для многих - канал/группа. (Хотя именно тут, возможно, я и путаю понятия и архитектуру как это устроено внутри.)
Тут тоже интересный момент, что я знаю всех, а они могут не знать друг друга никто.
Они внутри этого узла как-то видят друга, знают друг о друге, смогут просканировать узел, связаться с другими участниками, представиться теми кем не являются?
У них будет какой-то мнемонический, запоминающийся идентификатор на время существования узла до 253 участников? У самого узла? Какая-то связь между узлами, насколько понял, может быть?
СИТУАЦИЯ #3:
С малознакомым человеком необходимо создать канал/средство общения один на один. И больше в него не допускать никого. Возможно даже пытаться поддерживать анонимность. Конечно, я читал про рекомендацию "лично знать друг друга".
Для приватного общения тет-а-тет можно ограничить количество возможных участников узла до 2?
Допускаю, что мои категории мышления искажены современными мессенджерами/средствами коммуникации. Ну как есть. Никто не научил хорошему, пытаюсь ликвидировать безграмотность.
РЕЗЮМЕ: В целом хочу прояснить видимость участников узла друг для друга, возможность/невозможность пересылать информацию, файлы из одного узла в другой отдельный. Возможность ограничения пересылки любой информации за периметр узла. Возможности вторжения кого-то нежелательного и пути минимизации этих рисков.
И вообще может я неправильно понимаю как это устроено и напрасно, избыточно плодить столько узлов, достаточно будет одного?
Спасибо за время и внимание.
ответить
From Andrey V. Stolyarov Wed Nov 27 18:41:21 2024 UTC
Re: Права доступа
У меня чёткое ощущение, что вы вообще не понимаете, о чём идёт речь. Ну вот хотя бы даже это ваше
> Какая-то связь между узлами, насколько понял, может быть?
Вообще-то ради связи между узлами всё и делается. Мессенджеры, каналы и прочая прикладнуха тут вообще ни при чём, на нынешнем этапе речь идёт только о транспорте (точнее, формально это вообще "сетевой" уровень): ну написано же на сайте, внутри будет IPv6, связь между отдельными узлами -- через существующий Интернет.
Дальше, вот это вот
> Т.е. если кто-то получил ключ от мастера, он не сможет его передать третьему лицу,
Что значит "не сможет"? Физически? А как сделать так, чтобы он не мог? Ну вот как сделать так, чтобы один человек не мог какому-то другому человеку передать простой текстовый файлик? Вот просто взять и отдать?
Я потому и настаиваю, что хозяин ноды должен всех пойнтов знать лично. И кому попало пойнты не выдавать. Тут дело даже не в том, что пойнт может получить какой-то там доступ "внутрь узла", узел должен быть организован нормально, т.е. так, чтобы пойнты могли только то, что им мастер разрешил. Хуже другое: пойнт может сделать что-то не то в отношении пользователей сети, работающих через другие узлы. Вот перед другими узлами мастер будет за своих пойнтов отвечать как за себя самого. Например, ваш пойнт послал нах$$$ кого-то не того, тамошний мастер возмутился и забанил — естественно, не пойнта забанил, а весь ваш узел. Потом ещё публике рассказал, что ваш пойнт вот такая редиска, и остальные тоже почесали в затылке, а некоторые ваш узел забанили. Вот и генерите теперь новый мастер-ключ.
> С малознакомым человеком необходимо создать канал/средство общения один на один.
В принципе можно взять ключик низкого ранга, который никто всё равно признавать на своих узлах не станет, и пойнта этому малознакомому выдать на таком вот мусорном узле. Ну хотя тоже так себе затея, если только у вас нода не на постоянном "белом" ip-адресе: ему же как-то надо будет узнавать, где (на каком адресе/порту) сегодня/сейчас ваша нода, а узнать это можно только через других участников сети, которые, если вашу ноду не признают (а мусорные ключи никто признавать не будет), то и информацию о ней не хранят, и рассказать про неё не могут.
Но вообще это всё обсуждать рано, поскольку я пока что даже не начинал думать, как там внутри сети должно быть устроено "общение" и вообще прикладные службы.
> Они внутри этого узла как-то видят друга,
Да. И не только внутри узла, а внутри всей сети.
> знают друг о друге,
Да.
> смогут просканировать узел,
Зависит от того, как построен узел. Сама FEDAnet устанавливает связь и маршруты на соответствующие подсетки, но всевозможные пакетные фильтры и прочие файрволы никто не отменял.
> связаться с другими участниками,
Да, а иначе зачем вообще вся эта затея
> представиться теми кем не являются?
Зависит от политики ноды. Насколкьо я могу судить, нода должна быть или открытая (скажем так, при этом её пользователи, в том числе хозяин, могут раскрывать другим участникам сети свою реальную личность, но, если мастер этого не требует, то никоим образом не обязаны этого делать), или анонимная (в этом случае только ники и прочие псевдонимы, потому что один дебил, рассказавший, кто он и что он in RL, тем самым "сдаст" анонимность всей ноды, потому что прижать ему яйца дверью — дело техники).
Но вот что точно есть и подделке не подлежит -- это идентификатор ноды и идентификатор пойнта. Например, 49feb618794a8e1e4439.103. Вот это уже нельзя ни подделать, ни заспуфить, вообще с этим ничего сделать нельзя. Идентификатор ноды выводится из её публичного ключа (собственно, это тупо десять последних байтов ключа) и является частью всех IP-адресов, используемых нодой. Идентификаторы пойнтов распределяются хозяином ноды.
> мнемонический, запоминающийся идентификатор
У меня есть некоторые мысли на этот счёт, но озвучивать их явно рано.
ответить
From Anonymous (unverified) Wed Nov 27 18:58:56 2024 UTC
Re: Re: Права доступа
> Идентификатор ноды выводится из её публичного ключа
может лучше все таки из хеша ключа?
ответить
From Andrey V. Stolyarov Wed Nov 27 19:12:57 2024 UTC
Re: Re: Re: Права доступа
Нет, не лучше. Совсем не лучше. Вычисление хеша — операция дорогостоящая, её лишний раз лучше не делать, да и не хранить этот хеш вообще: один раз хеш для данного публичного ключа посчитали, увидели его ранг, запомнили, больше этого не делаем, работаем только с ключами. А реверснуть публичный ключ в любом случае невозможно, как и использовать фейковый, в смысле такой, для которого на самом деле нет секретного (если что-то из этого станет возможно, сети в любом случае пдц, причём независимо от того, откуда там идентификатор ноды берётся).
ответить
From Алексей (unverified) Wed Nov 27 20:27:11 2024 UTC
Re: Re: Права доступа
Да, действительно, не хватает понимания, знаний. Потому задаю вопросы.
Я честно и добросовестно перечитывал несколько раз основные тексты сайта FEDAnet в автоматическом переводе на русский язык перед тем как задать вопросы. Много раз обращался к поисковику для чтения статей об определениях в энциклопедическом стиле и поисковому оператору site:stolyarov.info
Как обычному пользователю, не причастному к программированию, бывает не хватает осознания даже приблизительно категорий в которых мыслите. Кстати, кажется, видеоблог помогает пониманию даже лучше, чем статьи про техническую тематику.
Стараюсь по мере своих возможностей заниматься самообразованием.
Правильно понимаю, что мне нужно пройти ликбез про сети, протоколы, немного шифрование и не натягивать на это свои категории мышления программами (мессенджерами)?
ответить
From Andrey V. Stolyarov Wed Nov 27 20:38:52 2024 UTC
Re: Re: Re: Права доступа
> Правильно понимаю, что мне нужно пройти ликбез про сети, протоколы, немного шифрование
В принципе правильно, поскольку на нынешнем этапе в этом проекте просто отсутствует тот слой, который вообще в принципе может быть описан в терминах, понятных конечному пользователю. Вот только начал бы я не с этого. Начать стоит с изучения английского языка. И уж вот это — без вариантов; пока вы технические тексты читаете гуглопереводчиком, с тем же успехом вы можете их и вовсе не читать.
ответить
From Алексей (unverified) Wed Nov 27 21:02:21 2024 UTC
Re: Re: Re: Re: Права доступа
Понял, спасибо)
Планируете делать раздел FAQ для сайта FEDAnet?
ответить
From Andrey V. Stolyarov Wed Nov 27 21:05:14 2024 UTC
Re: Права доступа
В планах стоит, но явно не в ближайших. Если делать FAQ сейчас, неизбежно придётся подробно описывать то, чего ещё нет. Я предпочитаю сначала сделать, потом описывать.
ответить
From Ilya Fri Nov 29 08:10:40 2024 UTC
Re: Права доступа
> мнемонический, запоминающийся идентификатор
Поскольку, как я понял, идентификатор ноды это обычный IPv6, каждый пользователь сможет сам добавить в /etc/hosts удобный ему псевдоним для нод к которым он часто ходит, да и с классическим DNS оно должно быть совместимо. Но это для нод, конечно, а не для поинтов.
ответить
From Andrey V. Stolyarov Fri Nov 29 09:11:40 2024 UTC
Re: Re: Права доступа
> идентификатор ноды это обычный IPv6,
Ну не совсем. Адрес IPv6 содержит 16 байтов, из них идентификатор ноды — только десять; старшие два байта в адресе — это префикс FEDA, младщие четыре — хосты внутри ноды. Т.е. если говорить о соответствии нод IP-адресам, то нода будет представлять собой IPv6-подсетку /96.
Если продолжать в этом направлении, то поинту тоже будет соответствовать подсеть, только уже /104.
ответить
☞ From А. (unverified) Wed Nov 27 16:10:02 2024 UTC
Бан в FEDAnet
Здравствуйте, Андрей Викторович!
Возможно я не заметил, хочу уточнить: В рамках своего узла FEDAnet мастер узла сможет банить тех, кто себя стал неэтично вести или чья "учётка/ключ" стали скомпрометированы?
Например, физически его устройство попало в руки к врагу/органам гос безопасности, или стало ясно/есть подозрения, что он агент.
Или необходимо будет ликвидировать узел? И заново как-то собирать участников?
ответить
From Andrey V. Stolyarov Wed Nov 27 16:22:00 2024 UTC
Re: Бан в FEDAnet
> В рамках своего узла FEDAnet мастер узла сможет банить
Разумеется, сможет. А что ему может в этом помешать, учитывая, что все исходники открыты? Скорее всего, конечно, банить нужно будет другие ноды целиком — типа, ключ вот такого-то узла у нас тут больше не котируется.
Если речь о собственных пойнтах, то всё ещё проще: выпускается более новый сертификат с тем же номером пойнта, секретный ключ от него тут же удаляется. Всё, хана — со своей нодой этому пойнту уже не соединиться, а остальные ноды и так с чужими пойнтами работают, ну, скажем так, условно, а тут и вовсе перестанут с ним иметь дела, когда до них этот новый сертификат доползёт.
> Или необходимо будет ликвидировать узел?
Это только в одном случае: при компрометации секретного master-ключа. Вот того, который генератором генерируется. Отсюда мораль: с этим ключом никогда не следует ничего делать на компьютерах, в принципе имеющих сетевое соединение. Оно, собственно, и не надо: тем ключом подписали ZeroPoint, и убрали ключ куда подальше — скопировали на две-три флешки, спрятали эти флешки куда поглубже в разных местах. Всё остальное делаем с помощью ZeroPoint'овского ключа, а если, ктулху упаси, он оказывается скомпрометирован — ну, тогда (и не раньше) достаём из пыльного угла флешку с мастер-ключом и делаем новый ключ (и новый сертификат) для ZeroPoint.
ответить
☞ From Anonimous (unverified) Tue Nov 26 22:47:54 2024 UTC
Отчуждаемость ключа для ноды
Почитал документацию и идея генерировать несколько месяцев приватный ключ вот совсем не вдохновляет. Если бы вдохновляла, то наверное занимался бы давно майнингом.
Кажется интересной возможность купить его у кого-то, но очевидно что в текущей реализации это невозможно, так как прежний владелец все равно его сохранит. Вы категорически против подобной возможности, не видите способа адекватно реализовать или это наоборот запланированно в каком-то виде?
Не силен в криптографии, но как будто если использовать вместо сгенерированного feda-ng ключа пару из обычного ssh ключа, то подобное будет возможно? Вопрос только в уведомлении всем контактов владельца старой ноды что она больше недействительна в паре его публичным ssh ключем.
Это бред, плохая рабочая, но по ряду причин не приемлимая схема, или Вы что-то такое и планируете?
ответить
From Andrey V. Stolyarov Wed Nov 27 08:14:27 2024 UTC
Re: Отчуждаемость ключа для ноды
> занимался бы давно майнингом
Майнинг наиболее популярных криптовалют на обычном CPU не работает, слишком медленно и энергозатратно в сравнении с ASIC'ами. В FEDAnet применён хеш, нивелирующий преимущества ASIC'ов и GPU.
> очевидно что в текущей реализации это невозможно, так как прежний владелец все равно его сохранит
Насколько я понимаю, это так в любой реализации.
> Вы категорически против подобной возможности,
Вообще говоря, да: я совершенно категорически против любых "услуг", как платных, так и "бесплатных", связанных с доступом в эту сеть. Внутри самой сети я против коммерческой деятельности не возражаю, если только она не будет связана с рекламой, но во всём, что связано с доступом, любая даже не то чтобы коммерция, а просто массовость угробит всю идею, ну а коммерция без массовости не бывает.
Но определяющим тут является не моё мнение, а вот это вот:
> не видите способа адекватно реализовать
Именно.
> пару из обычного ssh ключа
Ключи, используемые ssh, тут вообще ни при чём и их сюда никак пришить нельзя. Никаким способом.
ответить
From Ilya Wed Nov 27 10:58:49 2024 UTC
Re: Re: Отчуждаемость ключа для ноды
> Майнинг наиболее популярных криптовалют на обычном CPU не работает
Кстати в Monero уже давно работает алгоритм RandomX (пришедший на смену CryptoKnight), который делает майнинг на GPU и ASIC неэффективным.
ответить
From Andrey V. Stolyarov Wed Nov 27 11:08:20 2024 UTC
Re: Отчуждаемость ключа для ноды
Забавно, что в полученной мной рекомендации на тему хешей упоминались как раз эти два — RandomX и yespower, который я в итоге и взял.
ответить
From anon (unverified) Fri Nov 29 13:48:59 2024 UTC
Re: Отчуждаемость ключа для ноды
Почитал документацию и идея генерировать несколько месяцев приватный ключ вот совсем не вдохновляет. Если бы вдохновляла, то наверное занимался бы давно майнингом.
Майнингом, если я не ошибаюсь, приходится заниматься постоянно, а тут это нужно делать только для получения ключа. Обычные ключи не подойдут, т.к. тут смысл как раз в том, чтобы быстро сгенерировать ключи нельзя (а если кто-то хочет быстро, то ему это будет достаточно затратно) из-за чего всяким корпорациям придется задумываться стоит ли тратить ресурсы на генерацию ключиков, которые забанят в тот же момент, когда узнают про раздачу ключей.
P.s. пока генерация ключа у меня проходит так: ключ ранга 18 получил в первый день, ранга 19 через два дня, ранга 20 через шесть дней, а ранга 21 через девять дней.
ответить
☞ From А. (unverified) Mon Nov 25 07:54:48 2024 UTC
План/этапы/последовательность реализации проекта
Андрей Викторович, какими средствами предполагается общение внутри сети? Емаil? Предполагается создание нового мессенджера, лишённого недостатков существующих, или использование чего-то существующего (форк) с выпиливанием его недостатков?
ответить
From Andrey V. Stolyarov Mon Nov 25 08:11:47 2024 UTC
Re: План/этапы/последовательность реализации проекта
Насчёт мессенджера см. тут: http://www.stolyarov.info/guestbook/archive/8/#cmt955
Но это всё не сейчас, сейчас бы сначала транспорт запустить. А дальше — думать, думать. Я пока что толком не понимаю, как там будет устроено пространство доменных имён, ну то есть доменные имена, соответствующие нодам/пойнтам — это понятно, но хочется и чего-то более мнемоничного.
ответить
From A. (unverified) Mon Nov 25 13:24:01 2024 UTC
Re: Re: План/этапы/последовательность реализации проекта
Спасибо большое. Прочитал.
И даже что-то понял. Думаю процентов на 80. Общую схему, всё что не связано с более специальными знаниями протоколов, технологий. И приоритет понятен. Сначала инфраструктура.
Общий принцип, как я понял, что чем проще - тем лучше. А шифрование нужно делать на уровне инфраструктуры, а не программ.
ответить
From Andrey V. Stolyarov Mon Nov 25 13:40:13 2024 UTC
Re: План/этапы/последовательность реализации проекта
Совершенно верно, всё должно быть тупое как чугунная болванка, это основа основ. Что касается шифрования, то повальное шифрование трафика на уровне прикладных программ, ставшее мейнстримом в последние лет пятнадцать — это явление категорически недопустимое, и туда же следует отнести ещё много интересных явлений, таких как выбор конкретных алгоритмов уже в процессе взаимодействия (как это делается в SSL/TLS), certificate authorities и ещё много чего, причём вне всякой зависимости от того, есть или нет шифрование на уровне инфраструктуры. Попросту говоря, нельзя так усложнять и устройство прикладнухи, и её использование, причём нельзя и всё, и точка, а всё остальное (давайте, мол, шифроваться на уровне каналов) — это уже как повезёт.
ответить
☞ From А. (unverified) Mon Nov 25 07:42:26 2024 UTC
Домен для сети
croco.net тоже сам по себе классный домен для названия сети.
ответить
From Andrey V. Stolyarov Mon Nov 25 08:15:24 2024 UTC
Re: Домен для сети
Это как раз так себе идея. А ну как я помру и за домен не заплачу? Или, например, дождусь, пока все к домену привыкнут и в нём чего-то навертят, а потом заявлю, что что-то там становится с завтрашнего дня платным? Доменное имя в "ванильном" DNS'е — это единая точка отказа.
ответить
☞ From Anonymous (unverified) Wed Nov 20 19:40:55 2024 UTC
C++
Почему C++ неподходит для софта который слушает порты?
ответить
From Andrey V. Stolyarov Wed Nov 20 20:53:36 2024 UTC
Re: C++
Потому что не поддаётся ручному аудиту исходников.
ответить
From Anonymous (unverified) Wed Nov 20 22:09:21 2024 UTC
Re: Re: C++
Означает ли это, что на описанном вами идеальном языке так же нельзя будет писать такой софт? Ведь его аудитить будет еще труднее, все будет глубоко закопано под слоями макросов.
ответить
From Andrey V. Stolyarov Wed Nov 20 22:53:55 2024 UTC
Re: C++
Нет, не означает, разумеется. Используемый уровень абстракций в этом языке должен зависеть не от самого языка, а от применённых в конкретном проекте макробиблиотек, и вопрос будет не в выборе языка, а в выборе этих самых библиотек. Подозреваю, что большинство таковых для критичного софта подходить не будет, но будут, очевидно, и такие, которые подойдут.
ответить
☞ From Anonymous (unverified) Wed Nov 20 14:26:09 2024 UTC
C?
It looks like C++
ответить
From Andrey V. Stolyarov Wed Nov 20 14:54:13 2024 UTC
Re: C?
К сожалению, это C99, а автор, вообще говоря, не программист, как и большинство криптографов, если не все.
Но там не так сложно отстричь C99-измы, насколько я вижу, и это безусловно стоит в планах, просто это не верхний приоритет сейчас.
ответить
☞ From Anonymous from I2P (unverified) Wed Nov 20 14:22:21 2024 UTC
Build faild
FreeBSD 14.1-RELEASE, amd64
ответить
From Andrey V. Stolyarov Wed Nov 20 14:54:52 2024 UTC
Re: Build faild
Твою мать, читать доки будем или как? Про это написано в README, про это написано на сайте, куда мне ещё, на заборе то же самое написать?
И вот что, будет дальше I2P в нике — комменты останутся в очереди на премод из-за одного этого.
ответить
From Василий Ильич (unverified) Wed Nov 20 17:38:17 2024 UTC
Re: Re: Build faild
> на заборе то же самое написать
Андрей Викторович настолько крут, что когда скачивают его программу, инструкция появляется на ближайшем заборе.
ответить