Отправил случайно.
Короче, только не это!!! Fixed панели это ужасно. Почти как iframe.

Обновился. Вроде баг. В списке эх нажал пометить все как прочитанные а в меню слева -- счетчик новых сообщений остался 84. При нажатии на них -- пишет, что новых сообщений нет.

Сабж! Я у тебя ее тяну.

Точный алгоритм воспроизведения.
1. Потянули вниз список эх. Фетч.
2. Справа вверху пометили все как прочитанные
3. Выдвинули шторку слева
4. Видим что там счетчик не изменился (не 0)

Все. Разобрался. :) клиент радует.

Обновился.
У меня вопрос по использованию.
В левой шторке выбрал непрочитанные. Меня бросает на первое сообщение (самое старое). Но как перейти к следующему? Кнопки перейти вперед вроде не видно (кроме той, что в конец прыгает сразу).

AD для перемещения по сообщениям -- мегаудобно! Проникся.

Другое дело, что именно за клавиши использовать. Часто (почему-то) для следующий/предыдущий -- используют пробел и backspace.
Но пробел в браузере обычно это листание страниц. Может стрелки стандартные?
Это просто наблюдение, так то WASD норм, только знать надо об этом. :)

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

Интересно.
А так ли необходимо затачиваться на x/file?
Может таки свою схему и для забора? И по fid его?
Кажется, что x/file заточен на файловое хранилище определенной структуры. Хорошо ли это?

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

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

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. Забыл вписать /. Не видел сообщения, и получил ошибку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя это вот, реальное ограничение. Но нода может выдавать по запросу public ключи своих поинтов, что возвращает нас к схеме "шифрования на клиентах". Не знаю, как то не идеально. :)

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

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

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

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

Почему то мне такой вариант нравится больше. А вам? :)

Мне личные сообщения нужны скорее в рамках "КЛУБА", есть ли смысл делать их хотя бы в пределах одной ноды? Тогда все упрощается.

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

Разве это сильно отличается от обычной почты в интернете? Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

> Так что читать чужие письма всё равно сисопы смогут.

Те сисопы, кому мы доверим. А если поинт параноит, может и PGP поверх юзать.

> Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

ЭЦП можно и без pcrypto реализовать, прямо на питоне =)

> В общем, я пока займу опять выжидательную позицию.

Если еще идеи возникнут, пиши. У меня пока тоже нет 100% ясности, что делать и делать ли вообще.

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

netmail.<authstr> -- по сути это одновременно авторизация и софт не надо менять

> Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

> Это сабо самой.

То есть, доверенные ноды тоже забирают по authstr? Как доверенная нода забирает бандл со всем net.mail?

Теперь тяну эту эху тоже. :) С idec.spline-online.tk

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

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

После экспериментов с iing возникли мысли о нетмыле, которыми хочу поделиться. Вдруг что-то из этого окажется полезным?
Но с самого начала хочу описать некое допущение, на котором строится вся идея. Допущение состоит в том, что делая запрос u/e на некую "эху", мы можем получить msgid сообщений из других эх. Ну, например, делая запрос u/e/mail.to@Peter мы получаем все сообщения к peter из разных эх. Если это, по-вашему, принципиальный изъян, то дальше можно не смотреть. =) Я и сам не считаю, что идея хорошая, но... Что-то в ней есть...

Итак, Вася пишет Пете. Он начинает новую беседу. В этот момент создается сообщение с эхой вида: private-<magic>. Где magic это, например, hash(authstr + date). Тут возможны варианты. Например, дать автору формировать часть названия "беседы". Например private-gaming-<magic>. Это не важно, главное, что это автоматизированное создание скрытоэхи.

Далее, я уже писал про метаэхи типа mail.to@Peter. Вот, подписавшись на эху, например, netmail@<authstr> -- Петя будет получать все сообщения на ноде, которые адресованы ему, и автоматом получит сообшение от Васи с созданием эхи private-<magic>. Далее, Петя может ответить в эту приватную эху как обычно, и продолжить беседу. Потом Петя. Все в рамоках уже открытой скрытой эхи.

Это все прекрасно может работать в пределах 1й ноды. При этом, без доработки клиентского софта. Но как же связь между нодами?

А так-же. На ноде создаются эхи netmail@<nodestr> (для безопасности, можно несколько, с разным nodestr) И нодам отдаются эти эхи. Само собой, это все названия одной и той же метаэхи, которая отдает все сообщения приватных эх private, для сообщений, которые не принадлежат данному узлу.

Старая идея о зачистке сообщений транзитных для данного узла через н дней остается в силе.

А зачем так делать, если можно сделать просто одну эху netmail и все разруливать в рамках этой 1й эхи? На мой взгляд плюсы моей схемы:

