Нежданчик с доменами vit01 to All

Захожу сегодня в клиент, загружаю новую почту. Обнаружил, что резервная станция irk39.tk (mtest) не функционирует.
Ладно, думаю, проблема с хостингом, то есть с RedHat OpenShift. Как оказалось, у хостера всё работает, сервер на месте.

Зашёл к доменному регистратору (ранее dot.tk, теперь freenom) и офигел.

Единственным доменом, который за мной значится, оказался alicorn.tk.
Остальные (а их там было штук 5 минимум) куда-то исчезли, в том числе сам ii-net.tk без всяких на то предупреждений. А ведь раньше предупреждали.

ii-net.tk никто захватить ещё не успел, поэтому я его взял заново, но уже за 10$, а не бесплатно.
В ближайший день может отказать почта и дебаг-сервер (да и сам сайт), если мою заявку не зачтут.

Все остальные домены, в том числе irk39.tk, возвращать не буду, жалко тратиться =)
Насчёт резервной станции ещё подумаю.

// Нашим советую перенаправить фетч на alicorn.tk денька на 2, там стоит зеркало mira station, просто домен в фетчере поправить и всё.


Скрытоэхи как транспорт ЛС Peter to All

Не могу не поделиться результатами "боевых испытаний".
Короче, обсуждаем в закрытой эхе сюжет новой игры.
Очень удобно!

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

Сами эхи private.**** не засоряют веб интерфейс (их просто там нет).

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

В общем, есть ли netmail в классическом понимании или его нет, механизм скрытоэх очень приятен, особенно когда он автоматизирован...


Re: Скрытоэхи как транспорт ЛС Peter to Peter

Да, и опять несколько дней с моей ноды не работал фетчинг. =) Простите, сейчас все должно пойти....


Bugs? jmaks to All

Писал с ноды 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]─
==========


ЛС в клубе Peter to All

Впилил ЛС в рамках одной ноды (чтобы не влиять на выбор стандарта 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, то я и буду думать что делать дальше. А пока от меня идей больше нет. :)


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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

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


Re: Снова мысли о нетмыле Difrex(mobile) to Andrew Lobanov


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

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


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

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


Re: Снова мысли о нетмыле Difrex(mobile) to Andrew Lobanov


AL> Десять собеседников -- десять эх.
Лайк


Re: Снова мысли о нетмыле Peter to Peter

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

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

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

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

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

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

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

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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

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


Re: Снова мысли о нетмыле Andrew Lobanov to vit01

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> Предлагайте свои варианты.

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


Re: Снова мысли о нетмыле Peter to vit01

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

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

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


Re: Снова мысли о нетмыле vit01 to Andrew Lobanov

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). И...

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

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

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

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

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

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

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


Re: Снова мысли о нетмыле Andrew Lobanov to vit01

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

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

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

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

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

Но зачем?


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

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


Re: Снова мысли о нетмыле Peter to Difrex

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


Re: Снова мысли о нетмыле Difrex to Peter

>Работает на 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
====



Re: Снова мысли о нетмыле Peter to Peter

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


Re: Снова мысли о нетмыле Peter to vit01

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


Re: Снова мысли о нетмыле Peter to vit01

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

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

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

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

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

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

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

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

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


Re: Снова мысли о нетмыле vit01 to Andrew Lobanov

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

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

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

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

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

Ну оно сильно не отличалось с точки зрения запросов. Просто всё в одной эхе "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>

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

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

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

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


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

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

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

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


Re: Снова мысли о нетмыле Peter to Peter

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

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

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


Re: Снова мысли о нетмыле Peter to Peter

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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


Re: Снова мысли о нетмыле Peter to Andrew Lobanov

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


Re: Снова мысли о нетмыле Andrew Lobanov to Peter

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

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

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


Re: Снова мысли о нетмыле Peter to vit01

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

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


Re: Снова мысли о нетмыле vit01 to Peter

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

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

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


Снова мысли о нетмыле Peter to All

После экспериментов с 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) не читабельные имена эх. генерируемых автоматически. Но, может, терпимо?

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


Re: Что я натворил Peter to Difrex

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

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


Re: Что я натворил Difrex to Peter

502 Bad gateway :(


Re: Что я натворил Peter to Peter

Изменил кое-что, так что ссылка из прошлого сообщения не работает.
Аналог выборки:
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


Что я натворил Peter to Andrew Lobanov

Хочу поделиться мыслями по поводу моих экспериментов с 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

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

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


Re: idec mobile vit01 to vit01

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

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

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


Re: idec mobile Andrew Lobanov to vit01

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

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


Re: idec mobile vit01 to vit01

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

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

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

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


Re: Фэхи Andrew Lobanov to vit01

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

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

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

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


Re: Фэхи vit01 to btimofeev

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

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


Re: Фэхи vit01 to Andrew Lobanov

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

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



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


Re: Фэхи btimofeev to vit01

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

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


Re: Фэхи Andrew Lobanov to vit01

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

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


Re: Фэхи Andrew Lobanov to vit01

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

Я был уверен, что любые буквы латиницы =)

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


