Shiro is a Japanse word for “White” or “Castle” but it is also used to describe the mycohrizal mats that surround and connect to roots in the rhizome. We envision this project as a fungal-like communication and transport network for local-to-bioregional (and beyond) foodstuffs.
The impulse that originated this project was seeing the potential that cooperative and community driven food buyers clubs could provide in shifting our food systems to healthier patterns.
The term buyers clubs, is a very direct translation from the Swedish word “inköpsförening” and a lot of the insight that intiated this project comes from existing buyers clubs in Sweden. There are lots of variations on how this might work and the term food cooperative is a far more common and ubiquitous term.
This project has at it’s core a desire to increase the operative capacity of food co-ops and buyers clubs and have them better fullfill the needs of humans and the ecosystems they are embedded in.
There are a few primary ways we hope to empower these organisational forms:
- Coordination of between organisations
- Increasing the generative capacity of organizations to support new ventures
- Networking for better loop closure and synergistic organising in the bioregion
- Technical facilitation for creating new organizations and supporting a community of practice
But before we look into these goals, what do these organisations that we are looking to support look like?
What are common patterns and practices of existing buyers clubs?
Some sort of physical space is needed in order to operate a buyers club. These spaces can vary in size and form. Sometimes they consist of a garage beloning to one of the members of the association, other times they take forms that are very similar to grocery stores. Often these spaces also serve as a community meeting point so space for hanging out or events are also common.
We could view these spaces as a shared storage space for all of the members of the association. A similar expression existed in Sweden as freezer houses which enabled a community to freeze food together before the home freezer was ubiquitous.
Basically, the association buys foods directly from producers or retailers that go in to the shared storage and members of the association can make “withdrawls” from that community storage as needed. Money is usually deposited to the association account which gives the members credit which they then deduct from as they withdraw goods.
There is usually some person or grouping within the association that finds suppliers and orders in the products. This is one of the roles that is neccessary to have a functioning buyers club.
Most of these associations operate with a very high level of trust. This trust is built over time as people get to know each other and have an organisation that works. Often times people are able to access the location where the foods are stored whenever they want with simple code or tag-access locks.
Often food is deliverd by logistics firms or by the producers directly, the goods are recived, unpacked and shelved by members of the association.
Basic sketch of a buyers club
Commonly, most of the work that is going into running a buyers club is done by the members of the club and is not paid. Differing sizes of collectives and other contextual variables can have the workload more or less taxing on the members.
Even with no staffing costs, these associations most likely need to pay rent, power bills etc to keep the club running. Money for this is often generated by adding a small margin on the price paid to the supplier/producer when the member withdraws food.
These margins, often in conjunction with yearly membership fees, can be laborated with to find models that work for each community.
Benefits of buyers clubs
- 24/7 access to foods/groceries
- Access to non-paid work (member engagements), enabler for “low-purchasing power communities”, Salaries are highly taxed…
- Cheap rents, less regulation and byrocrazy as compared to “stores”
- Purposeful community
- Builds trust locally
Evolving the model
The current implementation of the buyers club is often a linear process as shown by the diagram above. While serving very real and tangeable needs for the members of these groups we feel that they could also be highly valuable as points of entry for new food system innovations that can help shift us into much more regenerative practice.
One of the basic forms that we would like to transform is to stop thinking of the buyers club as a one way liniar process. Not just food from producers to members but instead turning buyers clubs into 2-way Local Community Food Centers. Shared storage and logistic functions is almost something of a holy grail when it comes to developing local food systems. We are hoping that we can get closer to solving for some of theese functions with newly emerging patterns and technologies.
Distributed and agent-centric system design
Why do it right now? What is a good approach to such massive endevours?
Connect to change everything at once. Full system shift
Holochain as a framework
Holochain is a data integrity layer for distributed applications. Basically a way to have both the applications and their required data storage run on all of the users machines instead of centralizing it on a server.
It is a framework that is made to be agent-centric. That is to say, that all applications built on Holochain will enable the agent (person, device or collective) to communicate with other agents through a bunch of applications it has installed.
This means that an agent stores all of the data connected to the agent and allows this data to be accessed by applications of the agents choice. Agents also hold a share of other agents data, one piece of the collective dataset through the use of Distributed Hash Tables.
The architecture is designed for full interoperability so that any application can bridge to any other application through the agency of any agent. I can allow applications to read from each other using my vantage point as a user. What this enables is for applications to be developed as microservices that can be stitched together as modules to create very complex applications without anyone being stuck with all the governance of the whole thing.
Another useful feature of distributed applications is that since they do not require dedicated servers, they are not locked into economic models in order to operate. There does not have to be a company in the middle. However, Holochain IS designed to enable flows of value in many different forms which can be viewed as current-sees. Transacting is a subset of what can be done in the architecture.
REA (Resource-Event-Agent) accounting making it all work
Further learning materials for REA
Credit systems and kickstarting local actors
One of the reasons for our interest in working with existing and new buyers clubs is the possibility of bootstrapping credit patterns that already exist in the model.
Often, buyers clubs function by having its members deposit money into a bank account, this amount is then credit for the member. When food is withdrawn by a member from the collective storage, an amount equal to the purchasing cost (often + small markup for the collective) of that food is debited for that member. It’s credit is reduced. When the members credit is close to zero, members are often notified of their need to deposit more money.
For some clubs there is a possibility to go into negative credit, that is to say to withdraw more food than one has deposited money. This is not a problem as long as money is eventually deposited and there is enough cash on hand for the organisation to pay for its purchases and other costs.
Normally this credit is only something that exists in the accounting books of the collective, but in Shiro, it would be relativly simple to implement features where credit can be transferred between members. Effectivly creating a local and somewhat resilient digital currency that is acceptable for anyone that frequently buys food through the buyers club.
A deeper level of benefit to this system is that credit could be extended to agents that are looking to engage with the collective. Here is an example of how this might work:
- A local vegetable grower that wants to start an enterprise fermenting cabbage to make delicious Sauerkraut.
- Naturally 30 people in the collective respond to an inquery that they would like to eat Sauerkraut.
- They all agree to send €20 of their credit to the grower as prepayment for 2KG of Kraut.
- The seller withdraws those 30 * 20 = €600 to buy 5 large fermentation pots and delivers the Kraut to all of the members and now has a fermentation business enterprise running.
This feature of the system could be increasingly useful when many buyers clubs integrate their systems and start collectivly ordering and kickstarting producers with larger pools of unused credit.
Going past food into food system
Initially, the system would be focused on facilitating the distribution of foods but there are many other cloesly related areas of high-interest for food communities, especially when food producers are included in this boundry of community.
Some of the areas where producers would be able to piggyback on this infrastructure (credit, logistics, order management, accounting, etc.) include:
- Fertility products (Compost/compost teas, Biochar)
- Seed/spore exchange
- Circulation of agricultural “wastes” such as:
- vegetable biomass (stem, stalk, hulls etc),
- mushroom substrates
Perspectives on the system
This is an inital mapping of the needs of the system as described through a number of modules that could be developed in time. Many components for these modules or possibly entire modules covering these needs are probably being developed by others right now, so hopefully a lot of this would not have to be developed within this project but could be created in collaborations with other usecases.
Here is a breakdown of what the different modules are needed for:
Buyers Club Inventory Module
At the core of the network there is the need to handle products. This module needs to handle things within a buyers club like:
- Amount of foods (Rice, Chocolate, Broccolli, whatever…) that have been delivered
- How much food is in stock
- Which member has withdrawn what?
- Ordering food from suppliers
In the context of creating this software with the purpose of coordinating multiple buyers clubs in order to enjoy some scaling benefits without having consolidating groups into larger and larger entities, it is also important for this module to be able to handle orders between clubs.
- What products do other collective offer that we could order in?
- What products are we making available to other collectives?
Another big piece is the ability to collectivly (as many collectives together) order larger orders from retailers or directly from producers. An example of this would be that 10 buyers clubs together constitute a large enough demand to warrent ordering a full container of coffee or rice from an international source. In order to do that, this module would also benefit from enabling collective purchasing.
This module would need to enable the actions of the members such as:
- Withdrawing food
- Updating member details
- Viewing available credit
- Transferring credit
Other features that would be useful to implement eventually would be tools for governance of the club (Likely to be integrated from other applications). This could be things like:
- Collective budgetting of collective funds
- Decision making and visualization of dimensions of health of the collective (available cash on hand, inventory levels, feedback from suppliers etc.)
The producer module would include features that suppliers to the food club need in order to make their products available in the system. These include:
- Product information (text, images, video)
- Quantities/Inventory, how much of each product is available to clubs, have been delivered etc.
- Story telling, a space for producers to present how they operate, their values etc.
In the module diagram above, there are also things in this module which would enable the producer to do things like host their own independent online shop or simply to present their goods instead of having a seperate homepage. Modules are preferrably co-developed with other applications in the same sphere so that they can be used in many contexts (like ProducersToken)
Basically a self-checkout system like the ones that can be found in regular grocery stores but instead of paying with credit cards, you would autheniticate your food withdrawl over wifi/cellular with phone or using a USB thumb drive with a key on it.
This module would need to be able to integrate things like a bar-code scanner and electronic scales as well as a touch screen interface.
This would enable non-smartphone users to use the systems by simply having a USB thumb drive along with their key to the building. Something that would make implementation more laggard friendly. Some users of the buyers clubs we would not want to shift from a fully paper based system. If a human could take that paper enter it in to the system and simply help users sign the withdrawls this would make it even simpler to implement the system.
It would also be good to enable direct payment - credit systems that could connect a credit-card terminal as mode of deposit.
This module would be a specialized version of the member module that is specifically designed for restaurant/cafe type organisations. It would fokus on minimizing food waste and getting time-critical foods to the organisation. Being able to tag things that are soon to expire or currently exist in a glut so that restaurants would be able to effectively act as an outlet for these products would be a way to make sure that the full inventory keeps circulating properly.
Logistics (imported module)
While orders of food between buyers clubs might be handled in other modules, there would also be a strong need for integrating software that routes whomever is going to actually transport the food around. Whether it is done by some member of the club doing voluntary work, a person hired by the network for that service or an external logistics service.
This is such a ubiquitous need that it feels like an external project that will be solved by someone else entirely, or if not should be seperated out and persued as a project in itself.
REA (imported module)
The functioning of REA accounting is also something that is being developed by others that could hopefully be imported into Shiro, or adapted to suit Shiros purposes and is not going to need to be developed internally.
This is a large endevour that has a lot of different areas that can be developed and can work together help enable a shift of the food system.
Design module breakdown to enable Minimal Viable Products, and phase-based implementation. Hopefully this could be a great collaborative effort by a lot of people and we have lots of overlap with other projects so we should be able to collaborate on a lot of this. In any case, this is probably a good order to go about thinking of the module development.
Some basic module dev. progression:
- Inventory Module
- Producer Module
- Member Module
- Point of Sale Module
- Restaurant Module
We’ve started something, built in Rust! this is meant to be a prototype to start thinking about how the inventory module might work…
Roles is buyers club
- Supplier relations and purchasing
- Accounting and payments
- Reception of goods
- Unpacking and shelving
- Internal communication
- Location mantenance and cleaning
Lets look at a few examples of buyers clubs / food co-ops that guide our needs elicitation.
This buyers club started around 20 years ago. A rural and cultrurally rich community wanted access to Organic food which at the time was very hard to find. The community was located in an area that was also did not have enough people to support a general grocery store as they are normally operated.
An association was formed that started to find international, national and regional retailers that would be able to supply the members of the association with the products they wanted.
Products are purchased in retail size quantities (sacks and larger boxes) and are then unpacked and shelved by members of the co-op. One side-benefit of this mode of operation was the ability to massivly reduce the packaging of goods as most dry goods can be handled with members reusable containers.