You're claiming the design specification of the code is not related to the code? about epitome-django HOT 12 CLOSED

def identify_hasher(encoded):

from

https://github.com/django/django/blob/master/django/contrib/auth/hashers.py

Is the extant method django uses to ID stored password hashes.

You may notice that this routine detects some very old and woefully insecure password hashes and HANDLES THEM WITHOUT ERROR

Anyone with a method to get access on the django machine as the django user or root (like bribing some data centre employees for physical access), can get r/w access to the p/w hashes with the django credentials.

Also the password is in the DB, and most datacentres regularly backup the DB to tape.

For epitome, this is an error condition. An attacker with read access could look for hash collisions, or with write access, overwrite another users p/w with a known value.

Once you've lost certainty in your authentication system, you've lost the ability to record agreements. Agreements more complicated than a receipt must accurately record who has agreed. This is not ideology, but definition. Check with your lawyer and/or accountant.

Kerberos servers store the passwords in plaintext to enable hot-swapping of hash algorithms. Anyone who can root the Kerberos server can r/w all the passwords, and someone must be able to in order to install updates, but unlike a django server, a Kerberos server doesn't generate large amounts of traffic, so a group could adminster a Kerberos system over home broadband for a django instance in a datacentre.

Ideally for this purpose you'd want to deploy the Kerberos service over a TOR hidden service to obscure its location, however TOR has its own security risks.

The extant django system is fine for a system where account access doesn't grant much of consequence. epitome explicitly ties a vote to certain eligible users. This gives value to authentication data for those accounts to anyone wishing to influence a collective decision using those votes.

I'm not saying you want to disagree with the NSA, I'm saying you want to be able to disagree with the NSA. (Apparently they 'dispose' with a lot of datacentre backup tapes)

from epitome-django.

When the http://democracy.foundation/ people asked for a 'decision-making tool' they implicitly mandated sufficient authentication security for the task.

Computers are really dumb. If you were so drunk you were holding onto the floor to keep from falling off, you'd still have a better chance with identifying strangers over a IM.

The problem of how to identify users is a common one, and it's not the only common problem you have (threaded discussion / storage and iterarive development of complex text via proposal)

@MavropaliasG asked why I'd prefer to use a separate discussion system and proposal development system when you've got both. Well, you don't have both, you've a plan to code both. I'd rather use a spoon and fork to eat spaghetti than the idea of an automatic spork.

You've

• authentication
• authorisation
• threaded discussion
• proposal handling, and
• voting

as constituent components of your problem. All of those have already been handled somewhere else in a manner maintained by someone else, like Kerberos.

If you were to stitch previous solutions together with as little python as possible (discussion and voting might be simple enough to be worth custom coding), you could have a prototype in 5-8 days if you put the whole electorate in a single 'cycle' and dumped referendums to simplfy coding.

If a proposal has (50%/66%/100%) acceptance from the single 'cycle' or 'electorate' you don't need a referendum. Having one explicitly restricts voting by time. Doing that makes sense for a paper vote, but not so much for a (24/7 for no marginal cost) website.

Effectively, since the discussion board is recorded verbatim, one can claim it is minuted. If it is minuted, it can be a company meeting. If it is a company meeting, company members may propose and vote on resolutions. If the company meeting never officially ends, there is no need for the polls to close. If there's no need for the polls to close, why should they?

from epitome-django.

http://blog.jobbole.com/76867/

This is beautiful. Unlike your map it shows the development of the proposal over time.

The master branch is the current official position of the group.

Proposals are made in a branch named as username. They must directly descend from the current master branch.

When a proposal gains sufficient acceptance from the electorate, that proposal is merged into the master branch. Any active proposals that fast-forward merge with the new master stay active. Any active proposals that conflict with the new master branch are withdrawn pending amendment.

Also proposals may be withdrawn by the user, or sufficient active rejection to make acceptance impossible.

The part where the master branch moves, and the task is to identify which active proposals conflict and which do not, is key in handling 8, 80, 800, 8000 counter-proposals concurrently.

If the user wishes to register a PKI key, then the user can pull the repo and work offline on proposals, and submit them by push.

