> Ты стандарт всё равно опиши в документации, да поподробнее, другим ведь тоже у себя реализовывать надо.
> Плюс можно будет определённые куски текста на доработку отправлять, если спор возникнет.

AL> Предлагаю упростить всё и оставить только схемы f/e для индексов и f/p для посылки файлов, а для загрузки уже использовать существующую схему x/file.

>> Предлагаю упростить всё и оставить только схемы f/e для индексов и f/p для посылки файлов, а для загрузки уже использовать существующую схему x/file.
> Отличная идея, полностью за. Только в какой список будем файлы (для /x/file) складывать: в приватный или публичный?

vit01> Кстати, а если на нескольких разных станциях поинты одновременно загрузят два файла с одинаковыми именами?
vit01> Как-то конфликты разрешать надо будет при синхронизации.
vit01> Поэтому различать файлы по хэшу - это неплохая идея.

Demon> Вы знаете как выложить игру в INSTEAD?

Demon>> Вы знаете как выложить игру в INSTEAD?

AL> Нет.

Сказал держатель репозитория или что ты там хостишь :)

Demon>>> Вы знаете как выложить игру в INSTEAD?
AL>> Нет.
vit01> Сказал держатель репозитория или что ты там хостишь :)

>Первое (уже озвученное ранее) это нетмейл. То есть личная переписка.

AL>> Первое (уже озвученное ранее) это нетмейл. То есть личная переписка.
Difrex> Самое важное, ИМХО.
Difrex> Не обязательно монстрячить PGP. Можно взять AES или RSA. Обмен откртыми ключами - да, доверять сисопу. Т.е. теоритически может быть MitM.
Difrex> Нужно хотя бы драфт накидать.

> В очередной раз задумался о расширении стандарта.

> Первое (уже озвученное ранее) это нетмейл. То есть личная переписка.

> Удобного и действительно безопасного варианта я так и не придумал. Или привлекать PGP и монстрячить способ распросстранения открытых ключей или доверять всем сисопам сети личную переписку, отдавая поинтам только их сообщения. Если честно, мне оба варианта не нравятся. Может, у кого есть идеи получше?

Хочу озвучить мысли по нетмылу.

1) как ни крути, иметь возможность послать личное сообщение -- это нужная фича
2) шифрование может быть, а может не быть. делать его неотъемлемой частью нетмыла не вижу смысла. нетмыло - транспортировка, которая не противоречит шифрованию, но не заточено на него.
3) реализация должна быть простой
4) для работы netmail нужно понятие адресации, и эта адресация должна быть глобальной

Сначала, очевидные вещи.

Я вижу 2 способа реализации netmail. В обоих случаях есть специальная скрытая эха netmail. При ее фетчинге -- клиент получает только те сообщения, которые адресованы именно ему. В качестве адреса -- имя ноды и номер поинта (то, что у нас есть). Авторицация по authstr. Но вот как сообщение доходит до ноды, отдельный разговор. Итак, первый способ.

1) Сообщение распостроняется путем фетчинга как и сейчас. При этом, нужно решить 2 проблемыЖ

a) фетчить netmail могут только те ноды, которым мы доверяем;
b) сообщение в netmail должны убиваться после доставки;

Про b) решить можно радикально. Просто заложить в стандарт время жизни таких сообщений. Например 2 дня. Если за 2 дня сообщение не дошло -- все равно это какая-то проблема. Считаю, приемлемым.
Про a) к сожалению, единственный нормальный способ, это механизм ЭЦП. Нода, которой мы доверяем фетч, дает нам открытый ключ, который мы используем для проверки подписи запроса. Реализовать можно прямо на питоне, без сторонних библиотек. Еще один вариант -- тупо по ip запроса, но мне он не нравится. Вариант с авторизацией по authstr не нравится вообще.

Теперь переходим к варианту 2)

Идея в том, что сообщение идет так:
поинт -> нода поинта -> целевая нода

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

a) кто может посылать таким образом сообщения нашим поинтам?
Варианты ответа.
1) все, кто угодно.
2) ????

вариант 1 неуниверсален.
а вариант 2 - мне не понятен. Так как в общем случае, я не знаю от кого получу запрос.

В итоге, вариант 1 с фетчингом мне нравится больше.

Кто что думает?

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

Peter> есть специальная скрытая эха netmail. При ее фетчинге -- клиент получает только те сообщения, которые адресованы именно ему. В качестве адреса -- имя ноды и номер поинта (то, что у нас есть). Авторицация по authstr. Но вот как сообщение доходит до ноды, отдельный разговор. Итак, первый способ.

Peter> 1) Сообщение распостроняется путем фетчинга как и сейчас. При этом, нужно решить 2 проблемы

> a) фетчить netmail могут только те ноды, которым мы доверяем;
> b) сообщение в netmail должны убиваться после доставки;

Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Опишу целиком.

Основа: есть единый реестр поинтов, у каждого - свой открытый ключ, который записывается в общую корзину и есть на всех станциях

1. Есть публичная эха netmail, которую может фетчить каждый. Все сообщения в netmail зашифрованы.
2. Все ноды открыто забирают друг у друга netmail и смотрят на поле получателя. Если получатель числится на ноде, то сообщение сохраняется там навечно (ну или на очень долгое время вроде 3 месяцев). Иначе (если нода ведёт транзит, т.е. такого поинта на ней нет) - держится около 5-10 дней, на усмотрение сисопа.
3. Шифрование всё end-to-end, сервера в нём не участвуют. Смог расшифровать - сообщение твоё. Не расшифровал - значит не твоё.

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

> Это противоречит самым основам IDEC (да и ii), а именно:

> Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Peter> С шифрованием, конечно, частично все упрощается. Но по моему, все таки, делать его частью стандарта не очень...

> Шифрование и не предлагается делать частью стандарта. Можно использовать абсолютно любые алгоритмы, которые в голову взбредёт. Если хочешь - можно вообще не шифровать. Правда, тогда найдутся любопытные, которые захотят читать чужие письма.

> Просто в этом случае, ЛЮБОЙ сможет прочитать эти сообщения. В моей схеме (которая мне тоже до конца не нравится пока) -- только доверенная нода.

> Чтобы доставить поинту сообщение(не важно шифрованное или нет), нужно знать его координаты. Либо нужно расширить схему сети и сделать ее обязаловкой, а так же наконец-то начать использовать адреса -- тогда узнать, где поинт не сложно.

Difrex> Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

> Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.

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

Peter> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано - то это netmail ко мне.

> Адреса не уникальны.

> Нас спасёт только шифрование

>Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.

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