Loomio
Mon 8 Oct 2018

An Exercise in Decentralization

MS
Michael Shea Public Seen by 240

A learning through doing project.

To deepen knowledge around decentralized systems that will operational, performance and security requirements of true enterprise class systems.

Please review and comment in the proposal document : https://docs.google.com/document/d/1jfMOXH7ZW3Hipqgx2wBq370BptbwAzMe6TJ8ZqiqXbk/edit?usp=sharing

JF

Josh Fairhead Mon 8 Oct 2018

Sweet, I'm in for this one! One thing is that the doc is view only at the minute so comments (via phone) are not currently working :).
Perhaps now we should discuss action points around the proposal? How SHOULD we move forward? What's currently need for first steps?

MS

Michael Shea Mon 8 Oct 2018

MS

Michael Shea Mon 8 Oct 2018

Here are initial action points that I see (and I am open to suggestion/correction)
1. Agreement on system to work through (I suggested utility as I am familiar with the structure and design of the current centralized model)
2. Identification of those interested in participating in effort. Understanding of backgrounds, and what they are looking to get from the effort.
3. Agreement on system re-envisioning goals (degree's of decentralization, functional utility, operating cost minimization, data privacy and ownership, ...)
4. Initial analysis/requirements definition of centralized system, identifying major systems/subsystems that produce and consume data feeds.
5. Analysis of each system/subsystem of the centralized system. (I am assuming that each of these will be taken through multiple analysis cycles)

I think this is start and these will grow and evolve over time.

I will state this now, and it will always stand, I am always open to suggestions, questions, recommendation on different ways to attack this idea. For me I am looking for two main goals from this effort. To deepen my understanding of the different decentralized technologies, and to understand where these technologies really stand with respect to being able to operate under the operational expectations of existing centralized systems.

JF

Josh Fairhead Tue 9 Oct 2018

Okey doke:
1. Utility systems make sense as a top level category. Highly generalised and used by everyone. At this point, do you think we need to constrain things more? Water/Gas/Leccy all work fine if so, but if not its good to leave things open. I also add the suggestion of DNS lookup - a public utility thats rather centralised and quite dangerous. Its also a massive part of public web traffic so massive scale! "Approximately 95 million DNS look-ups everyday across 240 countries" - Wiki
2. I'm keen to practice Sociocracy3.0 style working patterns while deepening my understanding of distributed technology through practical exercises like this. Declarations of interest are certainly helpful but lets keep it an open space for those with varying levels of enthusiasm.
3. This point addresses questions of subjectivity. If we agree on an initial decision framework we can reiterate when the ground shits. A good framework like S3 allows iteration on the process itself. If we go agree to go that route, the arbitrary decisions we make now can be rolled back. None the less I think that going hardcore centralised route first is a good building block as it poses the biggest challenges to decentralised infrastructure - after which I'd consider the optimal level of decentralisation as the safest for the given application. We can acknowledge the brick-strings not a magic bullet for everything!
4. I'm not particularly experienced with developing large systems but Larry Mix might have a few to donate? I'd be happy to get in contact again; he's likely to have some things and might even wish to contribute :) What are your thoughts? You guys were talking a fair bit no?

MS

Michael Shea Wed 10 Oct 2018

Interesting on DNS... Know conceptually what it is doing, but no real depth to the knowledge, but do agree it is a modern day cross-border utility and as such brings a interesting challenge.

Good to know on Sociocracy 3.0, I will admit not to having a real knowledge of this term/philosophy. I would also like to add, that I think we must time bound each of these efforts, to prevent over analysis and enable quick decisioning.

Good idea to reach out to Larry. Last I talked with him was just before summer, so definitely reach out.

Finally, how do we make Loomio fit these back and forths more naturally? Should these be forked into threads?

JF

Josh Fairhead Wed 10 Oct 2018

I've mailed Larry, hopefully he will come say hello or provide interesting diagrams :) S3 is pretty interesting, perhaps we should select activities to timebox: https://patterns.sociocracy30.org/timebox-activities.html

The last point I've been thinking about and have a couple of suggestions but lets discuss during that our call tomorrow.

MS

Michael Shea started a proposal Thu 11 Oct 2018

Let's look at Electric Utilities Closed Sun 14 Oct 2018

We are going to use an electric utility data collection and bill generation as the test system to take from centralized to decentralized.

Results
Agree - 4
Abstain - 0
Disagree - 0
Block - 0
4 people have voted (50%)
MS

Michael Shea
Agree
Thu 11 Oct 2018

JF

Josh Fairhead
Agree
Thu 11 Oct 2018

Seems the type of systems we'll be able to get most information on.

WA

Will Abramson
Agree
Thu 11 Oct 2018

DTJ

Darren T. Jennings
Agree
Sat 13 Oct 2018

JF

Josh Fairhead Mon 15 Oct 2018

From the picture in your document Michael it looks like things breaks down as following:

Tropos 7320
* Substations
* AMI collector (receiving from energy storage device)

Tropos 6320
* Feeders

Tropos 1410
* Feeders
* Reclosers
* Field area networks
* Voltage regulators
* Voltage controller
* Sensors
* Relay
* Video Camera

900Mhz network
* NAN
* AMI system

Links to each of them as item spec sheets are
https://www.rfwel.com/downloads/datasheets/tropos_datasheet_7320.pdf
https://www.logic-control.com/datasheets/48/datasheets/Tropos-6320-6310-outdoor-mesh-router.pdf
http://logic-control.com/datasheets/48/datasheets/tropos-1410-haz-bridge-mesh-router-hazardous-environments.pdf

So I guess that leads us to throughput estimation, which will vary greatly. The movement of the network is unordered, so a DAG structure is usable. Thoughts on where to go with this next though?