btimofeev> А как их получать? В цезии нужно фэхи прописывать в конфиге? По умолчанию он мне пишет новых файлов не найдено.

Разобрался. Нужно в конфиг добавить "fecho имя_фэхи". В readme бы добавить это.

AL> Проанализировал логи и заметил, что фэхи с меня узлы не тянут (или тянут с отличным от эх периодом).

Станция мира фетчит фэхи на таверне раз в 20 минут.
Но я решил сделать проверку и увидел, что фетчер отказывается скачивать оттуда 3 файла.

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

// IDEC Mobile автоматически преобразует имя файла через toLower(), поэтому через него грузить безопасно.

vit01> Итак, IDEC Mobile получает начальную поддержку файловых эх

Очень здорово сделал, хотя пока и есть пара вопросов.

При скачивании файла появляется пустое активити с заголовком <null>. Но я так понял, это временное явление.

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

AL> В таверне на данный момент есть следующий фэхи:

А как их получать? В цезии нужно фэхи прописывать в конфиге? По умолчанию он мне пишет новых файлов не найдено.

Обновление IDEC Mobile!

Интерфейс фэх стал более отзывчивым, исправлены вчерашние баги, о которых было сообщено.
Также есть новые фичи:

1. Клиент теперь обрабатывает событие "Поделиться" от сторонних приложений. Можно отправлять файлы в фэхи напрямую из галереи, файлового менеджера или какого-нибудь мессенджера

2. Из режима чтения по просьбе Андрея теперь можно делиться сообщениями из Секты в plain-text, например, по Email/SMS/чтоугодно.

vit01> В общем, в стандарт гоним вот это
vit01> ====
vit01> [A-Za-z0-9_!-.]{1,60}.[A-Za-z0-9_!-]{1,60}
vit01> ====

Пушнул. Заодно улучшил вебморду.

vit01> А ещё прокидываю фэху ii://file.wishes, куда будем писать всякие пожелания по поводу того, чем поделиться, а также всякие перезаливы, отзывы по файлам и так далее.

Эху прокинута в таверну.

btimofeev> А чем плохи заглавные буквы в именах файлов?

В общем, ничем не плохи. Просто в стандарте прописано не было, вот я и решил перестраховаться. Скоро будет поддерживаться.

vit01> Обновление IDEC Mobile!
vit01> Интерфейс фэх стал более отзывчивым, исправлены вчерашние баги, о которых было сообщено.

Круто. Но ещё есть одно но. После скачивания или открытия список прыгает в самый низ. Это весьма сбивает с толку.

Обновления по фэхам на сегодня

1. Исправлен баг с прокруткой списка в конец
2. Опция "Поделиться" для файлов (длинное нажатие)
3. Копирование fid в буфер обмена
4. Если файл криво скачался (т.е. повреждён), то алгоритм предложит его либо удалить, либо открывать на свой страх и риск
5. К скачанному содержимому фэх теперь можно дотянуться из сторонних приложений в диалоге выбора файла. (работает на Android 4.4 и выше)
6. Всё допереведено на русский (мелочь, но всё равно)

Сегодня у меня был тяжёлый день, проведённый в документации Google и на StackOverflow, поэтому крутые фичи под пунктами 2 и 5 требуют того, чтобы вы их оценили.

vit01> У меня на станции стоят строгие регулярки, по которым имя файла разрешается только в lowercase (как имя эхи). Вроде бы, мы именно так по стандарту и договаривались, не?

А чем плохи заглавные буквы в именах файлов?

В общем, в стандарт гоним вот это

[A-Za-z0-9_!-.]{1,60}.[A-Za-z0-9_!-]{1,60}

А ещё прокидываю фэху ii://file.wishes, куда будем писать всякие пожелания по поводу того, чем поделиться, а также всякие перезаливы, отзывы по файлам и так далее.

vit01>> У меня на станции стоят строгие регулярки, по которым имя файла разрешается только в lowercase (как имя эхи). Вроде бы, мы именно так по стандарту и договаривались, не?
AL> Я был уверен, что любые буквы латиницы =)

Проверил стандарт. Там вообще ограничения на имена файлов не оговорены. Надо договориться пока не поздно =)

После экспериментов с 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

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

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

Мне нравится эта идея. Не, серьёзно.

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

