Проект "Свободные голосования"

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

А что мешает инициировать проверку в ручном режиме членов субъекта, силами заинтересованных в результате и отсутствии фальсификаций? Список членов субъекта есть? Емайл каждого члена тоже есть. Не пойму в чем сложности?

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

Любой может подписать ключ. А вот каково обратное действие? Таковое не предусмотрено без дополнительного функционала. Вот я и спрашиваю - каким может быть такой функционал если у нас не будет выделенного сервера для принудительной проверки ключа?

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

А понял Вас, да проблема.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

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

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

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

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

_________________
Если бы другие не были дураками, мы бы ими были. (C)

Kuguar, вы не поняли вопроса.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Андрей вы же сами писали про "вотум недоверия". вроде как у Вас была концепция.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17