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

По данной проблеме было высказано разумное предложение оставить внесение критериев идентификации личности на совесть субъектов голосования, так как требования могут быть самыми различными: возраст, пол, национальность, место проживания, рабочая специализация, отношение к политической партии и т.п. Как это будет определяться, вопрос вторичный. Например, так:
1) участник (УЖ), желающий вступить, делает запрос случайному участнику субъекта (УС);
2) УС отсылает подписанный плагин данного субъекта УЖ`у;
3) клиент УЖ`а подключает плагин и через интерфейс проводит процедуру идентификации по некоторым критериям;
4) когда необходимая информация внесена, плагин отсылает эту информацию одному или нескольким конкретным или неконкретным (в зависимости от настроек субъекта) людям в субъекте для проверки;
5) люди проверили и подписали, УЖ становится полноценным участником субъекта.

Но тем не менее, для глобального субъекта (в частности "Российская Федерация") требуется минимальное обеспечение для реализации "один человек - один голос". Этим критериям должны соответствовать все участники системы.

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

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

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

Кстати, обновил статью о подписании ключей на более актуальный вариант.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Тут я вижу много проблем.

Например при внесении в ключ пары ПАРАМЕТР:ЗНАЧЕНИЕ может появиться ситуация с персональными данными. Уже не хорошо.

Второе, по взаимному подписанию параметров - окажется что в Рязани весь Техас живет.

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

Подписание параметра всеми Участниками Субъекта - субъект Россия, население около 130 млн. Каждый подписывает каждому = 16,9 х 10^15 - я не говорю про трудоемкость (мне придется подписать 130 млн ключей), но и размер полученного ключа , которых будет 130 миллионов

Так что - давайте думать дальше. Про плагины и т.д. - все хорошо. Но как такой плагин будет работать для типа Субъекта - Страна? Т.е. как будет механизм работать. Обязательно учитывать количество жителей.

Опять же - как лишить лицо гражданства или сменить адрес прописки? Как?

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

Или Ваня скажет - А вот Петя Железянов уже 2 года как переехал в Гадюкино, а до сих пор голосует у нас в Перделкино.

И потребует Ваня признать выборы недействительными, т.к. доверия нет к голосованию - может там не только "левые" баба Нюра и Петя Железянов?

Север доступа это "особый" сервер. Надо делать это на уровне клиента. Как пока не знаю.

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

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

Таким образом, Техас сможет "жить в Рязани" только если все (или достаточное количество) текущие жители Рязани захотят так сделать.


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


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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Такие вещи на уровне клиента делать нельзя. Т.к. клиент можно изменить.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Рязанцы проверят техасских злодеев. Объявят им вотум недоверия и выгонят. Процедура нам более менее понятна. Тут проблему не вижу.


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

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

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

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

Именно так и предполагается. Система вложенных подсубъектов вводится именно для этого. Что-бы не нужно было что-то массово делать на уровне более крупных субъектов.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68