Давно не было новостей сабжа.

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

Следующим шагом будет поддержка файлэх.

Добавил таки документацию по фэхам в extensions.md. Просьба оценить внятность.

Также немного поправил раздел про схему /x/c, указав все возможные подстроки для декларирования поддерживаемых расширений.

Посмотрел, вроде, всё устраивает. Закинул на сайт. Потом надо будет ещё английскую подправить доку.

// Стыдоба, Андрей. Существительное длина пишется с одной "н". С двумя - только в форме краткого прилагательного :)

vit01> // Стыдоба, Андрей. Существительное длина пишется с одной "н". С двумя - только в форме краткого прилагательного :)

Мне норм =)

Пальцы заплетаются иногда, а вычитка для неуверенных в себе %)x

Окей. Тогда ставь 120 символов (как для эхи) и прописывай в стандарт.

Только что добавил в клиент очень вкусную фичу - обновление отдельных сообщений с сервера

Например, сослался кто-нибудь на определённое сообщение из индекса, которого у вас в базе нет
Пусть это будет ii://vEdu4F7rwud6zDIpLAZ1

Тыкаете в клиенте на ссылку и видите там [ничего]. Теперь можно зайти в меню и нажать кнопочку "Обновить с сервера". Хоп - и уже готово для прочтения.

Также фича может быть полезна, если у вас есть нода с админкой, чтобы заменять уже существующие сообщения в базе.

Добавил инфу про схему f/list.txt.

Не спешите обновляться. Там какая-то хрень дубли плодит =)

Сабж теперь хранит сообщения в sqlite-базе. Просьба потестировать всех желающих помочь проекту.

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

Баг найден. Добавлена поддержка файлэх.

Сабж обновлена до актуальной версии iing. Теперь в полном объёме поддерживает файлэхи.

На сегодня в обновлении ничего особо серьёзного, однако:

1. Повысилась информативность вывода фетчера (цифры при загрузке корректные + в целом получше)
2. Окно помощи полностью переделано, добавлен раздел для новичков (кстати, он будет выскакивать при первом запуске)
3. В репозитории теперь есть почти пустое README.md

Народу, который сейчас решит обновиться, я дам "на подумать" ссылку вот сюда:
https://github.com/vit1-irk/idec-mobile/blob/master/app/src/main/res/values/strings.xml

Особенно пункты help_about и help_newbie. Причём первый говорит сам за себя :) И за мою лень тоже говорит.

Попробовал установить ради интереса. В целом работает нода, норм всё, но есть несколько "но":

1. Сразу после скачивания из Git запускаю iing.py, жалуется на отсутствие конфига. Хорошо, копирую стандартный. Но, думаю, для развёртки на продакшене людям было бы приятнее и удобнее, если скрипт всё скопирует, даст парочку советов и интерактива.

Например, что-то вроде этого (только по-английски, наверное):

Запускаем ноду в первый раз, копируем конфиги...
Поправьте iing.cfg для настройки станции, образец в README

Создание первого пользователя

Имя: [user1] <Enter>
Пароль: [xxxxxx] <Enter>
Ещё раз: [xxxxxx] <Enter>

Authstr: yyyyyyyyyy, в дальнейшем запускайте points.py, чтобы создать нового юзверя

Listening on 0.0.0.0:3000.... ну и так далее

2. points.py также жалуется при первом запуске на отсутствующий points.txt. Это тоже минус для юзабилити. Написать пару строчек с проверкой и touch() лично тебе несложно, а юзверю хлопот меньше.

3. И уже настоящий косяк, на который нельзя закрывать глаза: iing позволяет создавать пустые сообщения через веб-интерфейс (т.е. пустые сабж и/или тело). По стандарту (да и просто ради отзывчивости интерфейса) оба поля обязаны заполняться. Тогда хотя бы проверку на JS набросай, если лень в основном коде копаться.

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

Например, взять ту же ii-php. Вроде бы, под капотом и в плане API есть неплохие наработки (особенно по транспорту), однако вебморда настолько негибкая, что новые фичи туда фиг добавишь. Увы, практически монолит. Придётся как-то перерабатывать фронтенд с точки зрения архитектуры.

Или CutieFeed. Лично для себя считаю его очень хорошим и юзабельным в момент "здесь и сейчас", но к новым изменениям и в GUI, и по транспорту он почти не готов. Либо втискивать новые фичи в устоявшийся костыль, либо пытаться найти новую парадигму для написания под Qt.

