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

Добрый день.

Который день думаю и не могу придумать ничего путного. Может попробуем вместе решить?

В чем проблема - есть Субъект. Возможный тип в данный момент - ТСЖ, ОАО, Город Москва, Калининградская обл., Россия.

Есть Участники Субъекта (я так назвал) - это те, кто имеют в данном Субъекте право голоса.

С терминами определились. Теперь проблема: Как делать пользователей Системы - Участниками Субъекта?

Понятно, что можно построить иерархию для некоторых Субъектов (подмножества всего множества Субъектов) по принципу вложенности - Калининград - Калининградская обл. - Россия - Земля - Вселенная.

Это дерево можно построить в момент и даже как-то администрировать (что само по себе проблема).

А как вот пользователя определить в "Город Калининград"?

Остальные субъекты (ТСЖ, ОАО и т.д.) давайте пока не трогать - там можно свои механизмы определить. Давайте подумает по тому, что всех волнует - голосование на региональном и федеральном уровнях.

Играть по принципу "больших чисел" нельзя - нужен точный учет. Т.е. что бы систему приняли, она должна быть АБСОЛЮТНО точна - ни одного лишнего или неверного голоса и все должны быть в ней. Т.е. кто имеет право голоса по Субъекту - должен быть в нем, кто не имеет - ни в коем случае находиться там не должен.

Надеюсь я все доступно изложил. А то у меня бывают с этим проблемы.

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

А вот как нам такое делать?

В ТСЖ будут такие же проблеммы. Кто будет определять Участников ТСЖ и их вес (он зависит от площади)?

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

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

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

С другой стороны к этому серверу будет подключены те, кто это может определять - та-же ЖКХ, например. у них будет админиский доступ к этому серверу. Жилец, который уже сгенерировал свой персональный ключ, приходит в ЖКХ, отдает им распечатку со штрихкодом своего идентификационного хэша или флэшку с публичным ключем. Возможно, пишет заявление что это его ключ (с указанием идентификационного хэша). Таким образом нужная организация контролирующая субъект голосований получает связь человек-ключ без необходимости вносить в ключ персональные данные.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

А может быть лучше сделать это на уровне клиента? Клиент обладающий рядом свойств автоматом становиться членом субъекта. Например ключ должны подписать все участники субъекта-ЖКХ? Ну ли другие специфические требования.
Не хотелось бы опять решать проблемы через "особый" сервер.

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

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Тут наверно надо дать право выбора субъектам. Я например буду участвовать в субъектах где будет подписание всего ключа или по крайней мере ФИО даты рождение и строки о участие в субъекте. Сложности в подписании дополнительных строк не много, а эффект в защите от ботов заметный.

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

Да - я там добавил уже. Регулироваться это все, естественно, будет на уровне субъекта. Будет соответствующий фильтр в субъекте, в котором все это будет описываться.

Т.е. получается что фильтры по данным в ключе пользователя могут быть нескольких типов:
1. По наличию определенных данных в ключе пользователя (например id субъекта голосования), подписанных определенным количеством других участников субъекта. В качестве параметров фильтра будет указываться необходимая строка данных и количество участников субъекта, которым необходимо подписать эти данные;
2. По условию к определенным данным в ключе пользователя, задаваемым в виде "КЛЮЧ:ЗНАЧЕНИЕ". В параметре фильтра будет: имя ключа, условие для данных, количество необходимых подписей участников субъекта у данного значения, количество необходимых подписей всего (не только участников субъекта) у данного значения;

Хотя, для универсальности эти два виду можно свести ко второму варианту.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Да второй вариант отличный. Наверно надо оставить его.

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

И еще один интересный нюанс мне пришел на ум. Например есть некий субъект в котором все участники должны ежемесячно оплачивать хостинг. То есть каждый участник должен до 1 числа перевести на определенный счет 100р например. Кто не перевел тот исключается. Можем ли мы автоматизировать этот процесс.
Или даже можно взять ситуацию вообщем: участнику субъекта что бы оставаться участником необходимо сделать некое действие в интернете.
Как этот процесс автоматизировать что бы не было "особых" людей следящих за этим.

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