For those not so willing, or without their PKI key, facility can be made to edit repo files in a remote frame, and the django app with it's own PKI key can commit and push to the user's branch their finished changes.

Any user branch that becomes set to a point fast-forward mergeable with the master branch becomes an active proposal and may begin gathering right swipes immediately.

Views

• Security: Log of user's personal activity. Also public security events like p/w resets or n00b induction (so admin can't quietly change p/ws or print votes). Also change user's PKI key. Also (admin only) induct n00bs and password reset.
• User's proposal: edit user's branch
• Resolutions: Searchable log of changes to the current master branch, and current official text.
• Active proposals: That haven't yet been accepted or rejected by the user. Swipe right or left. Left requests a counter-proposal. Searchable text.
• Archive: Rejected proposals. If not referenced by a branch, these will eventually be garbage collected.

@MavropaliasG suggested 80 members pushing counter-proposals would be 'chaotic.' When really, 80 counter-proposals means that 80 members think there should be agreement, and it shouldn't be the original proposal. Maybe they'll negotiate a resolution that passes, maybe not. There's only the two options.

Also, if 80 people have counter-proposals, whose proposals would you silence and how would you call the system democratic afterwards? Likely they're lucky to have 3 unique good ideas in 80 counter-proposals to the same proposal, but the electorate have to be able to decide for themselves how they define 'good idea.'

from epitome-django.

Thank you for your comments and the code you've put into @mm0hgw . We'll have to review it at the end of the week. We'll might have to open a separate branch in the repository so we can work in parallel and merge them later. However, that decision is for @TokmakidisP to make as the lead developer.

