CoPPER: Communities of Practice, Production, Enterprise & Resources

[nanomonkey]

Title (same as in your application form)

CoPPER: Communities of Practice, Production, Enterprise & Resources

Team member names

Scott Garrison and Spencer Hadley

Short summary of your improvement idea

To facilitate next generation cooperative organizations and marketplace discovery through a decentralized “social networking” production planning and supply chain protocol.
We plan on finalizing and testing a reference implementation (open source software) which embodies these concepts.

What is the existing target protocol you are hoping to improve or enhance? Eg: hand-washing, traffic system, connector standards, carbon trading.

Global and local supply chains, the gig economy and captured market places (Amazon) are all dumpster fires of extractive practices that don’t suit the needs of manufacturers, laborers or even consumers. They are in need of a more meaningful and open protocol which simplifies the discovery process, interoperability and feedback. We are working on a decentralized solution that uses the common folk’s vernacular of Recipes as a focal point of project planning.

What is the core idea or insight about potential improvement you want to pursue?

After building a resource management tools used by Disney, Delta Airlines, and Amtrak as well as other industries, we’ve found that the fundamental records and transactions can be distilled down into a simple model, which has has easily recognized terminology that can be pulled from every day usage, such as Recipe ingredients instead of Bill of Materials (BOM). Coupling such an accessible tool to a decentralized offline first peer to peer protocol allows groups to coordinate their efforts in novel ways; creating flexible supply chains, more in depth lot and providence tracking, democratic work environments with easily accessible user feedback.

What is your discovery methodology for investigating the current state of the target protocol? Eg: field observation, expert interviews, historical data analysis, failure event analysis

We will go to existing businesses, cooperatives and households and test their efficacy in use. A professional UX engineer will assist us on getting appropriate feedback from field studies with the reference software. And of course we will personally be using the software ourselves to manage the project itself.

In what form will you prototype your improvement idea? Eg: Code, reference design implementation, draft proposal shared with experts for feedback, A/B test of ideas with a test audience, prototype are, etc.

Open source software with documentation of it’s design choice and usage with Secure Scuttlebutt as the p2p transport. No payment processing will be worked out, these will be left to existing channels.

How will you field-test your improvement idea? Eg: run a restricted pilot at an event, simulation, workshop, etc.

We have a construction company that has expressed interest working with us. We also plan on reaching out to local cooperatives (Arizmendi Bakery, Omni Commons, the Berkeley Student Coops). We have Indigenous communities in New Zealand and Brazil running local networks that are familiar with the project and are excited to put it to use.

Who will be able to judge the quality of your output? Ideally name a few suitable judges.

Robin Hahnel & Mitchell Szczepanczyk who work in Participatory and Ecological Economics.

The software will be available to all, and have open feedback channels. That being said we’d like to pass the Mom test, and be usable by the general public.

How will you publish and evangelize your improvement idea? Eg: Submit proposal to a standards body, publish open-source code, produce and release a software development kit etc.

By publishing open source software with ample support documentation. We hope to engender symbolic partnerships, by making tools for the commons and folding community into the process of improving the tools to better serve them.

What is the success vision for your idea?

There are many facets to this vision being a success, and they all center around group coordination and feedback loops. The long term vision is new economies rooted in relationships, to achieve large scale change we need to stimulate individual and collective growth. Providing tools that deliver immediate value, and also support further learning and collaboration.

We envision novices using this tool to organize their household tasks, building up a knowledge base and experimenting with peer feedback. As experience grows, an entrepreneurial individual can use these skills and tools to coordinate freelance jobs or produce goods for their community on an open platform. Familiarity in inventory management, scheduling tasks and creating or improving production process recipes along with giving constructive feedback to improve on existing processes will grow as they take on new projects. Outside of their work environment there will be healthy economic marketplaces for goods and services built with similar tools, where the integrated nature of the open protocol creates supply chains where the providence of items can be tracked.

Businesses will see great benefits from a platform marketplace that does not skim their profits, or hold their data hostage with marketplace capture, instead they’ll gain valuable insight and market fit by allowing folks to share feedback about their concerns around invisible labor, animal and environmental welfare, as well as their appreciation for beauty and fine craft.

[nanomonkey]

For more context: Resource Planning goes by many names in many industries: ERP, Inventory Management, Production planning, etc. and has just as many industry standard terms: BOM (Bill of Materials) vs. Ingredients, RQA (Request for Approval), BTO (Built to Order), etc. All of these terms, while meaningful, can and should be distilled down to a common protocol utilizing simple vernacular that can be understood by anyone that has filled out an online shopping cart or created a grocery list.

