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

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

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

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

Второе (вот тут не уверен, что вопрос поднимался мной ранее), это файл-эхи. Тут как раз всё просто: запрашиваем индекс фэхи, качаем нужные файлы. Пока я вижу это так:

Например, выделяем под это схемы f/

f/e/node.list вернёт что-то типа

node.list
n20170614.json:Нодлист за 14.06.2017
...
etc

Потом запрашиваем недостающие файлы

f/f/n201706.14.json

Скачиваем их и сохраняем локальный индекс.

Наваять это могу в течении пары дней на базе iing и caesium. Практический смысл мне видится в уодбстве (распространение сборок софта, фоток, нодлистов и всякого такого в духе сети, кокгда не ты ходишь за информацией, а информация сама приходит к тебе).

Что думаете об этом вот всём? Надо ли оно? Если честно, мне эти фичи кажутся такими вкусными, что я прямо горю желанием их реализовать =)

AL> Я думал сделать дополнительную схему, где по authstr отдавать только те сообщения, которые совпадают с пользователем.

Ради одной-двух эх вводить такое вряд ли имеет смысл, но попробовать можно.

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

Если уж очень хочется что-то сделать с этим (например, сохранять ключи в куках), то надо будет использовать внешнюю javascript-библиотеку, потому что самостоятельно мы это не потянем.

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

Придётся раньше времени выдавать наши секреты =)
Борис придумал сделать в андроид-клиенте интеграцию с PGP, которую лично я себе представляю примерно так:

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

Выбор ключа и всю грязную возню с криптографией под капотом будет осуществлять свободное приложение OpenKeyChain. Оно, кстати, есть в F-Droid'е, так что за удобный GUI и юзабилити беспокоиться не надо.

---------------

Насчёт фэхи сначала посмотрим то, что ты наваяешь, а потом решим. Но в целом мне эта идея нравится. Даёшь децентрализованный варез и прон!

> Придётся раньше времени выдавать наши секреты =)
> Борис придумал сделать в андроид-клиенте интеграцию с PGP, которую лично я себе представляю примерно так:
> При заходе в эху будет пункт меню "Настройки шифрования"
> В этих настройках пользователь указывает, что будет шифровать сообщения, отправляемые в эту эху, такими-то ключами, а расшировывать - своим таким-то.
> Механизм будет в идеале работать вообще в прозрачном режиме, вся шифровка-дешифровка будет производиться на уровне мейлера-фетчера. Шифровке подвергнется текст сообщения и сабж (мини-костылём).
> Выбор ключа и всю грязную возню с криптографией под капотом будет осуществлять свободное приложение OpenKeyChain. Оно, кстати, есть в F-Droid'е, так что за удобный GUI и юзабилити беспокоиться не надо.

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

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

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

> Насчёт фэхи сначала посмотрим то, что ты наваяешь, а потом решим. Но в целом мне эта идея нравится. Даёшь децентрализованный варез и прон!

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

ЗЫЖ Прости, gl00my, я так пока и не перевёл iing на sqlite.

AL> Мне эта идея в контексте личной переписки всё равно кажется несколько неудобной, так как требует помимо адреса ещё и открытый ключ, а не везде так удобно это делать. Хотя можно через файлэху публиковать %)

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

Как-то раз хотел шифрованно послать одному товарищу кое-какой текст. Он опубликовал свой открытый ключ в 3 местах: на своём Гитхабе, через Telegram и в публичной группе ВК.
И только после того, как я убедился, что эти послания все одинаковые (принадлежат одному человеку), мы наладили такой вот дополнительный "канал связи".
Паранойя, конечно, но если ты заботишься о настоящем и хорошем шифровании, то только так.

AL> И просто жизненно необходимо, чтобы личная переписка ходила не только в пределах одной станции.

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

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

Любители экзотики по своему желанию могут личные эхи себе настроить.

> И эту "личкоэху" можно прописать по умолчанию во всех наших клиентах. А все сообщения "лично для тебя" сразу будут лезть в карбонку (как всегда и бывает), так что не надо будет беспокоиться о работе "из коробки".
> Любители экзотики по своему желанию могут личные эхи себе настроить.