1) разные беседы могут быть в разных приватных эхах. Это удобно. Все личные сообщения в рамках одной netmail -- имхо, не очень удобно.
2) клиентский софт менять не надо (или почти не надо), главное, чтобы фетчер честно тоссил сообщения в те эхи, которые прописаны в заголовках сообщений
3) в рамках 1й ноды делается вообще все с пол пинка (собственно, это и была первоначальная идея -- сделать лс в пределах инстед клуба)

Что мне НЕ нравится:
1) не читабельные имена эх. генерируемых автоматически. Но, может, терпимо?

Если есть мысли, с интересом жду. :)

> 502 Bad gateway :(
Я все перенес на http://club.syscall.ru

P.S. Оказывается, у меня был сломан фетчер все выходные. :) Починил...

Хочу поделиться мыслями по поводу моих экспериментов с iing. :) К сожалению, не удержался, и расколбасил iing так, что теперь мержится будет довольно сложно :)

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

В итоге я ввел такое понятие, как виртуальная эха, на которой сделал и карбонки и поиск. Как это выглядит. Например:

mail.to@Peter -- это виртуальная эха, которая показывает все сообщения для Peter. @ - признак виртуальной эхи. То, что справа -- параметр по сути выборки.
По сути, можно сделать запрос http://club-test.syscall.ru/u/e/mail.to@Peter и получить список msgid карбонки.

Дальше -- хуже. Что такое поиск?

query.ea@запрос

Где запрос:

эха:регулярное выражение

Очевидно, что эха и регулярное выражение, должны быть urlsafe, поэтому я кодирую их в base64.

Дальше, хуже. Так как начинают работать поиск в поиске (просто как суперпозиция query.ea), RSS на любые поисковые запросы и карбонки. Счетчики непрочитанных сообщений. Ну и так далее.. Так как это все просто эхи.

Пример страшного вложенного запроса:
http://club-test.syscall.ru/query.ea@query.ea%40query.ea%40pipe.2032%3A0KDQvtC80LA%3D%3AaWk%3D:0L7QsdGB0YPQtg%3D%3D

Скорее всего то, что я сделал -- ужасно и я это осознаю. =) Сейчас я думаю, что делать дальше и делать ли вообще. Но как эксперимент, мне показалось интересным. Обкатываю пока на http://club-test.syscall.ru

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

Да, поиск сделан плохо и медленно. По сути регулярные выражения. Но скорости для поиска в пределах эхи вроде бы достаточно... Пока не пушился. Если есть какие-то мысли, отпишись. :)

> Только я за то, чтобы название скрытоэхи генерировалось на клиенте

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

Изменил кое-что, так что ссылка из прошлого сообщения не работает.
Аналог выборки:
http://club-test.syscall.ru/query.ea@query.ea%40ii.14%400KDQvtC80LA%3D@bGludXg%3D
Или:
http://club-test.syscall.ru/u/e/query.ea@query.ea%40ii.14%400KDQvtC80LA%3D@bGludXg%3D

> Ну оно сильно не отличалось с точки зрения запросов. Просто всё в одной эхе "netmail", а не раскидано по нескольким.
А что с адресацией? Как по твоему, достаточно ли просто имени? Или что то вроде <syscall,1> становится адресом назначения?

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

Подумал и понял, что отличий между моей схемой и схемой с 1й эхой не так уж и много.
1. Забор nemail поинтом подразумевается по authstr. У меня это часть имени метаэхи. А у тебя какой будет запрос AL?
2. В моем случае в запрос попадают мессаги с echoarea приватных эх, но это может быть и одна эха. Технически очень близко.
3. Ноды забирают друг у друга нетмыл тоже по authstr. Как будет выглядеть запрос у тебя?

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

Не отмалчиваемся. :)

> Короче, пока я воздержусь от особого комментирования
Наоборот, лучше разверни мысль.
Почему куча эх для единичных сообщений? Эха создается в первый раз, а потом в нее пишут абоненты. Скорее, обычно это будет 1 эха на 1 собеседника. Ответ же делается в уже созданную эху.
Существенная переделка клиента. В чем она состоит?

> приходилось продираться через кашу приватных и публичных конференций. И вот это вот всё.
По идее, даже без переделки все приватные будут рядом. И тут вариант: или 10 скрытоэх как 10 личных топиков с 10 людьми, или в одном netmail беседа с 10 разными людьми. В первом варианте есть возможность как то организовать это дело. Во втором -- в принципе тоже. Но за счет уже анализа to. Но раз это примерно одно и то же, а первое вроде бы проще, кажется что вариант не такой уж пропащий. Я наоборот хотел бы пообсуждать, но если идея в корне не нравится, не настаиваю.

Ну или распиши подробно твою схему? Как сообщения создаются? Как забираются поинтом и нодой с тз запросов?

Итак, сделал концепт. Работает на http://club-test.syscall.ru. Можете хулиганить ;) (Но не сильно) Базу потом грохну. Что сделано:

1) Написание нового сообщения -- нажать на конвертик в ленте сообщений, или перейти по адресу: http://club-test.syscall.ru/private (нужно быть залогиненным). При написании сообщения создается эха: private.<magic>, где на данный момент magic это hash(authsr + time).lower(). Можно сделать это из цезия, главное создать эху private.что то.

2) в поле to ставится или имя просто Peter (и тогда это сообщение будет локальным для данной ноды), или что то вроде <mira,1>. Во втором случае, если окажется, что адрес локальный -- он сам преобразуется в имя во время записи сообщения. То есть. на моей ноде <syscall,1> превратится в Peter. Это служит признаком локальное это сообщение или транзитное.

3) все сообщения, что не являются локальными (адреса to в форме <...>), доступны в эхе net.mail@authsrs для забора нетмыла другими зулами. На данный момент, в целях тестирования - authstr может быть любым. Так что можете потестить и рассказать что вы думаете.

Если раньше я сомневался в жизнеспособности схемы, то теперь она мне очень нравится. :) Все впилилось очень просто. В крайнем случае будет работать ЛС в рамках одного syscall.

Пишите ваши мысли. :) Можете баловаться с http://club-test.syscall.ru

Да, недокоммитил. Через два часа буду дома и исправлю. Пока работают только лс :)))

Да, чуть не забыл. Личные сообщения видны в эхах: mail.to@authstr (входящие) и mail.from@authstr (исходящие)
На самом деле, это вообще все входящие и исходящие сообщения пользователя, но там будут и лс.

> Вариант Петра хорош тем, что "скрытоэхи" для совместных бесед автоматически прокидываются на фетч между станциями.
Да, думал об этом тоже.

Сегодня думал о других вариантах, в том числе и с одной эхой как у AL. И понял, что есть еще одна "фича" моего варианта.

Она состоит в том, что у мессаг стоит "честная" эха. То-есть, оно укладывается в существующую архитектуру полностью. Синхронизация с клиентами будет стандартной.

То-есть, если это не так, представьте себе, вы шлете сообщение. Какое echoarea ставить? Допустим, net.mail. В случае единственной эхи как у AL.
Тогда нужно мудрить особую обработку net.mail эхи, для того, чтобы юзер не мог ее фетчить. Нужно уметь синхронизовать себя с сервером.

То-есть чисто архитектурно, посылка сообщения -- это запись в эху как не крути.

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

Короче, я в качестве эксперимента начну делать следлующее.

1) адресация. Peter или <syscall,1> - так как имена могут пересекаться на разных нодах
2) забор своих сообщений через метаэху net.mail@authstr (само собой это не аксиома, просто у меня так сейчас проще, но метод забора может быть любым).
3) на веб ноде я сделаю кнопку -- начать беседу, которая будет создавать сообщение в скрытой эхе

по результатам опыта отпишусь...

> Вот это будет вообще зло, ИМХО. То есть будут эхи, которые я бы и не хотел гейтовать, но выбора у меня не будет. Почему бы тогда не гейтовать вообще все существующие эхи? В чём принципиальное отличие?

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

> Вот это вообще не очень. Хотя, смотря какой таймаут.
Я думал для конечных нод -- не стирать.
Для транзитных, несколько дней. Просто стирать, скажем, по крону транзитные сообщения старше 10 дней (например).

Вопрос, какая эха прописана в сообщениях? Одна и та же у всех? Попробуй начать делать, и мне кажется, ты столкнешься с проблемами.
Ведь эха вроде бы есть, но каждому показывается только то, что он видит. Это оч хитрый механизм. Кроме того, эта эха не должна быть видима по стандартной схеме u/e.
Жаль, что тебе не понравилось. :( тогда лс будет только в рамках клуба. :(

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

А я же частично описал это, ты не прочитал. =)
1) Если я пишу сообщение Andrew Lobanov - это автоматически становится локальным адресом, действующим только в рамках моей ноды. Такие сообщения _не отдаются_ другим нодам.
Я должен написать на адрес <mira,1> и при приеме сообщения от поинта на ноду, нода увидит что поинт не на этой ноде и будет раздавать такие сообщения другим нодам.
На станции mira, <mira,1> превратится в vit01 (to станет локальным адресом) и на этом путь сообщения закончится.

2) вот тут да, адрес это всегда конкретика. Ты это не имя, а адрес на узле. Взамен можно предложить только что то вроде <mira,1> <syscall,13> ну и так далее -- типа множественные адреса...

> Хаки же на то и хаки, что там всё не так просто, как кажется с первого взгляда.
Я тут понял, что завязка на имя эхи вроде как не нужна.

По идее, единственное что нужно, анализ поля to. Если в нем есть адрес типа <>, то это личное сообщение....