By using Secure Scuttlebutt as the p2p gossip protocol, each user will have their own ledger to which they can capture their own recipes of processes, schedule, purchases and feedback. Their ledger and those they follow are cryptographically signed and thus transactions and messages are content addressable, and verifiable to other users, creating a Merkle tree, a distributed database where each user can reference the work of other users, without needing global consensus.

All feed distribution is done on a pull basis, so you can focus in on suppliers and collaborators of your own choosing, without blocking other users from interacting with users of their own choosing, giving or receiving feedback, etc.

Each user can clone the production recipes, inventory, equipment and task information of other individuals that they collaborate with, and tweak attributes to their own liking. This allows for an extremely fine grain “voting” system where each user evolves processes to their own liking, taking on the changes of others who they agree with, to merge into a group consensus when needed, or individual preferences when allowed.

Currently there is no intent to build payment processing within the tool. A marketplace of goods and services is part of the tool, but payments are simply a part of the terms of order contract forms, and thus can be on other chains (Ethereum, bitcoin, cash, GNU Taler, local currencies, barter, etc.).

Transactions can be encrypted to an individual or group, thus hiding secret transaction that may cause harm to individuals. That being said some markets will benefit from public transactions, as they allow the end user to view the providence of the supply chains, not to mention can be used to show proper equity distribution and counter invisible labor practices. B-corps, cooperatives and gig economy workers all stand to gain through the use of such as transparent system.

If anyone has any further questions, or comments, they’d be appreciated. Thanks!

[valyagolev]

What you describe is an interesting problem!

we’ve found that the fundamental records and transactions can be distilled down into a simple model, which has has easily recognized terminology that can be pulled from every day usage.

A friend of mine is (also?) trying to start a small AI-powered planning startup, and while talking to him I’ve thought of the following. (I’m not sure he’ll use what I told him so here’s it for you as well). Maybe it’s close to what you’re saying.

We were talking about the planning process, like you want to build something huge with a lot of suppliers (am I correct that this is what you’re tacking?), and it takes a couple years to even plan. So there’s a big Excel (heard of the f1 team still using excel for the whole car planning?) or a Microsoft Project or a JIRA or whatever. And all those many months people exchange some emails, each email leads to a change in some little detail, the Excel/Project/JIRA gets edited accordingly, the formulas update, the charts change, some necessary rearrangement happens.

Now, all this incoming stuff (emails) is not represented in those sheets directly, but is only there as an external cause of a particular difference. Basically: there’s a stream of emails, that causes the stream of diffs, that are aggregated into what people who open the Excel/Project/JIRA pages see. This conversion between the streams is done completely manually, and typically in such a way that there’s no way to tell (without much searching) which particular email caused which particular change. (This makes it easy to lose changes, misinterpret them, or lose their correct ordering between streams)

Wouldn’t it be cool to make all of the incoming information part of the resulting model verbatim? So you could say: here’s an incoming fact, here’re its intepretations in the formal terms of the model. This seems to already make this whole thing much stricter and better auditable. (LLMs, I think, can help with this matching a lot, make it less of a hard, boring bureaucratic labor.)

Is this what you mean by the ledger?

I think coming up with such a matching protocol in a universal way, so that it can be integrated with Excel/git/JIRA/emails/whatever, has a clear vocabulary, some reporting tools, some experiments in semi-automating the matching process would be a blast.

I think having it (at least potentially) interoperable with the existing modelling and communication tools would be very important, as I don’t think people are eager to move from those

[nanomonkey]

Yes @valyagolev, secure scuttlebutt (ssb), and blockchain technologies for that manner, have signed transaction on a ledger. In the case of SSB, each person has their own ledger (signed append only log), instead of writing to one consensus ledger. This allows for feedback, and changes to be perpetually stored and referenced by other people as each message has a content addressable hash. So newcomers can reference why a decision was made, and customers can point back to the specifications that they were given at purchase time, even if these change over time.

Updates to a dataset are done in a similar fashion to how datalog or datomic stores updates to attributes. With a simple merge algorithm, based off of CRDTs (Conflict-free Replication Data Types) so that each update merges in a consistent manner, despite being a distributed system. So time travel (data archeology) is built in without much overhead. Views on datasets are very reactive, and changes flow though much in the same way as changes flow in Excel.

But yes, the idea is to not create any new terminology, or more importantly process flows, but to refine down to more common household terminology so that it is easily understandable by anyone dropped into the system (with easy UI overrides for those that insist on specific terminology being used). And hopefully because of the peer to peer nature, importing pricelists, specifications and other supplier data becomes automatic.

[bumblefudge]

This is really cool, and I think the layering is interesting. I think leaving payments to a higher layer and letting individual deployments of the protocol implement payment rails 1by1 on top makes more sense-- NGI Taler just opened a tender, btw, so finding likeminded folks to get cracking on that might be easy.