Re: Фэхи Peter to Andrew Lobanov

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

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


Re: Фэхи vit01 to Andrew Lobanov

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

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

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

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


Фэхи Andrew Lobanov to All

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


Re: idec mobile Andrew Lobanov to vit01

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

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

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

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


Re: idec mobile vit01 to vit01

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

Обновляться всем обязательно!

1. Заходите в настройки станции, ставите галку "Поддержка файловых эх"
2. Фетчите сообщения как обычно
3. В NavDrawer'е идёте на вкладку "Файловые эхи"

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

Багов ещё много, но это уже хотя бы что-то. Занимался сегодня клиентом целый день, даже еде внимания меньше уделял. Так что прошу feedback!


Re: Фэхи btimofeev to btimofeev

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

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


Re: Фэхи btimofeev to Andrew Lobanov

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

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


Re: Фэхи vit01 to Andrew Lobanov

На mira station есть ещё фэха pr0n.share

Да, это именно то, что вы подумали, название говорит само за себя :)

Более чем уверен, что её наполнять никто не будет, но пусть останется на всякий случай.


Фэхи Andrew Lobanov to All

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

* pictures - картинки, скриншоты, всякое такое;
* books.tech - техническая литература, включая учебники и справочники;
* mlp.pictures - картинки с поняшами;
* mlp.special - ещё картинки с поняшами.

Последнюю фэху я думаю в последствии удалить, наверное. Всё таки очень специальный контент =)

Все фэхи на данный момент фетчатся с mira station.

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


Re: club.syscall.ru теперь забирает develop.16 Andrew Lobanov to Peter

Фетч двухсторонний.


club.syscall.ru теперь забирает develop.16 Peter to All

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


iing Andrew Lobanov to All

Сабж теперь может отображать эхи в виде лент (отображение по-умолчанию, переключение в профиле) и передавать содержимое конференций в RSS.


Re: Мысли о стандартах Andrew Lobanov to Peter

>> Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.
>> Это сабо самой.
> То есть, доверенные ноды тоже забирают по authstr? Как доверенная нода забирает бандл со всем net.mail?

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


Re: Мысли о стандартах Andrew Lobanov to Difrex

>> Лучше вписать туда что-нить типа net.mail.
> Не, фишка в том, что если оставить поле пустым, то будет периписка между двумя пользователями, а если в echo вписать что-то, то туда можно наинвайтить много пользователей и писать на All.
> Получится что-то вроде приватной эхи.

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


Re: Мысли о стандартах vit01 to Peter

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

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

Это гениально! =) Отличная идея. Только тут надо помнить, что название эхи - это lowercase, но тут невелика проблема, можно преобразовать.

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

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


Re: Мысли о стандартах Peter to Difrex

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

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


Re: Мысли о стандартах Difrex to Peter

>То есть, доверенные ноды тоже забирают по authstr?
Да.

>Как доверенная нода забирает бандл со всем net.mail?
Примерно так:

====
for node in neighbords:
for username in node_users:
r = requests.get('https://' + node '/x/i/' + username)
for msg in r.content.split("\n"):
if msg.split(':')[0] not in point_mails():
store_to_pointmail(base64.d64decode(msg.split(':')[1]))
====



Re: Мысли о стандартах Peter to Andrew Lobanov

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

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

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


Re: Мысли о стандартах Difrex to Andrew Lobanov

>Лучше вписать туда что-нить типа net.mail.

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

Получится что-то вроде приватной эхи.


Re: Мысли о стандартах Difrex to Andrew Lobanov

>Я примерно это и предлагал, но Виктора смущает MITM, и доступ сисопов доверенных нод к переписке.

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

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


Re: Мысли о стандартах Andrew Lobanov to Difrex

Difrex> Даже поле Echo можно оставить. Разрешить его быть пустым, например.

Лучше вписать туда что-нить типа net.mail.


Re: Мысли о стандартах Andrew Lobanov to Difrex

Difrex> Нода может, как по крону фетчить почту своих поинтов, так и напрямую ходить к соседям при запросе от поинта.

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

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

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


Re: Мысли о стандартах Andrew Lobanov to Difrex(mobile)