Чё-то делать надо...

C python-софтом (включая Цезий и iing) ситуация в целом как зоопарк. Несколько людей пытаются одновременно реализовывать одни и те же вещи, тратя на них больше времени и усилий, чем нужно.

Предлагаю написать единую библиотеку idec-python, которая будет одинаковая для всех серверов и клиентов, позволяя абстрагироваться разработчикам от самых базовых вещей вроде парсинга сообщений, БД-транспортов, хэширования, эхофильтров, стандартов. Это позволит нам сосредоточиться на GUI, сэкономит кучу времени, даст работать гораздо более эффективно.

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

// Мечтать не вредно...

vit01> Попробовал установить ради интереса. В целом работает нода, норм всё, но есть несколько "но":

Исправил все три замечания. Спасибо большое за тестирование. Глаз уже замылился с этим всем =)

vit01> Попробовал установить ради интереса. В целом работает нода, норм всё, но есть несколько "но":

vit01> 1. Сразу после скачивания из Git запускаю iing.py, жалуется на отсутствие конфига. Хорошо, копирую стандартный. Но, думаю, для развёртки на продакшене людям было бы приятнее и удобнее, если скрипт всё скопирует, даст парочку советов и интерактива.
vit01> 2. points.py также жалуется при первом запуске на отсутствующий points.txt. Это тоже минус для юзабилити. Написать пару строчек с проверкой и touch() лично тебе несложно, а юзверю хлопот меньше.

Блин. Это було утеряно случайно при перепилинге не sqlite. Не спрашивай как - я не знаю =)

vit01> 3. И уже настоящий косяк, на который нельзя закрывать глаза: iing позволяет создавать пустые сообщения через веб-интерфейс (т.е. пустые сабж и/или тело). По стандарту (да и просто ради отзывчивости интерфейса) оба поля обязаны заполняться. Тогда хотя бы проверку на JS набросай, если лень в основном коде копаться.

А вот это реальный баг. Пофикшу.

AL>> Исправил все три замечания.
vit01> А вот и не все. Чистая нода из репозитория всё так же валится при запуске, жалуясь на отсутствие конфига.

Опа о_О

vit01> Если я скопирую конфиг вручную и попробую её запустить снова, то она даже не выдаст предупреждения, что points.txt пуст (и что его следовало бы наполнить чем-то).

Мне казалось, что это логично. Открываем вебморду и регистрируемся =)

vit01> Кстати, ещё заметил, что если в points.py не до конца указать параметры командной строки (например, только -u user, без пароля), то скрипт не обрабатывает исключение, а вываливает Traceback. Тоже непорядок.

Пофикшу.

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

Да я сделаю. Мне не лень. Просто работа и всякие другие дела (я утерял диплом армейским способом и сейчас восстанавливаю). А ещё новую игру на инстеде пишу =)

В мире очень много интересного и на всё просто не хватает времени. На этой неделе пришлось пожертвовать сном немного. Так что сейчас лучше в код не лезть. Завтра поправлю эти мелкие недоразумения.

ЗЫЖ А ещё я купил sunvox под андроид и это очень классная штука даже на 5" тачскрине и она тоже пожирает моё время =)

vit01> Предположим, человек хочет развернуть ноду. Обычно порядок действий таков:
vit01> 1. Качаем репу, ставим зависимости
vit01> 2. Запускаем скрипт
vit01> 3. Пытаемся получить поинта и написать "test"
vit01> 4. Если всё норм, настраиваем эхи и фетч
vit01> Пункты 2 и 3 проще совместить, чтобы всё было "не отходя от кассы".

Куда тут отходить то? Даже директорию менять не надо =) Я искренне не понимаю зачем это.

vit01> Также можно облегчить пункт 4, дав небольшие подсказки, и/или сразу конфиг подогнать.

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

AL> Исправил все три замечания.

А вот и не все. Чистая нода из репозитория всё так же валится при запуске, жалуясь на отсутствие конфига.

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

Кстати, ещё заметил, что если в points.py не до конца указать параметры командной строки (например, только -u user, без пароля), то скрипт не обрабатывает исключение, а вываливает Traceback. Тоже непорядок.

----

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

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