I’ll have a think on prior art, it’s kind of two distinct cottage industries with different core competencies between the US (mostly focused on industrial supply chains like steel or big ag) and EU (mostly focused on ESG/regulatory reporting and verifiable slavery-free supply chains). The latter has some precedent for this in Gaia-X/NGI toy implementations, but not sure anything directly directly relevant.

[Rithikha]

Love this proposal – I feel like there’s a bigger protocol here around value flows (locally and globally) that the inquiry your suggesting plugs into. Feels like a good project that has the potential to interface with many different kinds of on the ground organizations and groups (e.g. cooperatives, small businesses, individuals, bigger companies, and probably even cities/neighbourhoods.

I know there are lot of web2 supply chain solutions that are starting to gain traction (an industry that still needs to undergo a big disruption), but this seems like one area where a dweb approach actually makes sense and would directly value add to the product/solution.

[mixmix]

In the Maori (Indigenous New Zealand) context which I work in, local-first p2p is probably the only way to do safe, accessible community infrastructure. This is based on research revealing:

• corporate or foreign owned servers are not safe enough
• self hosted, centralised infrastructure are too expensive + brittle
• many communities have intermittent internet

This is a tool our communities want and need.

[spencer]

A protocol based approach seems necessary for the next step in networked material relationships.

We have all manner of rules and procedures that we interact with, conscious and unconscious. Murray Bookchin advanced the ideas of anarchy he inherited to include the natural world. He tied our understanding of human nature to all of non-human nature, making a continuous spectrum of agent based interactions of life. When we take an agent centric understanding of motivation and interaction we can develop systems that unravel the destructive patterns of extraction and replace them with cycles of functionality where repercussions are accounted for.

The building blocks of respect and trust are autonomy and connection to repercussion, or said otherwise ongoing relationship. Protocols are the proper way to empower people and communities towards long-term improvement. The key to separating protocols from imposed rules is respecting the difference of perspectives around a singular reality.

A kitchen can be said to produce meals and while that’s true it’s also incomplete. Protocols are meaningless until they are owned and expressed through someone. A baker can have feeling and meaning in their work. Perhaps it’s just a job to them, perhaps it’s a calling. The difference between the two is internal. How they do their job is an internal conversation that can change within a day or over a career. Every baker can have their own style. Recipes are shared, memorized, altered, and revered. Each recipe can have substitutions. An ingredient can have a special providence or be a commodity. A kitchen helper will have a separate relationship to the stock on the shelves. When asked to shop for today’s bake the helper will make a list for all the recipes, break it up by store and perhaps arrange the order of the items by their location within the store. The accountant might only be interested in the receipts of revenue as compared to expenses. The same eggs mean three different things to these three different people. When we work in virtual space all of these interactions can be automated but when we admit that the lives of these three people have myriad influences and interactions then cycles of incentives are beyond the domain of computers. If humans are not to be dominated by instructions from AI then we need to work on the respectful boundary between digital truth and meaningful human lives. I find unquestionable the need for human autonomy. We need to be free. We shouldn’t be tricked into working for abstracted values. We need to live through purposeful work.

Simply put, the baker should write the recipe the way that makes sense to them, same for the helper and the accountant. The content of their interaction is the kitchen and it’s products which they all have an understanding of. They all retain their autonomy while being able to be observed and judged by the others. They both share the truth of the interaction while simultaneously have their own perspectives on that reality.
If we are to make computers helpful to people interacting with the natural world we need their humanity to be fully expressible. Salmon is complex. As understood by a computer “Salmon” is only a string. But by a cook salmon is a protein with a smell and color. And by a fisherman salmon is a creature to be caught, but not too many or when they are too young. The importance of protocol in this situation is that when the information of a salmon is passed from the fisherman to the cook each on owns their own relationship to that information. They each have internal processes for developing their own work. If we stay with centralized services provided by private information companies then all definitions are rigid and only changed when the company decides to. The higher fidelity replication of reality into computer assistance is if a digital artifact is owned by the fisherman, then transferred to the cook, with providence kept through the record kept by both. This way each actor can interact with their system in a personal way. Said more simply, a baker might write up an ingredient list that includes sea salt, a computer gives that item a unique identifier (1234QWER), the helper goes to the store. The helpers list says sea salt, understood by the computer as (1234QWER), but the store has four sea salts. The helper chooses one, changes the line item to Maldon Sea Salt, while the computer still has the item labeled (1234QWER). Now whenever the cook next sends a list with “sea salt” the help will see on their list (Maldon Sea Salt). With this system each player owns their task and develops their own internal state as they interact with those around them.

[nanomonkey]

Thanks for all the feedback everyone!

There is now a more refined proposal that hopefully gives a better account of our vision and the steps we intend to take to make it happen. Any further feedback or encouragement is welcome.

Thanks again.