Имею честь быть знакомым с ребятами из проекта http://ru.gplvote.org/. Суть его проста как песня и нужна как воздух. Ребята создают полностью распределенную систему голосования на открытом исходном коде.
Надеюсь, здесь всем понятно, что для системы голосования означает «распределённость» и «opensource».
У ребят есть целая концепция организации верификации голосов, на GnuPG, которая не требует единого координационного центра. Читайте их сайт, там интересно.
У меня есть подозрение, что если бы выборы в КС оппозиции делались на этой платформе, то… но, история не терпит сослагательности, кроме как в книжках про войну…
Так вот, моим скромным вкладом в этот проект стала идея сделать распределенный транспорт доставки голосов на метафоре эхоконфереции.
Прелесть «эхи» в том, она полностью распределена, и каждое сообщение, отправленное в конференцию на одном узле растаскивается системой по всем остальным узлам, которые на эту конференцию подписаны.
То есть, приняв, что для каждого «голосования» заводится эхоконференция, голосование можно проводить просто отсылкой письма в «эху». «Эхи» могут быть локальные, глобальные — как и голосования.
Плюсами такой системы вижу:
- готовый, обкатанный, открытый софт,
- развитые, умные политики оптимизации обмена трафика между узлами, а одно голосование масштаба города — уже десятки тысяч писем,
- десятки, а то и сотни человек в каждом городе, знакомые с технологией ФИДО (это только бывшие НОДы, а с поинтами тысячи их), которые просто из ностальгии могут поднять у себя узел сети...
Собственно, если докрутить там гибкую маршрутизацию, (когда один узел умирает, почта идет в обход) неубиваемая ДДОСом вещь получается… А протоколы динамической маршрутизации в FIDO уже есть:
Протокол FRIP (расшифровывается как Fidonet routing information protocol) и одноимённая утилита, созданная Дмитрием Завалишиным, работающая по принципу «объявления» — каждый узел рассылает связанным с ним узлам объявления о том, что он готов принимать почту для некоего списка узлов (как правило, для самого себя и своих даунлинков). Получатели объявления продолжают рассылать его всем связанным узлам. Рассылка не происходит, если получатель объявления уже «знает» более короткий путь к целевому узлу. В результате должна быть автоматически построена карта роутинга, обеспечивающая доставку сообщений по наиболее короткому пути. В настоящее время этот протокол не используется.
Программа Hubroute generator (также известная как «сафроутер» — по имени создателя, Юрия Сафронова; в пакете Husky она называется Fidoroute). Эта программа строит роутинг на основе общих для региона списка жестко заданных путей роутинга и списка «доверенных» узлов, принимающих почту для определённой сети (в российском Фидо — R50.ROU и R50.TRU соответственно) с учётом данных об узлах, на которые данный узел может напрямую отправлять сообщения. Общерегиональные списки путей роутинга и доверенных узлов составляются региональным координатором на основании данных, которые ему присылают сетевые координаторы.
ФИДО функционировало на 40 000 узлах, без денег, в условиях платной междугородной связи. Соответственно, мысли типа «большой трафик», «не выдержит большой трафик» порождают один ответ — RTFM. Информация эхоконференций распределена в сети нодов (узлов). На этом уровне сеть — p2p. Но сейчас мощности хранения данных вполне позволяют держать нода и поинта на одной машине. Даже по старым стандартам в сети может быть 2^45 нодов = 32 триллиона узлов, так что архитектурно это вполне реализуемо…
Чтобы не гонять трафик из каждого дома по всей стране, конференции надо организовать аналогично административному делению: дом, улица, (микро)район, город (поселок), область, страна.
- Улица — «босс» домов,
- район — «босс» улиц,
- город — «босс» районов,
- область — «босс» всех населенных пунктов,
- страна — «босс» областей.
Тогда маршрут письма для каждой ноды можно сделать таким:
получив новое письмо;
послать его соседу ; // они сами разберутся, есть уже такая посылка или нет
проверить уровень конференции;
если (она есть у ноды уровнем выше), то {
послать боссу;}
Есть предложение не переливать из пустого в порожнее, а поднять FTN сетку из 3-5 узлов на том же Хаски husky.sourceforge.net и погонять там сообщения.
Если мы упремся во что-то, то, думаю можно написать ребятам которые делали Хаски, там половина русских, и попросить подправить нам руки и/или конфиги. А может они проникнутся идеей и допишут нужный функционал.
Собственно, кто еще хочет тряхнуть стариной и погонять сделать нормальную электронную демократию на FTN?
ЗЫ понимаю сам, что технология не идеальна, например (пока) не знаю, как сделать в FTN анонимизацию для тайного голосования. Но с чего-то начинать надо.
ЗЗЫ (небейтебольно) А вообще можно не заморачиваться FTN в силу экзотичности, а сделать транспорт на новостных группах NNTP (USENET). Архитектура та же, что и в FTN — группы распределены на NNTP серверах см. www.bog.pp.ru/work/usenet.html То есть, каждый участник сети поднимает у себя NNTP сервер и «подписывается» на интересные ему голосования. Доп. плюсом этого решения является то, что NNTP протокол поддерживается большинством современных почтовых клиентов, (в т.ч. Thunderbird) которые поддерживают GnuPG ЭЦП.
ЗЗЗЫ: Да, в Husky есть не GPL код. Непонятно, какая там лицензия на часть файлов, просто лицензионный текст… EULA короче ((( Посмотрел NNTP серверы- там Apache James идет соответственно под Apache License (GPLv3 совместима), и ISC — (не удивляйтесь! ) -под ISC license (GPL совместима и даже CopyFree)
Бывш. 5040/33.35
Автор: stt