Я думал сделать дополнительную схему, где по authstr отдавать только те сообщения, которые совпадают с пользователем. Снять нагрузку с клиентов, в общем. Про PGP в принципе согласен. Его лучше таки использовать, но придётся лепить удобный механизм работы с этем делом. В том числе и через веб-интерфейс. Так что хотелось бы хорошенько продумать этот вопрос.

Можешь - делай. Потыкаем, потестим. Идея бодрая и нужная.

AL> Или привлекать PGP и монстрячить способ распросстранения открытых ключей или доверять всем сисопам сети личную переписку, отдавая поинтам только их сообщения.

По-моему лучше первый вариант. Так сделано во многих email и jabber клиентах. Обменялись открытыми ключами, а потом в эхе выбираешь для кого шифруешь сообщения и они отправляются шифрованные, а полученные клиент соответственно расшифровывает твоим приватным ключем.

AL> По поводу f/e у меня есть мысль в виде спецсимола в перед именем фэхи. Например, как я сделал расцветку квотированных строк в цезии, chr(15) + fecho. Если такой вариант кажется приемлемым, то так и сделаю.

Ни в коем случае! Надо только печатаемые символы. Тем более, если мы будем на фэху в сообщении ссылаться.

AL> Есть мысли что можно добавить и улучшить?

1. Обязательно требуется поле размера файла (в байтах), как сейчас есть в /x/file. Без этого никак 100℅

2. Для обычных эх доступны запросы вида /u/e/echo.1/echo.2, а также расширенный /u/e и /x/c. Для фэх предлагаю сделать то же самое, чтобы они не были неполноценными. Будет что-то вроде файлового IDEC'a

3. Я ещё не уверен в этом, но следовало бы подставлять имя поинта+адрес в метаданные, дабы отслеживать, откуда и от кого ползут файлы.

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

Пока вроде всё

>> Есть мысли что можно добавить и улучшить?
> 1. Обязательно требуется поле размера файла (в байтах), как сейчас есть в /x/file. Без этого никак 100℅

В случае файлэхи не очень понятен юзкейс для которого это поле нужно. Можно поподробнее?

> 2. Для обычных эх доступны запросы вида /u/e/echo.1/echo.2

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

> а также расширенный /u/e и /x/c.

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

> 3. Я ещё не уверен в этом, но следовало бы подставлять имя поинта+адрес в метаданные, дабы отслеживать, откуда и от кого ползут файлы.

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

> 4. На описание и на имя файла следует наложить лимиты, чтобы не было неожиданностей. На размер пока не знаю, здесь от сисопов всё зависит (ресурсы сервера)

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

> Пока вроде всё

Ну буду править код под эти замечания. Не вопрос.

Изменения по мотивам предыдущего сообщения Виктора:

* f/e теперь поддерживает слайсы аналогично расширенной u/e, но пока не поддерживает несколько фэх одновременно;
* появилась схема f/c, работающая аналогично x/c;
* в индекс фэхи теперь сохраняется информация об отправителе файла.

По поводу f/e у меня есть мысль в виде спецсимола в перед именем фэхи. Например, как я сделал расцветку квотированных строк в цезии, chr(15) + fecho. Если такой вариант кажется приемлемым, то так и сделаю. Если есть более разумные предложения, то традиционно открыт для диалога =)

Итак, последние приготовления перед пушем iing с файлэхами.

Работает это всё по трём новым схемам:

f/e/<fecho>

возвращает список файлов в фэхе (одной за запрос) в формате

имя_файла:описание

f/f/<fecho>/<filename>

скачивает нужный файл из фэхи (разные фэхи могут содержать одинаковые имена файлов).

f/p

через POST-запрос получает параметры pauth, fecho, dsc и file (строка авторизации, название фэхи, описание файла и сам файл соответственно) и сохраняет файл на узле, добавляя имя и описание в соответствующий индекс.

На уровне ФС это выглядит так:

В корне iing есть директория fecho/.

В ней есть поддиректории, соответствующие названиям фэх и индексы с именем файла <имя фэхи>.txt.

Встроенный фетчер iing уже поддерживает фэхи (параметр конфига fecho). Так же есть скрипт ff.py (войдёт в стандартную поставку iing) для публикации файлов в фэхах.

Есть мысли что можно добавить и улучшить?

А в чем файлэхи будут кардинально отличается от текущего списка файлов? Правильно ли я понимаю, что:

1. Файлы смогут загружать пользователи? Если так, то тут и вправду нужно вводить ограничения. Ты же не обрадуешься, если я к тебе на сервер залью коллекцию своих любимых фильмов. И если это так, то сможет ли пользователь потом удалить файл?

2. Файлэх может быть несколько? То есть можно будет разбить все файлы на категории: софт, музыка и т.п.?

3. Будут ли они гейтоваться между станциями? То есть смогу ли сидя на одной станции получить список файлов другой станции и скачать что-нибудь?

vit01> В имени файла только английский алфавит, никаких спецсимволов и пробелов.

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

> 2. Для обычных эх доступны запросы вида /u/e/echo.1/echo.2

AL> В случае файлэх нужен механизм однозначного признака, отличающего имя фэхи от имени файла. Поэтому пока нет такого. Но мы ж тут обсуждаем будущее расширение стандарта =) Готов подумать и принять предложения к рассмотрению.

Рома в таких случаях использовал двоеточие. А насчёт имени файла мы поставим его в "запретные" символы. Один фиг в некоторых ФС этот символ нельзя использовать. И слэши точно нельзя, можно их взять

> 1. Обязательно требуется поле размера файла (в байтах), как сейчас есть в /x/file. Без этого никак 100%

AL> В случае файлэхи не очень понятен юзкейс для которого это поле нужно. Можно поподробнее?

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

Котов в мешке никому качать не хочется. Особенно если в мешке не кот, а большая связка кирпичей.

AL> Запостить файл с именем, длина которого свалит фс, вряд ли возможно, а описание вряд ли вообще может на что-то повлиять.

Вот так и возникают уязвимости :) Ай да, и так сойдёт, как говорится ;)

Предлагаю имя файла ограничить 256 символами, описание - 4096. В имени файла только английский алфавит, никаких спецсимволов и пробелов. В описании - любой юникод, за исключением двоеточия и переворачивающих последовательностей (для правостороннего набора). Имя поинта и адрес задаются станцией.

AL> Пользователи будут загружать. Удалять не смогут.

В обычных эхах сообщения не удаляемые, имеется черный список. А здесь как? Если сисоп удалит файл, он будет добавлен в черный список? Или клиент при заходе в файлэху будет каждый раз загружать весь список файлов?

> А в чем файлэхи будут кардинально отличается от текущего списка файлов? Правильно ли я понимаю, что:
> 1. Файлы смогут загружать пользователи? Если так, то тут и вправду нужно вводить ограничения. Ты же не обрадуешься, если я к тебе на сервер залью коллекцию своих любимых фильмов. И если это так, то сможет ли пользователь потом удалить файл?

Пользователи будут загружать. Удалять не смогут. Пожалуй, ты прав. Не нужно полагаться на здравый смысл пользователей =)

> 2. Файлэх может быть несколько? То есть можно будет разбить все файлы на категории: софт, музыка и т.п.?

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

> 3. Будут ли они гейтоваться между станциями? То есть смогу ли сидя на одной станции получить список файлов другой станции и скачать что-нибудь?

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

ЗЫЖ Вот большие объёмы не знаю как ограничить. Административно или технически.

>> По поводу f/e у меня есть мысль в виде спецсимола в перед именем фэхи. Например, как я сделал расцветку квотированных строк в цезии, chr(15) + fecho. Если такой вариант кажется приемлемым, то так и сделаю.
> Ни в коем случае! Надо только печатаемые символы. Тем более, если мы будем на фэху в сообщении ссылаться.

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