1. Качаем репу, ставим зависимости
2. Запускаем скрипт
3. Пытаемся получить поинта и написать "test"
4. Если всё норм, настраиваем эхи и фетч

Пункты 2 и 3 проще совместить, чтобы всё было "не отходя от кассы". Также можно облегчить пункт 4, дав небольшие подсказки, и/или сразу конфиг подогнать.

vit01>> Если я скопирую конфиг вручную и попробую её запустить снова, то она даже не выдаст предупреждения, что points.txt пуст (и что его следовало бы наполнить чем-то).

AL> Мне казалось, что это логично. Открываем вебморду и регистрируемся =)

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

AL>> Мне казалось, что это логично. Открываем вебморду и регистрируемся =)
vit01> Не все пользуются вебмордами. Можно хотя бы спросить юзера, вроде того, хочет он создавать первого поинта или нет.

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

vit01>> 2. Запускаем скрипт
vit01>> 3. Пытаемся получить поинта и написать "test"
vit01>> Пункты 2 и 3 проще совместить, чтобы всё было "не отходя от кассы".

AL> Куда тут отходить то? Даже директорию менять не надо =) Я искренне не понимаю зачем это.

Про points.txt и points.py в твоём README нет ни слова (значит логично было бы пустить их в дело сразу же), плюс нододержатель так или иначе пойдёт сам этой нодой пользоваться (как минимум ради теста). Мелочь, а приятно.

AL> Какого рода подсказки? Есть README, а конфиг, как только дойдут руки, будет копироваться автоматом из умолчального.

Например, после копирования конфига предложить сисопу его сначала поправить в редакторе, а затем только ноду запустить. В *nix системах можно даже $EDITOR брать на вооружение, чтобы ускорить процесс.

-----------

Кажется, мы опять обсуждаем какие-то малозначащие мелочи вместо того, чтобы заниматься делом :) Все эти штуки можно и не делать, но если сделаешь, будет чуточку приятнее.

Прошу высказаться насчёт идеи idec-python отсюда: ii://dvUD1leZtApAyB5AlwUC, и ещё хотелось бы услышать пожелания по поводу того, как строить GUI для фэх

AL>> Куда тут отходить то? Даже директорию менять не надо =) Я искренне не понимаю зачем это.
vit01> Про points.txt и points.py в твоём README нет ни слова (значит логично было бы пустить их в дело сразу же), плюс нододержатель так или иначе пойдёт сам этой нодой пользоваться (как минимум ради теста). Мелочь, а приятно.

Ну как минимум ридми я к 0.4 цезия поправлю да =)

AL>> Какого рода подсказки? Есть README, а конфиг, как только дойдут руки, будет копироваться автоматом из умолчального.
vit01> Например, после копирования конфига предложить сисопу его сначала поправить в редакторе, а затем только ноду запустить. В *nix системах можно даже $EDITOR брать на вооружение, чтобы ускорить процесс.

А вот это мысль. Надо будет сделать.

vit01> Кажется, мы опять обсуждаем какие-то малозначащие мелочи вместо того, чтобы заниматься делом :) Все эти штуки можно и не делать, но если сделаешь, будет чуточку приятнее.

У меня сейчас в плане но я скорее хотел фэхи и sqlite чтобы gl00my мог перейти на iing.

vit01> Прошу высказаться насчёт идеи idec-python отсюда: ii://dvUD1leZtApAyB5AlwUC

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

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

vit01> и ещё хотелось бы услышать пожелания по поводу того, как строить GUI для фэх

Ты пробовал запустить iing, закинуть что-нить в фэху и получить это с помощью цезия? Как один из вариантов реализации. Если же говорить о idec-mobile, то не проще ли сразу кидать полученные нодой файлы на фреки, как это сделано в той же iing?

Вот как лучше сделать приватные фреки в вебморде? Потому как authstr теперь передаётся только через POST-запрос. Есть мысли?

AL> Что ещё туда можно запихнуть?

Как минимум, обработка тегов, работа с msgline, пара двустрочников для base64, упрощение работы с бандлами.
Также парсинг значений /x/c, строк /x/file, list.txt, тех же фэх

Вот посмотри сюда: https://github.com/vit1-irk/idec-mobile/blob/master/app/src/main/java/vit01/idecmobile/Core/IIMessage.java
Здесь, конечно, не всё необходимое (отсутствует перевод в бандл-строку, например), но в своей основе вынос работы с сообщениями с глаз долой был бы очень удобен в нашем малокачественном python-коде.

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

