Тунеллирование можно и самому сделать.

Помню, делал так: брался tuntap-девайс с обеих сторон. К нему подключалась программа, которая доставала оттуда пакеты, переводила их в base64 и слала по XMPP. И обратно.

Потом, на slave-стороне выставлялся tun-интерфейс дефолтным гейтом а на master-стороне включался NAT.

Работало.

очень бегло посмотрел «спек» протокола и сорцы. Не понял - у вас получаются идентификаторы (пользователей по крайней сере) совсем уникальны что-ли? Кто за ней (уникальностью) следит или как она обеспечивается ??

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

Корневые ноды лежат

Интересный проект. Очень интересный. Аналог Скайпа, хоть пока и без звука и видео, но думаю за этим дело не станет. Это пожалуй последняя не взятая СПО твердыня. Поддержу своей нодой. Надеюсь «сорока» взлетит. Собрал клиента и ноду, вот только обе ноды прописанные в ноделисте picapica.im, picapica.ge лежат и соответственно связь наладить не получается. Автор, не пропадай. Отличное начинание. Поднимай корневые ноды. Общественность волнуется.

Автор, пока не поздно, отказывайся от уникальных номеров. У тебя же вся система сейчас завязана на один центр регистрации. О какой «децентрализованности» здесь может идти речь? Смотри в сторону самоподписанных сертификатов и, опционально, сетей доверия.

Для того, чтобы не диктовать все 1024 бит ключа - берем от него короткий хэш, ищем по нему на публичных «серверах адресов» и выбираем из того, что выдало, как сделано в pgp, например.

ebuild

Вот если кому интересно ebuild для Gentoo. Написано на коленках, поэтому сильно не пинайте.

---------------------------

# Copyright 1999-2012 Gentoo Foundation

# Distributed under ...

# $Header: ...

EAPI=4

DESCRIPTION=«Distributed decentralized secure instant messaging system.»

HOMEPAGE="http://picapica.im"

SRC_URI="http://picapica.im/${PN}-0.5.1.tar.gz"

LICENSE=«BSD»

SLOT=«0»

RDEPEND=«>=dev-db/sqlite-3.7.13

>=dev-libs/openssl-1.0.0j

>=sys-libs/zlib-1.2.5.1-r2 »

DEPEND=«${RDEPEND}»

src_configure() {

econf --disable-menuitem || die «configure failed»

[[ ! -f Makefile ]] && die «configure failed»

}

src_compile() {

emake }

src_install() {

make DESTDIR=${D} install || die «Install Failed»

}

---------------------------------

Собирается с --disable-menuitem. Одно НО - nodelist.db кладется почему-то в /var/lib/lib/pica-node/ вместо /var/lib/pica-node/ и приходится в pica-node.conf подправить путь. Разбираться чей косяк пока некогда. Работает и ладно, но вот корневые ноды все еще мертвы. Это уже хуже.

упс, и правда лежит :)

рестартанул

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

а то к 7 новым появившимся нодам не коннектится почему-то

91.202.255.68|2299|1345779852|0
89.237.21.144|2299|1345807620|0
84.23.35.164|2299|1345818350|0
109.188.171.251|2299|1345823122|0
92.55.38.239|2299|1345826087|0
193.169.37.63|2299|1345854428|0
89.31.112.34|2299|1345901005|0

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

nodelist.db кладется почему-то в /var/lib/lib/pica-node/

econf --disable-menuitem --localstatedir=/var (по умолчанию econf выставляет --localstatedir=/var/lib)

завязана на центр регистрации только один раз, при регистрации. Далее всё происходит децентрализованно

Для того, чтобы не диктовать все 1024 бит ключа - берем от него короткий хэш, ищем по нему на публичных «серверах адресов» и выбираем из того, что выдало, как сделано в pgp, например.

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

очень бегло посмотрел «спек» протокола и сорцы. Не понял - у вас получаются идентификаторы (пользователей по крайней сере) совсем уникальны что-ли? Кто за ней (уникальностью) следит или как она обеспечивается ??

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