Терпимо. Только я за то, чтобы название скрытоэхи генерировалось на клиенте (даже если это хэш(authstr + дата)). А сервер будет только по алгоритму делать проверку.
То есть если название эхи называется с "__private.", то лишь тогда относить её к нетмейлу.

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

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

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

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

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

502 Bad gateway :(

Изменил кое-что, так что ссылка из прошлого сообщения не работает.
Аналог выборки:
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 собеседника. Ответ же делается в уже созданную эху.
Существенная переделка клиента. В чем она состоит?

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

Ну оно сильно не отличалось с точки зрения запросов. Просто всё в одной эхе "netmail", а не раскидано по нескольким.

Грубо говоря:

== Запрос нетмейла поинтом

POST /n/p
pauth=<pauth>
slice=start:end

Возвращает индекс нетмейла для конкретного поинта.


POST /n/pm
pauth=<pauth>
msgids=<msgid1>/<msgid2>/.../<msgidN>

Запрос бандла нетмейла. Естественно, нода проверяет принадлежность сообщения этому поинту и запросить чужое сообщение, зная его msgid, не получится.


== Запрос нетмейла доверенной нодой

POST /n/n
password=<password>
slice=start:end

Индекс нетмейла для обмена между узлами сети.


POST /n/nm
password=<password>
msgids=<msgid1>/<msgid2>/.../<msgidN>

Запрос бандла доверенной нодой.
----

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

При этом мой вариант мне больше нравится идеологически =)

// Делать будем в любом случае так, как проголосуем.

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

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

Десять собеседников -- десять эх.

> Существенная переделка клиента. В чем она состоит?

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

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

Итак, сделал концепт. Работает на 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

>Работает на http://club-test.syscall.ru

Error: 500 Internal Server Error

Sorry, the requested URL 'http://127.0.0.1:3001/new/std.tech' caused an error:

Internal Server Error

Exception:

NameError("name 'addr' is not defined",)

Traceback:

Traceback (most recent call last):
  File "/home/peter/git/iing.club-test/api/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/peter/git/iing.club-test/api/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/peter/git/iing.club-test/api/web.py", line 319, in reply
    return template("tpl/reply.tpl", nodename=api.nodename, dsc=api.nodedsc, echoarea=echoarea, msgid=msgid, msg=msg, auth=auth, hidehome=False, topiclist=False, background=api.background)
  File "/home/peter/git/iing.club-test/api/bottle.py", line 3595, in template
    return TEMPLATES[tplid].render(kwargs)
  File "/home/peter/git/iing.club-test/api/bottle.py", line 3399, in render
    self.execute(stdout, env)
  File "/home/peter/git/iing.club-test/api/bottle.py", line 3386, in execute
    eval(self.co, env)
  File "/home/peter/git/iing.club-test/tpl/reply.tpl", line 15, in <module>
    %to = addr or "All"
NameError: name 'addr' is not defined

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

Потому что мухи отдельно, котлеты отдельно. Я искренне недоумеваю зачем валить в одну кучу и личную переписку и скрытоэхи, если это логически разные вещи.

vit01> Можно разделять нетмейл на эхи-беседы так, как предлагал Денис (подставлять в поле echo свой текст), а затем просто делать по ним доп. запросы, чтобы получать сообщения всех участников.

vit01> GET /netmail
vit01> pauth=blablabla
vit01> nechoes=first.necho:second.private.123

vit01> И теперь нетмейл будет формироваться с учётом скрытобесед независимо от того, какие получатели проставлены на "помеченных" сообщениях.

Но зачем?

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

Наша задумка с единственной эхой не имеет такой фичи.

Можно разделять нетмейл на эхи-беседы так, как предлагал Денис (подставлять в поле echo свой текст), а затем просто делать по ним доп. запросы, чтобы получать сообщения всех участников.

GET /netmail
pauth=blablabla
nechoes=first.necho:second.private.123

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

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

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

Имени, конечно, недостаточно, но вот существующий адрес годится для этой задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

vit01> Соблазн по фичам. С одной стороны, обыкновенный нетмейл по единственной эхе будет как-то работать. Но будет мало гибкости
vit01> 1. Обычный нетмейл - это разговор 1 на 1.

Что подразумевается из названия "личные сообщения".

vit01> 2. Скрытоэхи работают только на "своей" станции, ибо не гейтуются автоматически

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