Из того, что сверх протокола, неплохо бы прикрутить функции для работы с сетью (думаю поделиться проксификацией через lib-socks-proxy и поддержкой таймаутов).

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

AL> Ты пробовал запустить iing, закинуть что-нить в фэху и получить это с помощью цезия? Как один из вариантов реализации.

Попробовал зафетчить фэху pictures с помощью Цезия. GUI здесь по факту отсутствует, хотя реализация и рабочая. Хотелось бы для CutieFeed'а что-нибудь и для IDEC Mobile, чтобы самому выбирать, какие файлы скачивать, и чтобы более-менее прилично выглядело.

AL> Если же говорить о idec-mobile, то не проще ли сразу кидать полученные нодой файлы на фреки, как это сделано в той же iing?

Проще, но ведь всё равно не очень полноценно с точки зрения юзабилити. Пока что попробую реализовать только Upload-диалог, а там посмотрим.

AL> Вот как лучше сделать приватные фреки в вебморде? Потому как authstr теперь передаётся только через POST-запрос. Есть мысли?

В вебморде можно всё в куки складывать и по ним проверять. Только проверку на csrf сделать ещё.

Очень здравая мысль!

Нужно так и делать.

Вынес в либу реализацию на Go -- https://github.com/Difrex/go-idec.

Фетчер и dynamic сегодня или завтра на нее переедут.

В экспериментальном режиме: http://club.syscall.ru:3000/
База юзеров перенесена с клуба.
Нода только фетчит эхи инстед (с того же клуба).

IDEC Mobile переведён на английский язык!

Уделено внимание даже таким мелочам как дефолтный конфиг (т.е. русским пользователям подставляется Станция мира и Таверна, а всем остальным Mira Station и Tavern).

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

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

У сабжа появился параметр nosubscription, убирающий механизм подписок в веб-интерфейсе.

// Это всё пока делается для перехода инстед клуба на сабж.

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

// Спасибо, vit01 =)

AL>> Что ещё туда можно запихнуть?
vit01> Как минимум, обработка тегов, работа с msgline, пара двустрочников для base64, упрощение работы с бандлами.
vit01> Также парсинг значений /x/c, строк /x/file, list.txt, тех же фэх

Ну это я к реализации протокола отношу у себя в голове =)

vit01> Вот посмотри сюда: https://github.com/vit1-irk/idec-mobile/blob/master/app/src/main/java/vit01/idecmobile/Core/IIMessage.java
vit01> Здесь, конечно, не всё необходимое (отсутствует перевод в бандл-строку, например), но в своей основе вынос работы с сообщениями с глаз долой был бы очень удобен в нашем малокачественном python-коде.

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

AL>> Всё, что сверх протокола завязывается уже на конкретный способ хранения и отображения и уже не совсем понятно как добиться универсальности.
vit01> Из того, что сверх протокола, неплохо бы прикрутить функции для работы с сетью (думаю поделиться проксификацией через lib-socks-proxy и поддержкой таймаутов).

А вот я думал над этим. В итоге пришёл к мнению, что переменных http_proxy и https_proxy достаточно. Хотя, еси пускать под виндой, то таки да.

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

Ну это как минимум к выкидыванию кучи уже рабочего кода.

vit01> Попробовал зафетчить фэху pictures с помощью Цезия. GUI здесь по факту отсутствует, хотя реализация и рабочая. Хотелось бы для CutieFeed'а что-нибудь и для IDEC Mobile, чтобы самому выбирать, какие файлы скачивать, и чтобы более-менее прилично выглядело.

Просто если ты на десктопе подписан на фэху, то зачем какой-либо GUI? Сфетчилось и сфетчилось. Главное - квиток в почту и файлы описаний для разгребания.

AL>> Если же говорить о idec-mobile, то не проще ли сразу кидать полученные нодой файлы на фреки, как это сделано в той же iing?
vit01> Проще, но ведь всё равно не очень полноценно с точки зрения юзабилити. Пока что попробую реализовать только Upload-диалог, а там посмотрим.

Ну вот надо подумать. Как вариант, можно парсить имена файлов на предмет "/" и эмулировать подкаталоги в гуи работы с фреками.

