Cool. I added a script that automatically updates the motions/README.md with the motions and their hashes.
Looks like this: https://github.com/jgeewax/nubits-law/blob/master/motions/README.md
Script lives here: https://github.com/jgeewax/nubits-law/blob/master/scripts/generate_motions_table.py
I’m currently lacking the time to give a proper response to your tremendous proposal… All I can tell you for now is, that I imagined it like this: https://github.com/bananenwilly/nulaw/issues/1
After digging around in here a bit more, it seems like we should split content from presentation. Without this, cosmetic changes would require motions and votes, which seems off to me, but I could be wrong.
If that sounds like the right direction, it might make sense for the codex to actually be a set of structured JSON documents rather than plain text which we modify with diffs. We could use a super slimmed down organizational structure (hierarchy) defined by the US Code which is basically:
Title -> Subtitle -> Chapter -> Subchapter -> Part -> Subpart -> Section -> Subsection -> Paragraph -> Subparagraph -> Clause -> Subclause -> Item -> Subitem
Thought I doubt we’d use all of these levels of hierarchy, so we could do…
Title -> Chapter -> Section -> Item
Using @willy’s link from above, his text was:
§ 1 - "Motion for protocol changes" (Author: JordanLee) - Passed on Block 35532 (5 Oct 2014 14:52:55)
(1) Permit shareholders to vote to set transaction fees.
1. - Default transaction fees equal to the current transaction fees should be applied if there is no transaction fee vote for a particular currency in the majority of share days for the voting period of 2000 blocks. The share day weighted median vote will be the fee.
2. - The vote will consist of an 8 bit currency/share code and an uint32 expressing the fee in satoshis.
(2) Change the maximum interest rate rise from 1% per 1440 blocks to a per block rise of 0.002%. Enforce a maximum per block interest rate decrease of 0.004%.
(3) Remove the proof of stake difficulty floor of 0.000244414.
(4) Allow more than one motion vote per block.
(5) Transaction fees broadcasted in Blocks should be set using the fee from 60 blocks in the past. Parking rates in broadcasted Blocks shall also lag 60 blocks.
(6) Permit a custodial grant to have zero as the quantity of currency.
Note: This Guideline has been met with the release of NuBits v xyz on DateX.
Would translate to a file called title-1.json:
{
id: 1,
name: "Protocol",
chapters: [
...,
{
id: 4,
name: "Voting",
sections: [
....,
{
id: 7,
name: "Voting parameters",
items: [
{id: 'a', content: "All votes must consist of a currency/share code and a fee."},
{id: 'b', content: "Currency/share codes should be represented by an 8-bit unsigned integer (uint)."},
{id: 'c', content: "Voting fees should be represented by a 32-bit unsigned integer (uint32)."}
]
}
]
},
{
id: 2,
name: "Transaction fees",
sections: [
...
]
}
]
}
So then we can represent this as…
“Voting fees should be represented by a 32-bit unsigned integer (uint32).” - 1 NuBits 4 § 7(a)
Which says “See NuBits law Title 1, Chapter 4, Section 7, Item a”
Any likers/dislikers? It is pretty tough to strike a balance between “easy to deal with” and “easy to use as reference documentation later”
Making the source machine readable is probably the best way to go. It will be much easier to manage the presentation and parse specific points of data rather than trying to do it with raw text and some arbitrary dimiliters. Obviously not everyone will understand how to present their motions in such a manner, but maintainers of the codex only need worry about items which are actually voted in. Love the idea of wrapping it in JSON.
Didn’t find much free time until this weekend. I’m not sure how closely this follows your proposal, but I wanted to convert an existing motion over into a full JSON implementation to discuss.
I used this motion as the base, as it’s pretty simple. Which in turn was translated to:
{
"id": "1",
"name": "Liquidity",
"chapters": [
{
"id": "1",
"name": "FLOT",
"section": [
{
"id": "1",
"name": "Joining FLOT",
"items": [
{
"id": "1",
"content": "@mhps shall be one of the members of the First Liquidity Operations Team (FLOT)."
},
{
"id": "2",
"content": " @mhps will coordinate with other members of FLOT, and members of FSRT if necessary, to defend the peg."
},
{
"id": "3",
"content": "@mhps promises to be a part of FLOT for at least one year and to abide by all shareholder motions governing the use of funds."
}
]
},
{
"id": "2",
"name": "Limitations",
"items": [
{
"id": "1",
"content": "@mhps will be able to respond to any proposal for signing within 24 hours for 280 days a year, and be available on a best effort basis for the rest of the days. "
},
{
"id": "2",
"content ": "@mhps is able to carry out a maximum one signing a week, with its required investigation, discussion and deliberation, and no more than three a month."
},
{
"id": "3",
"content": "FLOT must be informed of exceptions."
},
{
"id": "4",
"content": "Being able to sign a request within 24 hours requires tools whithout which the response time cannot be held in case access to the internet is limited."
}
]
},
{
"id": "3",
"name": "Compensation",
"items": [
{
"id": "1",
"content": "Compensation for @mhps will occur in 90-day cycles, for a total of 4 cycles."
},
{
"id": "2",
"content": "By the end of each cycle, a total of amount of 435 NBT shall be paid to @mhps, conditional on satisfactory performance, which shall be measured in terms of his presence, effort and contribution."
},
{
"id": "2",
"content": "@mhps reserves the right to withdraw from his service if he does not receive the full amount of compensation by the end of any cycle or by personal discretion."
}
]
},
{
"id": "4",
"name": "Operation start",
"items": [
{
"id": "1",
"content": "The service of @mhps and the compensation cycles will commence from the passage of this motion."
}
]
}
]
}
]
}
You can manipulate it pretty easily from here: http://www.jsoneditoronline.org/?id=4f6422b4a6dacd6cfce853940bb73f3d
There was a number of formatting changes I had to make. If i’m understanding the point of this makes it easier to automate presentation and finding specific components of a motion, so those formatting changed were needed. Though the original motion hash can’t be computed from the text when any changes occur. It may be worthwhile including a B64 encoding of the original text for validating the motion hash from this source. Which (with removing the chapter for brevity) would look like:
{
"id": "1",
"name": "Liquidity",
"chapters": [],
"B64": "PG1vdGlvbmhhc2g+PHA+PGNvZGU+PSMjPSMjPSMjPSMjPSMjPSMjIE1vdGlvbiBoYXNoIHN0YXJ0cyB3aXRoIHRoaXMgbGluZSAjIz0jIz0jIz0jIz0jIz0jIz08L2NvZGU+PC9wPjxwPjxtb3Rpb250ZXh0PjxwPkBtaHBzIHNoYWxsIGJlIG9uZSBvZiB0aGUgbWVtYmVycyBvZiB0aGUgRmlyc3QgTGlxdWlkaXR5IE9wZXJhdGlvbnMgVGVhbSAoRkxPVCkuIEBtaHBzIHdpbGwgY29vcmRpbmF0ZSB3aXRoIG90aGVyIG1lbWJlcnMgb2YgRkxPVCwgYW5kIG1lbWJlcnMgb2YgRlNSVCBpZiBuZWNlc3NhcnksIHRvIGRlZmVuZCB0aGUgcGVnLiBAbWhwcyBwcm9taXNlcyB0byBiZSBhIHBhcnQgb2YgRkxPVCBmb3IgYXQgbGVhc3Qgb25lIHllYXIgYW5kIHRvIGFiaWRlIGJ5IGFsbCBzaGFyZWhvbGRlciBtb3Rpb25zIGdvdmVybmluZyB0aGUgdXNlIG9mIGZ1bmRzLiBAbWhwczwvcD48cD53aWxsIGJlIGFibGUgdG8gcmVzcG9uZCB0byBhbnkgcHJvcG9zYWwgZm9yIHNpZ25pbmcgd2l0aGluIDI0IGhvdXJzIGZvciAyODAgZGF5cyBhIHllYXIsIGFuZCBiZSBhdmFpbGFibGUgb24gYSBiZXN0IGVmZm9ydCBiYXNpcyBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRheXMuIEBtaHBzIGlzIGFibGUgdG8gY2Fycnkgb3V0IGEgbWF4aW11bSBvbmUgc2lnbmluZyBhIHdlZWssIHdpdGggaXRzIHJlcXVpcmVkIGludmVzdGlnYXRpb24sIGRpc2N1c3Npb24gYW5kIGRlbGliZXJhdGlvbiwgYW5kIG5vIG1vcmUgdGhhbiB0aHJlZSBhIG1vbnRoLiBGTE9UIG11c3QgYmUgaW5mb3JtZWQgb2YgZXhjZXB0aW9ucy4gQmVpbmcgYWJsZSB0byBzaWduIGEgcmVxdWVzdCB3aXRoaW4gMjQgaG91cnMgcmVxdWlyZXMgdG9vbHMgd2hpdGhvdXQgd2hpY2ggdGhlIHJlc3BvbnNlIHRpbWUgY2Fubm90IGJlIGhlbGQgaW4gY2FzZSBhY2Nlc3MgdG8gdGhlIGludGVybmV0IGlzIGxpbWl0ZWQuPC9wPjxwPkNvbXBlbnNhdGlvbiBmb3IgQG1ocHMgd2lsbCBvY2N1ciBpbiA5MC1kYXkgY3ljbGVzLCBmb3IgYSB0b3RhbCBvZiA0IGN5Y2xlcy4gQnkgdGhlIGVuZCBvZiBlYWNoIGN5Y2xlLCBhIHRvdGFsIG9mIGFtb3VudCBvZiA0MzUgTkJUIHNoYWxsIGJlIHBhaWQgdG8gQG1ocHMsIGNvbmRpdGlvbmFsIG9uIHNhdGlzZmFjdG9yeSBwZXJmb3JtYW5jZSwgd2hpY2ggc2hhbGwgYmUgbWVhc3VyZWQgaW4gdGVybXMgb2YgaGlzIHByZXNlbmNlLCBlZmZvcnQgYW5kIGNvbnRyaWJ1dGlvbi4gQG1ocHMgcmVzZXJ2ZXMgdGhlIHJpZ2h0IHRvIHdpdGhkcmF3IGZyb20gaGlzIHNlcnZpY2UgaWYgaGUgZG9lcyBub3QgcmVjZWl2ZSB0aGUgZnVsbCBhbW91bnQgb2YgY29tcGVuc2F0aW9uIGJ5IHRoZSBlbmQgb2YgYW55IGN5Y2xlIG9yIGJ5IHBlcnNvbmFsIGRpc2NyZXRpb24uPC9wPjxwPlRoZSBzZXJ2aWNlIG9mIEBtaHBzIGFuZCB0aGUgY29tcGVuc2F0aW9uIGN5Y2xlcyB3aWxsIGNvbW1lbmNlIGZyb20gdGhlIHBhc3NhZ2Ugb2YgdGhpcyBtb3Rpb24uPC9wPjwvbW90aW9udGV4dD48L3A+PHA+PGNvZGU+PSMjPSMjPSMjPSMjPSMjPSMjIE1vdGlvbiBoYXNoIGVuZHMgd2l0aCB0aGlzIGxpbmUgIyM9IyM9IyM9IyM9IyM9IyM9PC9jb2RlPjwvcD48L21vdGlvbmhhc2g+"
}
That way the original text used and voted on can be reproduced, since it cannot be reproduced from the codex format.
Is this in the direction you envisioned?
I think so 
It is missing a definitions section (in section 1.1 you do a combination of definition and membership, so we should probably break that apart), but on the whole I think it codifies more clearly what the motion was about.
It might be worthwhile to standardize the compensation across members, and then have a section that basically says, “The members of the FLOT are as follows: […].”
Thinking about the kinds of questions I want to ask about FLOT are…
Just a guess at potential structure, but I think we’re in agreement in the broad sense, which is “let’s get the facts down in a somewhat structured way, and then we can make it prettier using something else”.
In the future, my hope is that a git diff would be the representation of motion itself, with the diff containing:
The hash would be validated by taking the RIPEMD-160 of the diff body, which makes it super easy to validate:
$ git show 9af1128 | openssl rmd160
(stdin)= 0a46538843755990fac136b184bcbccf42e1a620
The validation script becomes pretty simple (pseudo-code…):
for each $commit
hash = `git show $commit | openssl rmd160 | cut -d' ' -f2`
assert motion_passed($hash) == true
Proposing a motion is effectively proposing a git commit, so when you have it all packaged up, the validation logic is super easy (no more questions about which browser you’re using).
To catch up, we’d effectively need to pass a motion that is “codify everything” as the initial diff. Not exactly fun, but the sooner the better.
I think for starters, you’re right that we need to include the original representation, and base64 seems like a reasonable enough choice.
@jgeewax you’re on fire!
@all others:
Please consider participating in the poll:
https://discuss.nubits.com/t/idea-nulaw/3250/10?u=willy
On geez, I keep having these epiphanies every time you post. My brain is just so hard wired to think about how Nu works in a certain way because I’ve been grinding away at it for almost two years. I’m still thinking in terms of ad-hoc proposals and motions. Even when willy proposed it. Derp. (I’m mostly here for my looks anyway).
What I put together for one past motion is intended format to rewrite all previous (and future) motions into a unified organized JSON document.
Now with that understanding I can really appreciate the rest of what is being proposed here.
I have some more thoughts to share but its 2am and they can sit for tomorrow.
You are gorgeous, no one can deny it.
We can have it on the front of the NuLaw book. Would be cute 
I apologize for unintentionally derailing this thread with my ravishing appearance.
Don’t worry @CoinGame – bringing us back to topic
Just to summarize what we have so far, here’s that status of what I’m proposing:
git rebase is your friend)git show <commit> | openssl rmd160
Seems like the “todo list here” is:
With great beauty comes great responsibility!
Haven’t had time to read through all this, but I hope you’ll stay around, @jgeewax! 
Not sure how to describe this yet, but do we have any way to make arbitrary parameters voteable and accessible for say bots?
I’m thinking FLOT members (and other future groups) may need to have different payrolls, which should be supported. We currently vote for fees in protocol onto blockchain. We vote the same way for motions except only a hash of it.
Would it be useful to have the payout value split out into a separate variable?
{
"id": "2",
"content": "By the end of each cycle, a total of amount of 435 NBT shall be paid to @mhps, conditional on satisfactory performance, which shall be measured in terms of his presence, effort and contribution."
},
Putting 435 (US-)NBT … somewhere.
"payment": {
"asset": "US-NBT",
"amount": "435"
}
Too complex?
I think if we can codify it clearly (ie, a single amount like your example), it would make sense to do that, with reasonable defaults of course…
This also ties into a separate question I just posted, not sure if anyone has an answer: [Question] Contract enforcement, doomsday, risk, etc (this topic is not very focused)
Fantastic summary. Allow me to utilize this wrench i’m holding and inject it into the discussion once again. This is a fundamentally different approach to governing Nu than what has been the process for many of us over the course of a year and a half (In a good way. I’m sold.). My first concern is that if we put forth a rigid structure for participating in the DAO it could be a very messy transition. Maybe this is an unwarranted concern, but I just wanted to raise it for discussion purposes. Before we go diving into shallow water.
If you look at previous motions they’re very free form. Most people here are volunteering their time trying to emulate roles that organizations have full time employees for. Even paid project members are only working part time and have other full time responsibilities. If the project grows the burden of supporting the services we offer weighs heavier on participants in managing those services (who are unfortunately rather limited at this point). Development, Nu properties, marketing, support, documentation, liquidity. There’s a lot of moving parts here and up until this idea was presented there was no “way” of doing things.
So I say all that to set the stage for my concerns. I know you’re new, so I wanted to provide a little background and put some context in for everyone else. I see you work for Google. I’m assuming they don’t have similar issues of having extremely limited time, money, and people to throw at important projects. We do.
I see implementing NuLaw as a really important project. To me, it’s huge. What you’ve presented is the direction we need to go. It’s a maturing process of the project and I think it helps to lead the way in governance for not only Nu, but possibly other projects with voting systems that could utilize the implementation. (B&C is on the way). There will be growing pains, but how can we make this implementation more transition friendly? That it can still embrace the free form nature of the current model while adopting this more rigid proposition over time. We don’t have the capability to literally stop what everyone is working on, call an ‘all-hands’ meeting, and instruct everyone to start doing it this way.
We’re going to need to build tools that make it easier for people to do things the “right” way in submitting motions and grants in the future. Also displaying all of the content from the documents we produce. People tend to move in and out of the community over the course of days, weeks, and months. It’s going to take time for everyone to catch onto these changes and adjust their habits. In the mean time we’ll still need to be passing motions/grants in the process of implementing all this without the changes impeding us. Also comes into play that some people just don’t have the technical knowledge of working with git, Github, hashing and other elements required in the new proposal.
This is going to be a common sentiment for a lot of people regarding the changes and implementation. Now maybe my concerns are unfounded. I could be over thinking all this. I think it would be beneficial though to consider that the structure should allow for more free form elements to be included. Not only for the transitional purposes but also because not all voted motions will be for NuLaws. They can also be to garner the support of an idea. Meaning we can vote and pass motions to encourage more debate and discussions on topics.
Or Similar to the process of petitions in the UK invoking debates among MPs. These motions wouldn’t be written into NuLaw in the same way that other contractual based motions would be.
So, how do we allow for this? I think we make it a two tiered solution. If you want your motion to be directly included into NuLaws you educate yourself on the process. Submit a PR with the diff hash and all required information included. Ask everyone to vote directly on that. It’s the process moving forward and fastest way to get your language into the book.
For others that prefer the more informal method, or for motions that are to garner sentiments on issues we allow for the existing process. Just put together some text, hash it and ask people to vote on it. If it passes then people with the understanding of using the first process would take that text and rewrite it into the proper format. This would have to then be voted on again to make sure the rewrite matches the language and spirit of the previous motion to be included in the law book. The verification script could be updated to recognize this type of event as well. The new PR would need to include the B64 encoded text of the passed motion in a unique field that it checks for. If the field exists it decodes the B64, hashes it, and checks to see that a hash with that text passed. Then it checks to see if the new PR was passed as well. If so then it’s good to go in the books.
The NuLaws system doesn’t even have to be “legally binding” until the process flows very smoothly. We can allow for the community to continue operating how it does while builders and maintainers of the NuLaws system refines the process (however long that takes). As motions and grants pass we can simply ask shareholders to also symbolically run the second vote of the two-vote system through. Then at some point when the process is matured we can run a final motion to vote the NuLaws repository as the “Network Constitution” if you will.
Keep in mind that this is volunteer time for me too…
Also, I swear that this isn’t the office:
I don’t think it’s unwarranted. Too much structure would alienate people, which would suck.
I think it’s important to note that this all feels like it’s still in requirement-gathering mode, trying some stuff to see what works. Maybe it’s just me, but until we started looking at the possible structure and fitting existing motions into those, I couldn’t really get a feel for whether the structure would work…
I absolutely agree.
Sounds good to me 
Can we at least say that motions should be plaintext rather than formatted on Discourse? Hashing rich-tech means a lot of potential inconsistency, right?