vit01> 1. Предположим, я пишу пользователю Andrew Lobanov, проставив его имя в поле получателя. Сообщение расходится по всей сети через общую эху net.mail. На станции syscall (там есть публичная регистрация) некто заводит аккаунт с именем Andrew Lobanov (предположим, что этого поинта на syscall раньше не было) и ловит всю его почту. Пролёт.

Ипользовать не имя, а адрес. Адрес в рамках сети уникален.

vit01> 2. Придумываем, что некто написал письмо мне, vit01, но в поле получателя написал (mira,1). Сообщение расходится по всей сети. Здесь, внезапно, станция мира падает под DDoS или потому что я не оплатил хостинг. Само собой разумеется, я перенастраиваю клиент на другую ноду, пусть это будет Таверна, где мой адрес уже (tavern,N). И...
vit01> и получаю, что в нетмыле пусто.

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

vit01> Предлагайте свои варианты.

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

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

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

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

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

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

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

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

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

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

Что же противоречивого?

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

Когда собесеников больше двух, флейм неизбежен =)

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

Вот это вообще не очень. Хотя, смотря какой таймаут.

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

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

AL> Но зачем?

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

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

-----
to All

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

1. Предположим, я пишу пользователю Andrew Lobanov, проставив его имя в поле получателя. Сообщение расходится по всей сети через общую эху net.mail. На станции syscall (там есть публичная регистрация) некто заводит аккаунт с именем Andrew Lobanov (предположим, что этого поинта на syscall раньше не было) и ловит всю его почту. Пролёт.

2. Придумываем, что некто написал письмо мне, vit01, но в поле получателя написал (mira,1). Сообщение расходится по всей сети. Здесь, внезапно, станция мира падает под DDoS или потому что я не оплатил хостинг. Само собой разумеется, я перенастраиваю клиент на другую ноду, пусть это будет Таверна, где мой адрес уже (tavern,N). И...

и получаю, что в нетмыле пусто.

Предлагайте свои варианты.

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

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

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

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

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

Подход Andrew Lobanow более, что ли, академичен. Нужен нетмейл, делаем нетмейл. Хорошо и правильно. Да, сбоку. Но это правильный путь. То-есть, есть эхи, а есть нетмыл, и они не пересекаются.

Я не чувствую в себе морального права "проталкивать" свою идею, даже если мне она нравится. Во первых, я и сам не уверен, что она правильная. А во вторых, без обсуждения с остальными участниками ii это было бы очень неправильно. Но судя по всему, потребность нетмыла не назрела, а вот мне лс в клубе очень нужны.

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

Если есть какие то идеи, не стесняйтесь!

AL> Единственное, что мне видится проблематичным при любой реализации нетмейла, это необходимость в общесетевом поинтлисте. Чтобы было удобно выбирать кому пишется сообщение.

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

Писал с ноды tavern, в эху linux.14, там же получил ответ, но с другой ноды. В конфиге
прописана строка {to jmaks}, а в карбонку это сообщение-ответ не попало.

Это норм? Ник совпадает.
Вот данные сообщения

==========
[linux.14 / D2KDOEYx13zDzoc86IRT]─
От: vit01 (mira, 1)
2017.08.10 15:17 UTC
Кому: jmaks
Тема: Re: Orange Pi PC2
[1.26 KB]─[Ответ на sJwK4BWIRkTQ4mZjeve1]─
==========

Впилил ЛС в рамках одной ноды (чтобы не влиять на выбор стандарта netmail).
Как сделано:

1) сообщения в поле to которых присутствует адрес вида <нода,поинт>, считаются признаком лс.
Пример валидных адресов.
- Peter <syscall,1>
- <syscall,1>
- Петька Редька <syscall,1>

2) в вебе на сообщениях, которые созданы поинтами той же ноды, появился конвертик, нажав на который формируется письмо в случайной эхе с to: User <node,point>

3) есть эхи mail.from@authstr и mail.to@authstr в которых видны все сообщения от нас и к нам, в которых и будут появляться эти лс (в том числе), помеченные визуально специальным образом

4) (опциональная фича) это при попадании сообщения в ноду, адрес вида Peter <syscall,1> превращается в Peter, если этот поинт принадлежит нашей ноде.

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

Если/когда будет сделан другой netmail, то я и буду думать что делать дальше. А пока от меня идей больше нет. :)