Difrex(mobile)> Кстати. Можно сделать ЛС и без шифрования и без общей эхи.
Difrex(mobile)> Например, методы <POST|GET> /i/username
Difrex(mobile)> Т.е поинт отсылает сообщение в свою ноду на поинта с другой ноды.
Difrex(mobile)> node1user:$ curl -XPOST /i/node2user -d '{"auth": "authstring"}'
Difrex(mobile)> И оно становится доступно для фетча для доверенной ноды. На другой ноде, где юзер хочет почитать почту, делается запрос на получение своей почты. Вторая нода делает запрос на все ей известные ноды, ну и фетчит почту своих поинтов.
Difrex(mobile)> Так протокол остается простым и может быть реализован хоть на файлах.
Difrex(mobile)> Вот как-то так.

Я примерно это и предлагал, но Виктора смущает MITM, и доступ сисопов доверенных нод к переписке.


Re: Мысли о стандартах Difrex to Difrex

Даже поле Echo можно оставить. Разрешить его быть пустым, например.
Если поле не пустое, то получится, что-то типа канала во всяких irc, только не im :).

Еще можно сразу нескольким юзерам разрешить писать: /x/i/<to_username>/<to_username2>.


Re: Мысли о стандартах Difrex to Difrex(mobile)

Сейчас с утра прочитал свое сообщение -- в общем мне нравится эта идея.

Вынести это все куда-нибудь в расширения, типа, /x/i/<to_username>.
Нода может, как по крону фетчить почту своих поинтов, так и напрямую ходить к соседям при запросе от поинта.

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

Годнота же.


Re: Мысли о стандартах Difrex(mobile) to Andrew Lobanov

Кстати. Можно сделать ЛС и без шифрования и без общей эхи.

Например, методы <POST|GET> /i/username

Т.е поинт отсылает сообщение в свою ноду на поинта с другой ноды.

node1user:$ curl -XPOST /i/node2user -d '{"auth": "authstring"}'

И оно становится доступно для фетча для доверенной ноды. На другой ноде, где юзер хочет почитать почту, делается запрос на получение своей почты. Вторая нода делает запрос на все ей известные ноды, ну и фетчит почту своих поинтов.

Так протокол остается простым и может быть реализован хоть на файлах.

Вот как-то так.


Re: Android клиент jmaks to vit01

jmaks>> Не работает почему-то authstr, который ты мне выдавал с mira station.
vit01> Напиши мне на me@ii-net.tk , разберёмся
Пишу.

jmaks>> И кнопки просмотреть pass нету.
vit01> Сделаю кнопку
Отлично.

vit01>>> Всем обновиться!
jmaks>> Я конечно может занудствую, но хотелось бы хоть знать какая теперь версия, что искать для обновления, а то найдешь, да не то.
vit01> 1. Заходишь на https://ii-net.tk, там есть кнопка
vit01> 2. Или в самом клиенте в Navigation Drawer'e в списке есть кнопка "Обновиться", она приведёт сразу на APK
Да, я уж нашел. Вспомнил где брал. Просто у тебя пакет называется всегда app-debug.apk и непонятно, какая версия, какое что.
Было бы понятней если идет ченджлог и версия пакета... типа idec-mobile-1.2.5.apk

jmaks>> Реквестирую СОХРАНЕНИЕ черновика сообщения
vit01> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.
Так-то да, но вот сегодня поймал странное поведение, и черновик написанный не сохранился, а только созданный.

jmaks>> прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts
vit01> Очень странное поведение. Однако я понял примерно, куда копать, спасибо за багрепорт.
Не за что.


Re: Android клиент vit01 to btimofeev

vit01>> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

btimofeev> Похоже нужно ещё и в onPause сохранять.

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


Re: Android клиент btimofeev to vit01

jmaks>> Реквестирую СОХРАНЕНИЕ черновика сообщения

vit01> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

Похоже нужно ещё и в onPause сохранять.


Re: Android клиент vit01 to jmaks

jmaks> Не работает почему-то authstr, который ты мне выдавал с mira station.

Напиши мне на me@ii-net.tk , разберёмся

jmaks> И кнопки просмотреть pass нету.

Сделаю кнопку

vit01>> Всем обновиться!
jmaks> Я конечно может занудствую, но хотелось бы хоть знать какая теперь версия, что искать для обновления, а то найдешь, да не то.

1. Заходишь на https://ii-net.tk, там есть кнопка
2. Или в самом клиенте в Navigation Drawer'e в списке есть кнопка "Обновиться", она приведёт сразу на APK

jmaks> Реквестирую СОХРАНЕНИЕ черновика сообщения

Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

jmaks> прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts

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


Re: idec mobile jmaks to vit01

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


Re: idec mobile jmaks to vit01

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

Реквестирую СОХРАНЕНИЕ черновика сообщения!!!!!!!!!!!!!!!!!!!!!!!
Выбесило просто, два раза пытался написать сабж в music.14, в ответ Andrew Lobanov, рекомендации и проч, что послушать, да погонять под настроение.