выше (Вышел первый релиз Pica Pica Messenger (комментарий)) anonymous уже высказал правильную мысль. Пока в сети есть центр она не является децентрализованной. Посмотри в сторону GnuPG и сети доверия (по крайней мере там описанно как они строятся). Но под это протокол просто неподходит :( У вас идеалогически аналог IRC с dcc командами, а там подразумеваются пиринговые отношения и сеть доставки.

любыми средствами надо убирать центр из сети. Иначе это фейк.

и выбираем из того, что выдало

я специально заострил на этом внимание, это как поиск по email-адресу - вводишь «username» - тебе подсказывает варианты. username@mail.com, username1@mail.com и т.д.

за уникальностью следит центр регистрации, подписывающий сертификаты пользователям в последовательной нумерации.

Ситуация: корневой сертификат скомпрометирован, твои действия? Выпускать новый и похерить все дочерние, выпущенные до этого? Во имя святого П-трика, подумай над этим.

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

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

По поводу ID-шников пользователей. Так как все таки выдача ID происходит? Некая центральная или постоянно работающая нода, следящая за уникальностью ID, нужна или нет?

Как разруливаются случаи изменения данных пользователя (например, быстро переподключаеться под другим IP через другую ноду, первая нода не увидела disconnect)? Можно ли сидеть с двух разных IP на одной ноде или на разных нодах под одним логином/ID?

Как разруливаются случаи, если какие-то ноды, хранят совершенно разную информацию о пользователе? Пользователя просто не найдут там где указан неверный адрес пользователя или есть еще какие-то механизмы?

очень краткое замечание по протоколу :

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

Пример - юзер хочет пообщаться с vpupkin, запрашивает ноду. А нода не знает этого vpupkin`а и должна запросить соседей. Пока нода не получит ответа от соседей запрос не может быть выполнен. А юзер на самом деле хочет общаться (анонсировать себя) ещё с 30-40 абонентами и его пожелание сбудется ещё очень не скоро :)

То есть процесс длительный. Из этого следует что протокол должен должен поддерживать асинхронные/отложенные запросы, то есть работать а-ля imap.

ИМХО, здесь следует разделить операции на блокирующие и неблокирующие.

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

ИМХО, здесь следует разделить операции на блокирующие и неблокирующие.

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

- запрос исполнен, вот результат

- запрос зарегестрирован и исполняется сетью, вот его местный ID

- пшёл нах - слишком много запросов :)

Клиентская часть в свою очередь должен иметь возможности:

- спросить какие запросы всё ещё исполняются и на какой стадии, а на какие получен результат

- получить результат выполненных запросов (если серверная часть пассивна и сама этого не сообщает)

- отменить выполняемые

Залито в AUR

ИМХО, слишком жирно. Такое нужно только в том случае, если таких запросов в протоколе больше половины, и каждый в среднем исполняется минут по 5, либо легко может вылезти за такие рамки.

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

Про идентификацию (способы идентификации в сети):

При отказе от централизованного CA, клиенты используют самоподписанные сертификаты. То есть сочетание credentials при генерации (ФИО+e-mail или ещё что-то)+открытый_ключ можно считать однозначным ID пользователя в сети. А закрытая часть ключа позволит пройти авторизацию.

Ноды в сети идентифицируются по доменному имени+порт. Так в Интернете принято :)

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

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

Получается, что сеть должна управлять этими идентификаторами. То есть соотносить ключ, с набором ноды+номера_в_них,в разумных масштабах рапространнять эту инф, обеспечивать отзыв и замену сертификатов, изменение credentias. Даже при отключенных нодах.

p.s. И наверное не надо вообще поддерживать справочник вида vpupkin->его_открытый_ключ на уровни распределённой сети. На мой взгляд это излишне. Юзеры вполне могут обменяться открытыми ключами иным способом (по e-mail или другим внешним, или ещё несделанным дополнительным сервисом). IM должен поддерживать децентрализованный обмен сообщениями между владельцами сертификатов.

Получается, что сеть должна управлять этими идентификаторами. То есть соотносить ключ, с набором ноды+номера_в_них,в разумных масштабах рапространнять эту инф, обеспечивать отзыв и замену сертификатов, изменение credentias.

Нет. Если клиент провафлил свой сертификат - это не забота сети в целом, а конкретного криворукого индивидуума.

ИМХО, слишком жирно. Такое нужно только в том случае, если таких запросов в протоколе больше половины

это как раз просто в реализации и легко масштабируется. Принимается пакет, регистрируется задача, кладётся в очередь worker`а. Время ожидания на сокете минимально, отзывчивость сервера выше.

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

это не забота сети в целом, а конкретного криворукого индивидуума

«криворукий индивидум» должен иметь возможность замены собственного серт. штатным образом. У сертификата например бывает срок годности :) Или просто индивидуму показалось что серт. может быть скомпрометирован и он решил сгенерять новый.

«криворукий индивидум» должен иметь возможность замены собственного серт. штатным образом.