However I will have to come back in comments with you and raise questions in regards to the git system you suggest. It still eludes me who will decide how the proposals will be merged if there is a conflict (its not code, its ideas that might differ), how this will be integrated as a frontent (we don't want users using git, but connect through website), and how we will not allow members pushing code or using other git functions that are not privileged with, restrict git functionalities so that users don't exploit them, integrate django authentication to it (or the web authentication that we will use) and how we will prevent the repository to be cloned and seen from someone outside of the community. Integration with the frontend is the most important, we don't want users to have to use git (not everyone is a programmer).

I will have to write down all these points in detail and discuss them with you. However your contribution and ideas are fantastic and we will definitely study them. Thank you very much.

from epitome-django.

"It still eludes me who will decide how the proposals will be merged if there is a conflict"

There will never be a conflict.

If a user pushes a branch which conflicts with the master branch, it is not listed as active until such time as the conflict is resolved.

When a proposal is accepted into the master branch, all branches are re-evaluated to see if they merge without conflict. Any that do not are dropped from the active list.

Attempting to accept a proposal not on the active list throws an error.

"We don't want users using git"

Why not? If someone gets serious about proposal development, why would you deprive the option from them?

"how we will not allow members pushing code"

Why not? How would it be possible to use epitome to create any rules about code if you're somehow restricted from pushing code to the repository that stores the rules?

"or using other git functions that are not privileged with so that users don't exploit them"
"how we will prevent the repository to be cloned"

You haven't thought that through. You do want any user that can be bothered to clone the origin repo. If none do, then none will notice if the blockchain changes. If nobody cares, there's no point in having any rules.

"seen from someone outside of the community"

You haven't thought this through either.

Every user has the ability to ask for advice concerning any proposal from anyone they feel is qualified to give such advice. How do you propose to BAN this practise?

Loss, rather than theft, is the security concern for the resolutions and proposals in the repo.

Out in the real world, there are no countries with secret laws, or companies/NGOs with secret articles of association. It's not that secret agendas don't exist, but that once an agenda is public record, it is no longer secret.

"we don't want users to have to use git (not everyone is a programmer)."

You haven't thought this through. The issue is not whether users have to use git. The issue is whether users are able to use git. Users will presumably be able to edit text in a frame on the site without having to use git. For almost all users, this will not be their preferred text editor.

A computer program is a set of rules in a language. Anyone not creating a set of rules in a language has no business using epitome. As outlined previously, any agreement is a rule and rules must be in a language.

All the users of epitome, by definition, are programmers (not programmers of computers, but programmers nonetheless). To say they MUST NOT use git is stupider than saying they MUST use git, and this is not even what I proposed.

I proposed that users MAY (in future) use git to submit proposals. If a user can use git, mandating they MUST NOT builds pointless busy time into the system when the user likely will anyway, then cut-and-paste the results into the website

If you want users to take this as seriously as you would like to (you need to think it through to take it seriously), forcing pointless busy work upon the users is counterproductive. They're not all too stupid to learn git, but those that are have a limited attention span.

from epitome-django.

https://www.englishlacrosse.co.uk/annual-general-meeting-minutes/

This is a sample NGO. These AGM minutes are public record. Any formal proposal made and any formal vote taken at the AGM, is recorded in the minutes.

Not every word spoken at the AGM is recorded in the minutes, but while an AGM is not public, it is also not an event in which to expect privacy.

The US first amendment protects the right of people to say things. It doesn't protect people from the consequences of the things they say.

Similarly, protecting people from the consequences of the things they say is wildly ambitious for epitome.

from epitome-django.

“Not every word spoken at the AGM is recorded in the minutes, but while an AGM is not public, it is
also not an event in which to expect privacy.”

“Out in the real world, there are no countries with secret laws, or companies/NGOs with secret articles of association. It's not that secret agendas don't exist, but that once an agenda is public record, it is no longer secret.”

To give the ability in a community to have their deliberation in private is definitely something we want to ensure. Countries and NGOs wont be the only users of epitome. Epitome will be probably used widely from corporations and organizations that would like to keep their internal affairs hidden. You can’t force a community to have their discussions in the open if they don’t want to. If we decide to build upon git which I start to like the idea, we must ensure the repository for each community will have the ability to not be publicly viewable. Being public will also be a option. Communities should have every possible option and customization they want.

#########

“If a user pushes a branch which conflicts with the master branch, it is not listed as active until such time as the conflict is resolved.”

Let’s first make sure we are on the same page. I believe your model is quite different from ours. We want users to base their own “fork” of a proposal to a previous proposal by another user, and not merge their changes in the same proposals. In a nutshell: I believe in your model you want users to work on one file and improve that file. We want each COMMIT to be a different node in the map, and users voting on which commit (that also includes all the previous commits it was based upon) they prefer. What do you think ?

#########

“"We don't want users using git"

Why not? If someone gets serious about proposal development, why would you deprive the option from them?”"

Because I fear that an advanced user may use git in such a way to exploit the functionality of the platform and do something that was not suppose to happen otherwise.

#########

“Users will presumably be able to edit text in a frame on the site without having to use git. “

I’m glad. Hopefully there is some kind of web application like github/gitlab written in python that we can borrow code from (or simply html/javascript?).

Would it be possible to be able to use this system only through the website ? Like have a token that only allows the website after the user has logged in to do commits?

Although a bit irrelevant to this, this is a pure python implementation of git https://github.com/jelmer/dulwich

from epitome-django.

"Epitome will be probably used widely from corporations and organizations that would like to keep their internal affairs hidden."

So... the mafia? Intelligence agencies? The military? Probably not. Secrets are incompatible with democratic operation. Organisations that wish to keep secrets are therefore hierarchical, impossible to implement as a democracy, and therefore have no use for epitome.

"To give the ability in a community to have their deliberation in private is definitely something we want to ensure."

I didn't say you want to store the threaded discussion board in the git repo. I don't know why you think I did.

"You can’t force a community to have their discussions in the open if they don’t want to."

You can. All you have to do is be a member of the group and you can publish the discussions to which you have been a party. If you'd previously agreed not to publicise the discussion, the group could sue you, but even then, they couldn't un-publish the discussion.

Even if the publisher broke the law in finding and/or publishing the discussion, it still could not be unpublished.

Further, by using a communication system that, by it's nature, records, epitome users could not possibly claim they had not consented to being recorded.

If you want to have secrets, don't talk about them on the internet.

"I believe in your model you want users to work on one file and improve that file."

Why do you think a git repository can only hold one file?

"users voting on which commit"

That's.... wildy ambitious. Too many commits. Each user has the option to propose as a branch. Accepting a branch doesn't mean accepting every previous commit. It means accepting every previous commit insofar as they remain unchanged by the subsequent commits.

i.e. A proposes 'So what about the Jews?,' B counter-proposes A adding 'Kill them all.' and C counter-proposes B removing his addition and adding 'what about the Jews?'

Proposal C is accepted, and commits A and B are accepted in as far as they have not been altered. Commits A and B now exist in the master branch development history, but neither was ever the target of the master branch, and the group never accepted the Jews should all be killed.

"Because I fear that an advanced user may use git in such a way to exploit the functionality of the platform and do something that was not suppose to happen otherwise."

What is this fear based on? This possibility exists with python, voting, legislation and servers too. In any system, those more familiar with the system have an advantage. We don't eschew systems because some are capable of taking advantage, we have lawyers.

If you knew a specific way that an advanced user could mess up a git repository to which they did not have write access, you could report it as a bug. Since you haven't, you're presuming someone may find an exploit and instead of reporting it, use it to persecute your users. The only way to prevent that possiblity is to delete epitome, ensuring no-one ever uses it.

"Would it be possible to be able to use this system only through the website ?"

Why do you think it wouldn't be?

"Although a bit irrelevant to this, this is a pure python implementation of git "

I don't think you can use that. It's Apache v2 / GPL v2. pygit2 is GPLv2 with a specific exemption for linking, so you can definitely use pygit2 as a dependency and still have epitome be MIT licenced.

from epitome-django.

"You can’t force a community to have their discussions in the open if they don’t want to."

Actually, there are very few people you can have a genuinely closed discussion with. Lawyer and priest. It's not me doing the forcing, just the way society works.

The point of the exercise is to produce agreements, which means documentary evidence that the agreements were made.

The reason evidence is required is that without evidence the agreement was made, one cannot expect a court or arbitration panel to accept an agreement was made, which means they can't accept it was broken, which means one clearly cannot have been injured by the breaking of an agreement which never existed.

When such evidence is taken to court, it becomes a matter of public record. The documentary evidence of the agreement exists for the sole purpose of demonstrating to outsiders that an agreement actually happened.

Court and arbitration isn't so much about truth as confidence. A claim with evidence to substantiate it is said to 'command confidence.' A claim without substantiation is said to be 'fraudulent.' Making fraudulent claims in court is not a good idea, even if they are true.

epitome is a tool for making communal decisions democratically. This restricts its userbase to those who want to make communal decisions democratically, meaning you don't need to concern yourself with the problems of people who don't want to make communal decisions democratically.

epitome will not work for people who don't want to make communal decisions democratically, like intelligence agencies, organised criminals and secretive people who won't openly put their name to a proposal.

You can't make a forum where hundreds of people have the ability to read and repeat every word you write and connect it with a verified identity 'private.'

from epitome-django.

“So... the mafia? Intelligence agencies? The military? Probably not. Secrets are incompatible with democratic operation.”

Secrets are not incompatible with the democratic way. A community might be secretive of their internal affairs being discussed, but they can still be decided democratically by consensus from every member. One is not different from the other. I don’t talk about the mafia and the military, I talk about companies or simply teams that don’t want for everyone to see what their doing internally. This is something that we definitely want to give the option to. I’m sure the git repo can be encrypted to be assessed only from an authenticated source (e.g. https://www.agwa.name/projects/git-crypt/ ). If it can’t we’ll have to find another way. It’s not secrecy, it’s privacy. It doesn’t matter if communities that you may participate in the future may never use it, it is important to give all options so that every kind of community may be able to use this tool. Our community and every community that I would like to take part in, I would like to be public, just like you suggest, but others in their community may want to keep it private.

//////////////////////////////////

“All you have to do is be a member of the group and you can publish the discussions to which you have been a party.”

Yes but that is a violation of privacy. I can also have a discussion with you over the phone, but you won’t expect me to post that online. If a community has a private access to the repository and you go and post it online, then that’s illegal.

“If you want to have secrets, don't talk about them on the internet.”

Then what about encrypted communication ?

//////////////////////////////////

“That's.... wildy ambitious. Too many commits. Each user has the option to propose as a branch. Accepting a branch doesn't mean accepting every previous commit. It means accepting every previous commit insofar as they remain unchanged by the subsequent commits.

i.e. A proposes 'So what about the Jews?,' B counter-proposes A adding 'Kill them all.' and C counter-proposes B removing his addition and adding 'what about the Jews?'”

No it’s not wildly ambitious. If indeed a user writes something bad, the next user will not commit on top of their commit, but on the previous version of the proposal. You are thinking as writing a code, this is not code you must understand that. In code there is a specific desired outcome that one tries to achieve. With deliberation it’s ideas, different from one another, you can’t merge them back to one file because it’s not something that is correct and that is the best way to be done like code, it is ideas and what is considered correct is different between people. We want a system that won’t have to follow an order of commits, but will be able to handle separate branches.

Image A is both linear and non-linear history. We don’t want that

Image B is a tree graph. That’s what we want. There is not a single branch where commits will be merged into, but separate branches. Each node is a commit of that branch and the person submits their commit on the node that they want, furthering that specific branch. If a branch is not supported then it dies out, no further commits are added to it. I hope git can work like this.

//////////////////////////////////

“"Would it be possible to be able to use this system only through the website ?"

Why do you think it wouldn't be?”

I mean is there a way to restrict access in other way apart from using it only through a website? I am asking because if someone is able to use git directly to push code, then we won’t be able to implement the systems of capital and cycles. Commits need to go through python to check their privileges of their user, and also coordinate participation according to the size and the configuration of the community.

//////////////////////////////////

“This restricts its userbase to those who want to make communal decisions democratically, meaning you don't need to concern yourself with the problems of people who don't want to make communal decisions democratically.”

Again let’s not confuse privacy with democracy. We need to give the options to restrict unauthorized access to the repository. You may not agree with it. I do not agree with it. But someone will want it.

from epitome-django.

"Secrets are not incompatible with the democratic way. "

Secrets are absolutely incompatible with the democratic way. The democratic way requires the electorate to make decisions. In order for the electorate to make informed decisions, the electorate must be informed. Anything the entire electorate knows about is practically impossible to conceal from private investigators, let alone state sponsored investigators.

Secrets could only be compatible with the democratic way if it were possible for the electorate to make decisions based upon information they don't have.

"Yes but that is a violation of privacy."

No it isn't. To be a violation of privacy, there would have to be an expectation of privacy. If you wave your genitals around in your bedroom, you've an expectation of privacy. If you wave your genitals around in a town meeting, you have no expectation of privacy.

EDIT: As outlined below, resolutions can't be both secret and enforceable, so they must have no expectation of privacy. When a user proposes a new resolution, they have no way to know for certain that the proposal will not pass. Thus, at the moment of proposition, the proposal must have no expectation of privacy.

EDIT: If all members of the group have read access to all the resolution, proposals and discussions, anyone who bribes any member of the group has read access to all the resolutions, proposals and discussions. In such a situation, it is practically impossible to guarantee privacy. All you can do is not mislead users by pretending privacy is possible.

"Then what about encrypted communication ?"

Encryption algorithms become insecure over time. Encrypted communication is only as private as its algorithm is secure.

AES came along in 2001, before that DES was standard. A flaw in DES has been discovered, and DES is no longer secure.

A secure conversation in the 90s, is likely not secure today.

EDIT: Further, encryption doesn't mean security. Skype is encrypted, but the way the Skype system works, both you and your conversational counterparty receive the session encryption key from the central server, which is owned by Microsoft, who share data with the NSA.

If you want it to be secret, don't talk about it on the internet.

"the next user will not commit on top of their commit, but on the previous version of the proposal"

That's not how people work. People will make most counter-proposals from commits they strongly disagree with. Naturally, this commit will develop from the commit they disagree with.

If you want to stop people acting like people you'll need a method of enforcement. Without such a method, preventing people forking from commits they disagree with is wildly ambitious.

"it’s not something that is correct and that is the best way to be done like code,"

I don't think you understand the situation.

There's no one answer to a coding problem. Solutions have a binary state with regard to whether they pass the unit tests. Further than that, there's a qualitative measure whereby unit-test compliant code that generates the answer more quickly is better.

There's no one answer to a negotiation. Solutions have a binary state with regard to whether they are understood by the negotiating parties. Further than that, there's a qualitative measure, where a greater degree of acceptance by the negotiating parties is better.

In both cases it is typically hard to prove that any particular solution is the best solution possible when tackling an issue of any significant complexity, so one typically settles for the best solution seen so far, but that doesn't make it 'correct'

"You are thinking as writing a code, this is not code you must understand that."

The law is code and courts are the machinery that process this code. Legislators are literally the programmers of this paperwork processing system.

Code is law, and CPUs are the courts of computers where decisions are made impartially, according to the law. Programmers are literally the legislators of the digital environment.

"Image A, Image B"

The data in image A could be displayed as a tree like in B. The data in image B could be displayed as a tree with a time axis like in A.

How you choose to display the data doesn't change the underlying static truth of what the data is.

If you don't want a single branch that tracks the current state of agreement, where exactly do you want the (singular) current state of agreement to be stored?

"I mean is there a way to restrict access in other way apart from using it only through a website? I am asking because if someone is able to use git directly to push code, then we won’t be able to implement the systems of capital and cycles. Commits need to go through python to check their privileges of their user, and also coordinate participation according to the size and the configuration of the community."

Branch restriction.
https://help.github.com/articles/enabling-branch-restrictions/

Tying user accounts to PKI keys.
https://github.com/settings/keys

If the only way a user can push to a repo by PKI, is by explicitly tying a PKI key to their account, exactly like github, then the permissions are pre-checked, and there is nothing left for python to do.

Coordination is handled by having a single entity permitted to push to each branch. Each user has an independent branch, and the master branch is only written to by the central app.

If group size and configuration somehow have some impact on the situation, you've utterly failed to explain how.

"Again let’s not confuse privacy with democracy"

We certainly don't want to be confused. I thought we were making communal decisions. These MUST be known by everyone expected to abide by them. Without major administrative infrastructure to force all participants to sign a NDA concerning the rules before joining the group and vigorously persecute transgressors, there is no reasonable expectation of privacy.

You can't easily both ban Jews from your group, and also keep it secret that Jews are banned by your group.

The closest you can get is the Equifax system, where they bind their customers to not publicly complain about their service, and also to resolve disputes through arbitration. This makes it practically impossible to verify the accuracy and usefulness of the data provided by Equifax before the contract is signed.

What makes this work, is that Equifax have big pockets to sue people who breach the NDA.

"You may not agree with it. I do not agree with it. But someone will want it."

Someone wanting it, doesn't make it practically possible. Not everyone who wants to be married to Katy Perry can be married to Katy Perry.

Nevertheless, you've got a better chance of getting Katy Perry legally married to everyone that wants than you do of having communal decisions that are both private and fit for purpose, because Katy Perry marrying a whole bunch of dudes is technically possible.

This is not a democracy thing, it's a communal decisions thing. A dictator makes communal decisions unilaterally, but if he bans sandals, and keeps that ban secret from the population, the police and the courts, has he really banned sandals?

from epitome-django.

Take Image B.
https://user-images.githubusercontent.com/13523909/34601848-b9aca7ec-f238-11e7-9264-f5849da79eac.png

Presume the central node is the current master, and its four surrounding nodes are A,B,C,D.

A is accepted, so the master branch moves to A. Everything downstream from A remains active, since they all ff merge with A. B,C,D and their children only remain active if they can merge commit A without conflict.

Now B is accepted, so the master branch moves to an A&B node not pictured. Children of A remain active if they can merge commit B without conflict. Children of B remain active if they can merge commit A without conflict. C,D and children remain active if they can merge commit A&B without conflict.

Taking any two steps from different branches causes the master branch to wander off the map never to return.

You're going to have user proposals that cause complex conflict resolution problems whether or not you use git. The fact thst git recognises and complains about conflicts does not make git the cause of conflicts.

If you, or @TokmakidisP or @pbout or @agelessbrain have any other proposal at all for how to handle the complex conflict resolution between multiple branching user proposals and the extant canon I'd love to hear it.

@MavropaliasG, you've not explained how any of:

• The law
• Computer programs, and
• The information generated by epitome

Are anything other than a set of rules in a language. In all three cases, there must be an understandable language in which the information is encoded.

If human language isn't encoded information, what can words possibly mean?

from epitome-django.