Первый раз -- упало новое сообщение в ii.14, собственно я его сам и написал до этого, прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts, вижу есть 1мессдж, фух, думаю сохранилось, написал уже много. Открываю, а там просто квотированный текст и заголовки мессдж ответа.

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


Re: Android клиент jmaks to vit01

Не работает почему-то authstr, который ты мне выдавал с mira station.
И еще, в idec-mobile, как раз при вводе этой самой authstr, почему бы не сделать строку видимой при первом вводе, потом можно и точками ее закрывать, при настройке эхо станции. Потому как не видно и сравнить нельзя правильно ли ввел посимвольно. И кнопки просмотреть pass нету.


Re: Мысли о стандартах Andrew Lobanov to Peter

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

Если нужны, то почему бы не сделать? Главное, чтобы остальной стандарт поддерживался. Причём по большей части достаточно ii-03 =)


Re: Мысли о стандартах Andrew Lobanov to All

А ещё я это сообщение набрал одним пальцем =)


Re: Мысли о стандартах Andrew Lobanov to All

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

Но почему-то нет доверия между сисопами. Мы ж кого попало не берём =)

Надо понимать, что вся сеть у нас строится на доверии и так и надо продолжать. Интернет и правительства государств стремятся к разделению людей, а мы же стремимся к обратному. Посмотрите на картинку на http://ii-net.tk/ она передаёт суть idec - сеть людей. Это то немногое, что отличает нас от остального интернета. И важно это не потерять со временем.

Выдохнул.


Re: Фэхи и документация Andrew Lobanov to vit01

>Так что ради соответствия сделал file ok:<hash> по аналогии с msg ok:<hash> в обычном /u/point. Ну и, конечно же, error: no auth
> Очень странно, что это было пропущено при проектировании, в iing и в стандарте.

Потому что я болван =) Спасибо. В ближайшее время внесу соответствующие правки в iing.


Re: Мысли о стандартах Peter to vit01

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

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

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

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

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

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


Re: Фэхи и документация vit01 to Andrew Lobanov

Просматривая документацию фэх, обнаружил, что при использовании f/p совершенно нет никаких кодов ответов
Так что ради соответствия сделал file ok:<hash> по аналогии с msg ok:<hash> в обычном /u/point. Ну и, конечно же, error: no auth
Очень странно, что это было пропущено при проектировании, в iing и в стандарте.

На станции мира в экспериментальном режиме теперь работают фэхи. Правда, я f/list.txt забыл сделать, но это не критично. Зато f/blacklist.txt не забыл =)


Re: Мысли о стандартах vit01 to Peter

Peter> Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

Ну так ЭЦП ведь действует независимо от шифрования. Так что читать чужие письма всё равно сисопы смогут.
Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

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


Re: Мысли о стандартах btimofeev to Andrew Lobanov

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

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


Re: Мысли о стандартах Peter to vit01

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

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


Re: Мысли о стандартах vit01 to Andrew Lobanov

vit01>> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.
AL> В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю?

vit01>> Также любые метаданные сообщений можно подменять на пути следования.
AL> Ну и долой такого сисопа при первом палеве из сети.

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

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

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

Когда мы пытаемся договориться по поводу чего-то, надо учитывать и плюсы, и минусы. Так что надо приводить примеры и с MITM, потому что кому-то это может не понравиться.


Re: Мысли о стандартах Peter to Andrew Lobanov

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


Re: Мысли о стандартах Andrew Lobanov to vit01

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


Re: Мысли о стандартах Andrew Lobanov to vit01

Peter>> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.
vit01> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.

В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю? Это позволит создать "круг доверия" между узлами и позволит ходить личной переписке между ними без этой уязвимости. Ведь внутри сети у нас не повторяются имена узлов.

vit01> Также любые метаданные сообщений можно подменять на пути следования. И отправителя, и получателя, и адреса, и всё остальное. То есть я тупо захожу в админку на станции, ввожу msgid и меняю любые данные в сообщении. Если уложился в 10 минут - атака MITM сработала. Иногда мне приходится очепятки так править, если случайно загнал сообщение, не подумав =)

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

vit01> Нас спасёт только шифрование, потому что именно оно может гарантировать сохранность переписки. И это гораздо надёжнее в плане транспортов, потому что подойдёт под любую схему синхронизации, какую только можно придумать.

Тогда я пас.


Re: Мысли о стандартах Andrew Lobanov to Peter

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

Вот! Хоть кто-то меня понимает.


Re: Мысли о стандартах Andrew Lobanov to Difrex

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

Да ни к чему, как по мне.

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

Это было бы актуально при аутбаундах.

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

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


Re: Мысли о стандартах vit01 to Difrex

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

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