Да легко, генерируем новый, рассылаем по контакт-листу с просьбой добавить. Сам же предлагаешь таким образом контакты добавлять: «иным способом (по e-mail или другим внешним, или ещё несделанным дополнительным сервисом».

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

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

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

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

Право замозабаниться должно таки быть у пользователя:)

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

Раз в год, скажем можно потратить на 10 минут на рассылку и подтверждение нового.

P.S. В общем автор, идей тебе накидали, думай, пиши. Эту тему помониторю ещё недельку, дольше её всё равно никто читать не будет.

кстати вот аналогичный проект http://retroshare.sourceforge.net/ :)

http://retroshare.sourceforge.net/wiki/index.php/Documentation:Security_model

нифпечатлил. Технической документации практически нет, зато куча рекламного бла-бла-бла. Или они зарелизились достаточно недавно, либо есть какой-то подвох.

Чтобы нода работала нужен ведь внешний ip?

у них чистый клиент-клиент. Зато полностью,реально децентрализован:) Если рассматривать как аналог Pica, то node просто ещё один клиент с отключенным gui.

Тех.доков мало как и в каждом 2-м comunity проекте. То есть проект максимально близок, но не полный аналог. Если глянуть то увидишь что разработчков штуки 3-4, им очевидно достаточно сорцов и за написание хоть какой-то документации стоит похвалить :)

а рекламное бла-бла-бла вещь сугубо необходимая. Даже более чем тех.документация :)

Пример - юзер хочет пообщаться с vpupkin, запрашивает ноду. А нода не знает этого vpupkin`а и должна запросить соседей. Пока нода не получит ответа от соседей запрос не может быть выполнен. А юзер на самом деле хочет общаться (анонсировать себя) ещё с 30-40 абонентами и его пожелание сбудется ещё очень не скоро :)

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

Принимается пакет, регистрируется задача, кладётся в очередь worker`а. Время ожидания на сокете минимально, отзывчивость сервера выше.

Что-то подобное в виде очередей планируется для ноды, для процесса подключения новой ноды к уже существующим

Чтобы нода работала нужен ведь внешний ip?

да

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

http://picapica.im/vkr.pdf

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

Например, такая идея - сделать комбинированный вариант, кто хочет, получает сертификат от центрального CA, кто не хочет - работает по принципу PGP, сети доверия, и подписывает свой ключ как можно большим количестом разных людей. Первые получают последовательный номер в диапазоне 1 - 2^31-1, вторые - 2^31 - 2^32 -1 который будет хэшем открытого ключа

Первые получают последовательный номер в диапазоне 1 - 2^31-1, вторые - 2^31 - 2^32 -1 который будет хэшем открытого ключа

Не проще ли ввести идентификацию по номеру пользователя и сертификату? Т.е. в системе регистрируется новый сертификат (открытая часть). После чего все пользователи обрабатываются по группам (в зависимости от принадлежности к соответствующему «корневому» сертификату), естественно пользователи из разных групп могут общаться между собой без проблем (используя те же ноды сети для поиска пользователя). Пользователи регистрируются у того, кто владеет любым «корневым» сертификатом. Одна нода (сервер) вполне в состоянии работать с несколькими сертификатами.

Механизм обмена сертификатами между нодами (и способ обмена некоторыми ID сертификатов, если они появятся) с ходу не могу представить... Если потребуется ID для сертификата, то можно предусмотреть возможность регистрации сертификата так как сейчас сделано для регистрации пользователя, хотя можно обойтись без ID и честно верить любому «корневому» сертификату (но тут будет проблема при поиске/обмене контактами).

Система будет более децентрализованной (хотя и выглядит немного костыльненько). Что-то типа того как пользователю дается возможность отправить письмо с gmail.com потому что у него есть учетка на mail.ru... В итоге получится более гибкий и простой способ регистрации пользователя (без необходимости регистрации на центральном сервере, если рядом есть уже авторизованный пункт выдачи ID, или самому стать центром выдачи ID). Пользователя придется идентифицировать по некому ID сертификата и собственному ID (уникальности ID пользователя достаточно в пределах одного «корневого» сертификата).

хотя можно обойтись без ID и честно верить любому «корневому» сертификату (но тут будет проблема при поиске/обмене контактами)

а ещё легко реализуемая атака man-in-the-middle, и весь смысл системы резко теряется :)

а ещё легко реализуемая атака man-in-the-middle, и весь смысл системы резко теряется :)

Согласен на все 100%! После подобных изменений проблем становится просто огромное количество (например, все ноды можно будет положить за пару часов нагенерировав тысячи фейко-сетей с миллионами пользователей), но в принципе потенциальные проблемы можно более-менее решить и выявить. После этого предоставить пользователю / админу возможность решить какой вариант сети он хочет использовать. Супер надежный, безопасный и т.д. Свою закрытую и изолированную сеть. Или вообще глобальная сеть с террористами и педофилами.