vit01>> В имени файла только английский алфавит, никаких спецсимволов и пробелов.

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

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

Безусловно ЧС будет. Без этого никак. Ну и не стоит забывать, что фэхи будут разные и не обязательно подписываться на все. Как и гейтовать.

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

Если честно, то мне видятся вполне достаточными ограничения, которые у нас на имена эх распространяются, и в этом случае. Английский алфавит с учётом регистра, цифры, минус, подчёркивание и точка.

Вот с ограничениями в описаниях у меня такой ясности мысли пока нет.

А ещё как быть с названиями фэх? Сейчас у меня позволяются вообще любые и я не вижу смысла в обязательной точке, например.

>> В случае файлэх нужен механизм однозначного признака, отличающего имя фэхи от имени файла. Поэтому пока нет такого. Но мы ж тут обсуждаем будущее расширение стандарта =) Готов подумать и принять предложения к рассмотрению.
> Рома в таких случаях использовал двоеточие. А насчёт имени файла мы поставим его в "запретные" символы. Один фиг в некоторых ФС этот символ нельзя использовать. И слэши точно нельзя, можно их взять

А вот, кстати. В индексе фэхи есть двоеточия, а в имени нет. Значит можно считать строку с двоеточием именем фэхи =) Всё на поверхности же.

>> В случае файлэхи не очень понятен юзкейс для которого это поле нужно. Можно поподробнее?
> Не, ну ты чё. Скачивать файл 2 килобайта и 20 гигабайт есть разница и огромная. Во втором случае я ещё подумаю, надо это мне или нет (особенно если с телефона сижу, где трафик - это время и часто деньги). Да и на серверах ресурсы не резиновые. Это позволит писать скрипты, которые будут рассчитывать свободное место и выдавать уведомления мне как сисопу, например, что, дескать, всё, хватит.

За посыл в фэху 20 гигов надо карать =) Сам юзкейс фэх это передача небольших файлов.

>> Запостить файл с именем, длина которого свалит фс, вряд ли возможно, а описание вряд ли вообще может на что-то повлиять.
> Вот так и возникают уязвимости :) Ай да, и так сойдёт, как говорится ;)

Я руководствуюсь принципом Оккама. Отсекаю лишнее. Пока я не смог придумать гипотетической ситуации, которая свалит узел или клиента через длину файла или описания.

> Предлагаю имя файла ограничить 256 символами, описание - 4096. В имени файла только английский алфавит, никаких спецсимволов и пробелов.

Не взирая на мой предыдущий абзац, пожалуй всё же введу такое ограничение. Причём имя файла я бы подрезал до 64-х ну или хотя бы 128-и символов. Описание тоже срезал бы до килобайта. И то оверхед.

> В описании - любой юникод, за исключением двоеточия и переворачивающих последовательностей (для правостороннего набора). Имя поинта и адрес задаются станцией.

Двоеточие то зачем в описании запрещать? В индексе все поля фиксированы же. Выходит что-то типа того (пример на python):

f = row.split(":")
filename = f[0]
filesize = f[1]
username = f[2]
addr = f[3]
dsc = ":".join(f[4:])

и ни в чём не ограничиваем описание. Запрещать всякие спецсимволы это надо подумать. Если не затруднит, можно привести их список, а то я пока не знаю как их искать? =)

btimofeev> Так я и не понял: один и тот же файл будет храниться на всех серверах?

Да, а иначе смысла особого в фэхах вообще нет. Есть ведь /x/file
Идея-то неплохая, правда, злоупотреблять ей будут наверняка.

btimofeev> Да и на клиенте мне так же не хотелось бы автоматом выкачивать все файлы.

Мне тоже. Поэтому автоматом только индексы подцеплять буду.

AL> Подписался на фэху и все файлы, попадающие туда, к тебе ссыпятся автоматом. То есть они гейтуются и это в них самое вкусное. В отличии от фреков, мне видится большим преимуществом, что файлы сами будут приходить к пользователям.
AL> ЗЫЖ Вот большие объёмы не знаю как ограничить. Административно или технически.

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