AL>> Вот как лучше сделать приватные фреки в вебморде? Потому как authstr теперь передаётся только через POST-запрос. Есть мысли?
vit01> В вебморде можно всё в куки складывать и по ним проверять. Только проверку на csrf сделать ещё.

Ну можно действительно отвязаться от протокола. Как-то в голову не пришло =)

AL> Просто если ты на десктопе подписан на фэху, то зачем какой-либо GUI? Сфетчилось и сфетчилось.

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

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

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

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

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

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

В идеале в моих фантазиях клиенты и нода будут различаться только своими GUI. То есть будет нечто вроде idec-base, к которому по желанию прикручиваются bottle-модуль, ncurses-модуль, qt-модуль и так далее.

В мобильном виде вроде не работает. :)
В не-мобильном все ок.

Что на сегодня:

1. Учтены замечания Петра
2. Попытался починить очередной баг с падением

Всем обновиться!

Peter> Из замечаний: все таки стоит добавлять / к урлу станции, если его не ввели, имхо.

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

vit01> Что на сегодня:

vit01> 1. Учтены замечания Петра
vit01> 2. Попытался починить очередной баг с падением

vit01> Всем обновиться!

Обновился! Полет нормальный.

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

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

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

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

Пробросил обратный фетч с http://club.syscall.ru:3000/
Теперь, теоретически, можно пользоваться как gk11 интерфейсом на http://club.syscall.ru,
так и iing интерфейсом на http://club.syscall.ru:3000/
Если что-то пойдет не так, пишите... =)

Наконец, обновил. Клиент стал мега-крутым!
Из замечаний: все таки стоит добавлять / к урлу станции, если его не ввели, имхо.
И кнопку написать новое сообщение сделать можно рядом с ответить. Но это все мелочи! В целом, мега удобно!

vit01> Он и так добавляется. Просто предупреждение выдаётся, дабы человек запомнил. Но могу его убрать.

Я обновил клиент и отредактировал ноду, дописав к урлу :3000. Забыл вписать /. Не видел сообщения, и получил ошибку.

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

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

Мне кажется, что сначала, нужно решить проблему синхронизации поинтов.

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

Либо можно придумать скрытоэху, которая синкается всеми. В ней можно устроить e2e шифрование, например с GPG ключами. На ноде хранить сообщения от туда по-минимуму. Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

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

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

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

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

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

> Либо можно придумать скрытоэху, которая синкается всеми. В ней можно устроить e2e шифрование, например с GPG ключами. На ноде хранить сообщения от туда по-минимуму. Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

Вот этот вариант по сути и предложил vit, а я думаю в сторону возможности работы без gpg. В приниципе, мы уже повторяемся. Значит, все идеи уже кончились?

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

Еще бы послушать мнение Андрея.

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

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

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

Согласен, этот вариант тоже мне не нравится.

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

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

Моя идея на фетчинге, если ее упростить/уточнить.

Фетч для абонента (избранные сообщения netmail). Эха доступна для фетчинга по authstr, при этом забираются только те сообщения, которые адресованы этому абоненту.

Фетч для ноды (вся почта netmail). Доверенный фетчинг всей эхи нодой, но степень доверия строится на ЭЦП. На худой конец, тоже по authstr.

Все узлы, которые не обслуживают данного поинта, стирают netmail сообщения спустя n дней.
Узел, обслуживающий поинта -- не стирает. Или стирает после забора поинтом. Короче соответствует твоему 2 пункту.

Что мне не нравится. Не нравится 2 разных типа фетичнга. Клиент (забирает свое). И нода (забирает весь нетмыл).

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

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

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

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

Difrex> На самом деле никому ключ передавать не нужно. Можно воспользоваться тем же pgp.mit.edu. Либо, чтобы сисоп поднял sks и грузить ключик туда. Это не сложно =)

Почесал репу и подумал, что всё-таки это хорошая идея.

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

В теории, мы можем потребовать уникальности. В любом случае, описанные атаки, не совсем атаки. Так как любая нода может забрать netmail если она доверена.
Доверенность подтверждается ЭЦП. Так что я не понял суть твоего примера до конца. Если я доверяю твоей ноде, и убеждаюсь с помощью ЭЦП в аутентичности твоих запросов, почему бы мне и не слить тебе netmail?

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

Вероятно, так и есть. :( Для меня, это выглядит скорее как отсутствие перспектив на netmail.