Просто идея какая... Сейчас у тебя есть некий закрытый сертификат, средство регистрации пользователей и некий открытый CA.pem для твоей сети (в арихиве с исходниками/бинариками). Постепенно пользователи у тебя регистрируются, получают ID, поднимают ноды и в итоге разворачивают большую сеть.

Никто не мешает еще кому-то сгенерировать свой закрытый сертификат (может быть даже тебе придется сделать это в будущем, если что-то случится с твоим сертификатом), получить свой CA.pem, вложить его в дистрибутив, организовать систему регистрации пользователей и получить свою сеть. Было бы красиво, если бы эти две сети в последствии смогли бы прозрачно взаимодействовать друг с другом, тогда действительно получится децентрализация... Если для этого придется по договоренностями между влядельцами нод и обменяться файликами CA.pem чтобы видеть друг друга, ну чтож... пусть так...

...и будет у вас сотня «валидных» сетей, поднятых гоблинами разной степени криворукости в которых сидит по 10 человек. Нахер эти полумеры.

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

Хватит трястись о мифическом «удобстве хомячков», не оценят они его. И клиент этот - не для них.

Например, такая идея - сделать комбинированный вариант, кто хочет, получает сертификат от центрального CA, кто не хочет - работает по принципу PGP.

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

Определись, чего ты хочешь: если создать реально децентрализованный клиент, которым (может быть) будет пользоваться куча народу - это одно, если создать ещё вариацию на тему аськи, в которой у тебя будет контакт № 1 - это совсем другое.

Я даю советы, как сделать по первому варианту. Если будешь делать по второму - флаг в руки, но при случае я буду поминать проект добрым матерным словом.

...зашифрованное TLS соединение устанавливается между пользователями....

Э-э-э-э... а как быть с NAT?

Э-э-э-э... а как быть с NAT?

конечными точками TLS соединения являются пользователи, но данные проходят через ноду прозрачно для TLS протокола

клиент1 ==> нода1 ==> нода2 ==> клиент2

через 3 последовательных TCP соединения и 2 ноды, в общем случае. Могут и через одну общую ноду, если оба клиента подключены к ней

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

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

Вопрос в том, нужно ли это :)

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

именно то, ченго хотели большевики. идея хороша, скажите как на практике

Где мне взять этот pem файл

Вот init скрипт для Gentoo:

#!/sbin/runscript

depend() {
        after logger
}

start() {
        ebegin "Starting pica-node"
        start-stop-daemon --start --background --exec /usr/bin/pica-node
        eend $?
}

stop() {
        ebegin "Stopping pica-node"
        start-stop-daemon --stop --quiet --exec /usr/bin/pica-node
        eend $?
}

И еще было бы неплохо прикрутить у вас на pica сайте форум, а то на ЛОРе эта тема со временем уйдет и вы потеряете связь с «клиентом».

Четыре года просраны бездарно

Выскажу своё субъективное критическое мнение.

регистрацией занимается отдельная программка-регистратор

Отсюда следует, что поделка по сути своей является эпичным фейлом. Фейлом во всём. Начиная с протокола, заканчивая реализацией. Непонятно чем автор занимался 4 года. Он совершенно не знаком с теорией одноранговых сетей. По-нормальному такие вещи делаются так: изучается теория, готовые реализации аналогов, выясняются у них слабые места, ставится проблема их усранения, находится решение. Потом изучаютяс програмные каркасы, на базе которых пишется реализация (чтобы не плодить селосипеды). Взять хотя бы тот же GNUnet, который дал бы и разные транспорты, и пробитие натов разными способами и кучу всего полезного. Здесь же какая-то школьная поделка, что просто смешно смотреть. Автору поделки никакого респекта.

Осиль прочитать последние 2 страницы. Я с одним из регистрантов уже это разжёвывали.

Плюсую идею с форумом.

Итак,

- Репозиторий выложен на гитхаб - https://github.com/antonsviridenko/pica-pica

- Доступны ebuild-ы для Gentoo - https://github.com/antonsviridenko/pica-pica-gentoo-overlay

- Для обсуждения разработки созданы рассылки: https://groups.google.com/d/forum/pica-pica-development https://groups.google.com/d/forum/pica-pica-development-ru (на русском)

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

- Вышла новая версия http://picapica.im/pica-pica-0.5.2.tar.gz

Исправлено несколько багов и пополнен список «затравочных» нод