AL> Не взирая на мой предыдущий абзац, пожалуй всё же введу такое ограничение. Причём имя файла я бы подрезал до 64-х ну или хотя бы 128-и символов. Описание тоже срезал бы до килобайта. И то оверхед.

Согласен на 64 + 1024.

AL> и ни в чём не ограничиваем описание. Запрещать всякие спецсимволы это надо подумать. Если не затруднит, можно привести их список, а то я пока не знаю как их искать? =)

Окей, пусть так будет. Не, насчёт спецсимволов я, например, могу припомнить непечатаемые последовательности, которые в консоли есть. Ещё есть переворачиваемая последовательность, которая файл 3mp.exe превращает зрительно в exe.mp3
В идеале надо просто непечатаемые символы удалить, а видимые - оставить. Но не знаю, как это технически реализуется.

AL> А ещё как быть с названиями фэх? Сейчас у меня позволяются вообще любые и я не вижу смысла в обязательной точке, например.

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

AL> Если честно, то мне видятся вполне достаточными ограничения, которые у нас на имена эх распространяются, и в этом случае.

Ладно, сойдёт, так даже проще.
Кстати, репозиторий на Гитхабе с документацией всё ещё доступен тебе для RW-доступа.

AL>> Подписался на фэху и все файлы, попадающие туда, к тебе ссыпятся автоматом. То есть они гейтуются и это в них самое вкусное. В отличии от фреков, мне видится большим преимуществом, что файлы сами будут приходить к пользователям.

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

Так я и не понял: один и тот же файл будет храниться на всех серверах? Я думал что только индексы будут гейтоваться, а файл останется на одном сервере. Да и на клиенте мне так же не хотелось бы автоматом выкачивать все файлы.

Должен быть список разрешённых символов. Он будет всяко меньше списка запрещённых и работать быстрее.

>> Подписался на фэху и все файлы, попадающие туда, к тебе ссыпятся автоматом. То есть они гейтуются и это в них самое вкусное. В отличии от фреков, мне видится большим преимуществом, что файлы сами будут приходить к пользователям.
> А вот это очень плохо. Когда у меня появятся фэхи, то поставлю квоту на фетчер не более 100 мб в день.

Мне видится, что больший объём это уже не очнь нормально. Это, в конце концов, не для обмена музыкой и фильмами, а для обмена фоточками, например, софтом (нашим, например, в виде сборок) и всякого такого. Посмотрим, как оно будет использоваться на практике и изменим квоты в соответствии.

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

На мобильном устройстве это наиболее правильное решение, ИМХО. Тот же "Горячаяя Собака Редактор", на который я уже неоднократно ссылался, вообще не поддерживает файлэхи, если мне не изменяет склероз.

> Согласен на 64 + 1024.

Консенсус! =)

> В идеале надо просто непечатаемые символы удалить, а видимые - оставить. Но не знаю, как это технически реализуется.

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

>> Если честно, то мне видятся вполне достаточными ограничения, которые у нас на имена эх распространяются, и в этом случае.
> Ладно, сойдёт, так даже проще.

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

> Кстати, репозиторий на Гитхабе с документацией всё ещё доступен тебе для RW-доступа.

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

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

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

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

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

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

Спешить же с реализацией стандарта совершенно ни к чему. Куда мы торопимся то? Джва года без файлэх жили, ещё несколько недель/месяцев проживём без проблем. Острой необходимости то нет =)

> Так я и не понял: один и тот же файл будет храниться на всех серверах? Я думал что только индексы будут гейтоваться, а файл останется на одном сервере. Да и на клиенте мне так же не хотелось бы автоматом выкачивать все файлы.

Так точно. Файлы ходят между всеми так же, как сообщения. На тему выкачивания, всегда можно отписаться. В условиях доступного интернета и файлообменников с торрентами, кидать в фэху музыку или не дай Босх фильмы, это моветон. Но! Для разного рода контента можно легко создавать разного рода фэхи. И не обязательно на них на всех подписываться.

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

