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

Сейчас я сделал так, что допуск пользователя к различным действиям в системе будет производиться на основании величины его индекса доверия. Индекс доверия рассчитывается исходя из некоторых параметров ключа. Вот примерный список:

Список учитываемых параметров

'Идентификатор правильного формата' - присутствие в ключе идентификаторов (сток данных) правильного формата. Здесь имеется ввиду идентификатор типа ФИО (язык) <емэйл>;

'Атрибут правильного формата' - атрибут с данными правильного формата. Аттрибут типа даты рождения;

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

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

'Не подписанный идентификатор' - отрицательное значение. Уменьшает индекс доверия если в наличии есть идентификаторы или атрибуты не подписанные другими ключами.

'Нет персональных идентификаторов' - отрицательное значение. Уменьшает индекс доверия если в ключе нет ни одного идентификатора или атрибуты нужного нам формата.

'Существующая подпись' - Увеличивает индекс доверия если ключ, которым подписан идентификатор, присутствует в базе системы.

'Отозванная подпись' - отрицательное значение. Наличие в ключе отозванной подписи. Возможно, имеет смысл ставить нулевое значение, во избежание понижения индекса доверия манипулированием подписыванием и отзывом.

'Подпись ключем с положительным индексом' - Повышение индекса если подписавший имеет в системе положительный индекс.

'Подпись ключем с отрицательным индексом' - Понижение индекса если подписавший ключ имеет в системе отрицательный индекс;

'Неподтвержденный адрес email' - Понижение индекса доверия если есть адреса email из ключа, которые еще не проверены на достоверность;

'Подтвержденный адрес email' - Повышение индекса доверия за каждый подтвержденный адрес email из ключа;

'Присутствие всех обязательных данных' - При наличии правильных данных ФИО+дата рождения, повышает индекс доверия;

'Отсутствуют некоторые из обязательных данных' - Понижает индекс доверия если в ключе есть не все обязательные данные;

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

Планируемые параметры

'Объем сообщества до 5-го уровня подписи' - анализируются подписи до 5-го уровня и анализируется количество уникальных ключей. Чем больше такое количество относительно количества подписей, тем выше уровень доверия.

'Разброс дат регистрации ключей в подписях до 5-го уровня' - анализируется разброс дат регистрации ключей подписей до 5-го уровня и анализируются даты их регистрации. Нужно для того, что-бы человек не мог нагенерировать 100 своих подписей, взаимно подписать их все и использовать в системе.

Операции к которым допуск будет рассчитываться по индексу доверия

- Создание и управление субъектом голосования:
- создание субъекта;
- добавление экспертов в совет;
- удаление экспертов из совета;
- создание голосований;

- Голосование;

Что нужно?

1. Нужно определить величины индексов для каждого из параметров;
2. Нужно определить какие параметры еще добавить в учет, а какие исключить;
3. Нужно определить величины индекса доверия для выполнения операций;

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

1, Согласен "Идентификатор неверного формата" нужно убрать он нам ничего не дает.
2,'Не подписанный идентификатор' думаю нужно сделать подпись 2 ключами пороговым значением. после этого можно принять участие в голосовании, но необходимо еще учитывать чьи это ключи.
3, Неподтвержденный адрес email большой минус.

Нельзя ставить эти возможности в зависимость от индекса эти возможности дополнительный параметр

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

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

Каким образом учитывать чьи это ключи? Интересуют конкретные варианты правил.



Так и сделано.



Вот здесь есть чисто технический момент. Если всем позволять создавать субъекты и голосования, то любой сможет уронить систему переполнив БД. Какой-то минимальный отсев должен быть.


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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Предлагаю так:
1Ключ имеющий ФИО, дату рождения и подтвержденный 2 ключами имеющими индекс 0, тоже имеет индекс 0 и может голосовать.
2,Тех кто может устраивать голосования определяет каждое сообщество внутри себя и это отдельный индекс.
3, При неправильном формате данных человек не должен иметь возможность зарегистрироваться вообще.
4, Через емайлы общаться крайне не удобно, предлагаю сделать графы телефон, скайп и аську необязательными ля заполнения тогда.

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

Мне кажется что 2-х подписей маловато, все-таки. Лучше уж 3 или 5, как минимум.



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



Ну, можно организовать.



Я, честно говоря, не понимаю почему вы емэйл считаете неудобным средством общения. Думаю, вы передумаете, если к вам целый день через каждую минуту в скайп будут ломиться на предмет помощи с регистрацией. Даже если это будет чат, держать открытыми штук 30 окон, думаю, вам не очень понравиться. При том что большая часть собеседников будет возмущаться почему вы им так долго не отвечаете. Голосом ситуация еще хуже, т.к. ваш номер будет постоянно занят и никто к вам дозвониться не сможет.

Электронная почта в данном смысле намного более удобна. Даже если будет желание пообщаться другим способом - можно договориться по электронной почте. Многие люди не хотят публично распространять свои контакты для живого общения, т.к. массовое живое общение и крайне утомительно и нерационально.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Давайте начнем с 2, потом можно будет увеличить.

Я писал про право назначать голосование по какому то вопросу. Это право определяется уставом организации, а в случае территориального голосования давайте решать позднее когда будут прецеденты. А в отношении права голосовать с Вами полностью согласен.

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

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

Ну, для начала давайте так. Значит к голосованию должны допускаться ключи:
1. Имеющие фио и дату рождения в данных на двух языках;
2. И имеющие по 2 подписи всех этих данных ключами, которые зарегистрированы в системе и имеют положительный индекс;
Т.е. надо так подогнать значения индексов что-бы выполнялось это требование (значение 0 примем за допуск к голосованию).



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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Да все так.

Не совсем так, в каждом субъекте свой устав там и написано кто инициирует голосование. например в ООО, по моему 10% акционеров. вообщем у всех по разному.
Думаю так инициировать голосование может обладатель индекса 0 и выше, обладающий полномочиями инициировать голосование согласно уставу субъекта.
На практике это означает, придется вручную присваивать для каждого бладающий полномочиями инициировать голосование этот статус по каждому субъекту и хранить эти данные в базе.

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

ясно, хорошо.

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