Децентрализация регистрации пользователей

[Alexey Zakhlestin]

В разных местах уже озвучивалось — оставлю и тут.

Вместо ведения собственного реестра пользователей можно использовать существующую инфраструктуру PGP. При этом уникальным идентификатором пользователя является публичный ключ, а для поиска могут использоваться имя, email, fingerprint, и т.п. (поиск осуществляется на OpenPGP серверах, а не средствами клиента), а необходимости в каком-то дополнительном идентификаторе для Pica Pica вообще нет.

Так же отпадает необходимость в хранении контактов на сервере. Есть ключ в GnuPG-keychain — можно общаться. Нет ключа — надо добавить, потом общаться

[an...@picapica.im]

Хорошо, как тогда определять, к какой именно ноде в данный момент подключен
интересующий нас абонент? :)


On Tue, Aug 28, 2012 at 12:42:51PM -0700, Alexey Zakhlestin wrote:
> В разных местах уже озвучивалось -- оставлю и тут.

>
> Вместо ведения собственного реестра пользователей можно использовать
> существующую инфраструктуру PGP. При этом уникальным идентификатором
> пользователя является публичный ключ, а для поиска могут использоваться
> имя, email, fingerprint, и т.п. (поиск осуществляется на OpenPGP серверах,
> а не средствами клиента), а необходимости в каком-то дополнительном
> идентификаторе для Pica Pica вообще нет.
>
> Так же отпадает необходимость в хранении контактов на сервере. Есть ключ в

> GnuPG-keychain -- можно общаться. Нет ключа -- надо добавить, потом общаться
>
> --
> Вы получили это сообщение, поскольку подписаны на группу Pica Pica Development (Russian).
>
> Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу pica-pica-de...@googlegroups.com.
> Перейдите в группу по ссылке http://groups.google.com/group/pica-pica-development-ru?hl=ru.
>
>

[Alexey Zakhlestin]

On Wednesday, August 29, 2012 11:48:10 AM UTC+3, Anton wrote:

Хорошо, как тогда определять, к какой именно ноде в данный момент подключен
интересующий нас абонент? :)

У меня в голове рисуется примерно такая картина:

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

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

[an...@picapica.im]

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

[Alexey Zakhlestin]

On 29.08.2012, at 21:05, an...@picapica.im wrote:

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

в момент регистрации пользователя нода может рассылать другим нодам сообщение «видела пользователя с таким-то ключом»

сценарий:
пользователь 1 регистрируется на ноде А
нода А сообщает об этом своим соседям: нодам Б, В, Г
нода Г сообщает об этом своим соседям: нодам Д, Е, Ж, З [и т.д.]
в сети регистрируется нода Ж. Её ближайший сосед — Б
пользователь 2 регистрирутся на ноде Ж
пользователь 2 запрашивает у своей ноды как связаться с пользователем 1
у ноды Ж нет этой информации (она появилась позже чем прошёл бродкаст)
нода Ж шлёт запрос по своим соседям и сразу же получает ответ от ноды Б которая бродкаст слышала


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

в запросе информации о местоположении другого пользователя можно указать «нужна информация обновлявшаяся не ранее чем …»
это будет использоваться в случае если информация с более ранним таймстемпом уже была получена и после проверки оказалась устаревшей

[an...@picapica.im]

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

В принципе можно просто взять и заменить везде (в сообщениях протокола и в коде) 32-битный
id на открытый ключ пользователя (2048, 4096 бит или больше). Какие это может повлечть последствия -
надо подумать :)

On Wed, Aug 29, 2012 at 10:24:42PM +0300, Alexey Zakhlestin wrote:
>
> On 29.08.2012, at 21:05, an...@picapica.im wrote:
>
> > Ну нода, к которой подключен клиент, и так о нем знает.
> > Я спросил, как другие ноды и клиенты узнают, как связаться
> > с искомым абонентом?
>
> в момент регистрации пользователя нода может рассылать другим нодам сообщение <<видела пользователя с таким-то ключом>>
>
> сценарий:
> пользователь 1 регистрируется на ноде А
> нода А сообщает об этом своим соседям: нодам Б, В, Г
> нода Г сообщает об этом своим соседям: нодам Д, Е, Ж, З [и т.д.]

> в сети регистрируется нода Ж. Её ближайший сосед -- Б

> пользователь 2 регистрирутся на ноде Ж
> пользователь 2 запрашивает у своей ноды как связаться с пользователем 1
> у ноды Ж нет этой информации (она появилась позже чем прошёл бродкаст)
> нода Ж шлёт запрос по своим соседям и сразу же получает ответ от ноды Б которая бродкаст слышала
>
>
> цикличность сообщений устраняется тем, что если нода уже видела сообщение, то она его по второму разу рассылать не будет
> у сообщения есть UUID и timestamp.
>

> в запросе информации о местоположении другого пользователя можно указать <<нужна информация обновлявшаяся не ранее чем ...>>

> это будет использоваться в случае если информация с более ранним таймстемпом уже была получена и после проверки оказалась устаревшей
>