> Идея-то неплохая, правда, злоупотреблять ей будут наверняка.

Ну вот как я это вижу в наших реалиях: съездил я куда-нибудь (хоть в лес, хоть поинтовку провёл), пофоткал (ага, я никогда не фоткаю, но очень хочу да), зазиповал лучшие фотки и кинул в фэху photos, например. В случае цезия я хочу ввести механизм генерации квитков в карбонке. Мол, получены файлы: имя, описание. Увидел, что что-то ссыпалось, если вдруг не заметил на экране лол, открыл, посмотрел, снёс нафиг.

> Мне тоже. Поэтому автоматом только индексы подцеплять буду.

Одна из идей мной предложена в предыдущем сообщении. Пока она мне кажется отличным компромиссом.

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

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

То есть какое-нибудь my.fecho_file1.jpg и my.fecho_text.txt?

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

У меня пока в приватный складывается. Только вот gl00my (сисоп инстед-клуба) поднял вполне закономерный вопрос. В такой ситуации имя файла должно быть уникальным во всех фэхах. Надо этого каким-то образом избежать, по пути не усложнив чрезмерно реализацию.

Продолжаю думать.

Пока пришло в голову только добавление в индекс хеша содержимого файла (fileid) и сверка имени перед сохранение с автоматической подстановкой суффикса в случае необходимости.

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

Отличная идея, полностью за. Только в какой список будем файлы (для /x/file) складывать: в приватный или публичный?

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

Нет.

Имхо, имя файла имеет смысл только при записи его клиентом себе на диск. Во всех остальных случаях ключ -- это хеш контента.
В этом смысле, обмен файлами не сильно отличается от обменом сообщениями. Но я пока не могу придумать ничего конкретного. Если появятся идеи -- напишу. В принципе, у нас 2 типа информации. 1- сам бинарный блоб и 2- метаинформация (размер, имя файла, mime???). Имхо все это может быть частью одного "сообщения". Ну почти как наши текущие :)

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

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

Именно к этому я и пришёл. Получается, UID это хеш по содержимому. А имя нода локально может и поменять (например, добавить индекс в имя перед расширением). Пока обмозговываю это. С точки зрения хранения в ФС опять таки пока не придумал как быть. Если ложить на существующий x/file, то у нас нет никакой иерархии. Только плоский список файлов. Так что или расширять имя файла именем фэхи или отказаться от x/file или усложнять x/file, что совсем не хочется.

Не было у бабы забот, так купила порося. Вот нафига я это решил делать? =)

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

Поэтому различать файлы по хэшу - это неплохая идея.

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

AL> Нет.

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

Хотя нет, не очень удобно с точки зрения юзабилити.
А вот для хранения в ФС - сгодится

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

Ну не мог я удержаться. Извиняюсь =)

2Demon: Заходишь на http://instead-games.ru/, нажимаешь кнопку "Войти" (нужен google-аккаунт). После входа появится кнопка "Загрузить игру".

ЗЫЖ На моей памяти это первый раз, когда у человека возникла проблема с загрузкой игры в репозиторий.

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

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

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

Самое важное, ИМХО.
Не обязательно монстрячить PGP. Можно взять AES или RSA. Обмен откртыми ключами - да, доверять сисопу. Т.е. теоритически может быть MitM.

Нужно хотя бы драфт накидать.

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

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

> Удобного и действительно безопасного варианта я так и не придумал. Или привлекать 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> С шифрованием, конечно, частично все упрощается. Но по моему, все таки, делать его частью стандарта не очень...

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

А так-то фильтрация по получателю будет работать в любом случае. Только на клиенте, а не на ноде. Нода пойдёт осуществлять только самое базовое обслуживание (вроде удаления через N дней).

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

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

1. Интернет не должен быть единственным транспортом
2. Никто, абсолютно никто не обязан быть доступным 24/7 (это самое важное правило, на котором построена наша сеть)
3. Один и тот же человек сегодня может подключаться к одной станции, а завтра - к другой

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

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

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

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

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

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

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

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