Conceptualizing a modular system of apps for organizing food hubs and other ways of connecting producers and consumers

#1

In the past few weeks, I met up with @orangeman to discuss the current situation concerning software solutions for people who want to cooperate in food hubs. To our knowledge, there is no software that includes sufficient features for storage-based hubs, especially offlineability, continuous units (like 0.832 kg), a Point Of Sale interface for entering takings out of a batch-based storage, consumption statistics etc., while also providing features for co-ordering. Both @orangeman and I worked on attempts to build software to fulfill such features a few years ago. (FoodCoApp resp. Kerndlware)

Much inspired by the discussion on interoperable modules and @MyriamBoure’s posts on Data Food Consortium, our ideas tend towards splitting the required features into a system of many small standalone apps which can communicate with each other as well as externally (with other food hub software systems, but also accounting softwares etc.) instead of one giant software monolith that always lacks at least one important feature.

Matrix protocol could be used for the apps to exchange data instead of a centralised database. To make that happen, we would need a standardised data format which works for several organizational forms all around the world. In our vision, this could evolve into an open system where anyone can contribute new apps that offer new ways of modifying the data.

Once more, step by step:

Our intent: To empower people to cooperate as food hubs (co-ops), to reduce their organizing work while extending their possibilities.

Our long-term goals:

  • To enable participants of storage-based hubs to take any amount out of bulks (with continuous units like kg which allow e.g. 1.385 kg)
  • To provide a tool for organization and participation which does not require an active internet connection while utilizing the possibilities of storing/exchanging the data on online servers
  • To split the features into a modular system of separate apps which can run independently from one another
  • To keep it open for further apps and inviting other hackers to make contributions (free software)

The consequenses we draw:

  • Dedicated features to run food hubs with a storage from which members can take goods at any time (batch-based)
  • Dedicated features for regular order cycles and irregular orders
  • Several features for organization, from membership fees to stockkeeping statistics, balance sheets and so on
  • Additional features for participation in storage-based coops, like a pick-up-planner and consumption estimation forms
  • Building all those features into a modular system of separate apps which can be installed locally on devices to enable offline use, but which can synchronize their data with the server whenever there is internet connection
  • Enabling decentralized data storage on custom servers, so there isn’t any dependence on centralized data storage
  • Using/establishing a standardised data format
    • suitable for food hubs of various different organizational forms all around the world
    • suitable for other organizational forms like farmer-to-consumer direct marketing, wholesalers, CSAs or even private households
    • which can exchange data with other softwares like OFN, or even accounting softwares etc.

We would be glad to hear what you think about this brainstorming.
Sorry for any bad grammar.
Leo

0 Likes

#2

Thank you @Leo239 for summarizing our conversations!

Offline-ability was a key issue in our foodcoop experience since the storage cellars didn’t have reliable reception. The more independent data copies exist the more likely replication conflicts arise and confidentiality becomes an issue. But requiring all apps/services to be connected becomes less feasable with a growing number of distributed parts.

We talked about kappa architecture as a way to synchronize distributed state via a consistent changelog [1] and discussed the matrix (state replication) protocol as a promising pragmatic transport. This is less about a common vocabulary (data format), but much more about a common language (protocol), ie a standard way of how to “talk” and interact. Specifically how to ensure everyone eventually arrives at the exact same shared state after network partitions. Matrix seems a good fit since it additionally brings state-of-the-art multi-party e2e encryption as a trustless way to implement privacy, access control and permissions. Users are in full control of their own (local) data and how to selectively share it in order to cooperate in coops. We also talked about value flows and datafoodconsortium as data models that seem flexible enough to encompass the multitude of cooperation patterns that the wider integrity food movement engages in.

Since interoperability, modularization and decentralization has been discussed a lot in the OFN community over the years we are curious about your thoughts.

[1] kappa - there are many other names for this old simple idea: write-ahead-log in database internals, event-sourcing in the enterprise integration world, virtual synchrony or state machine replication in academia, git branch/merge in sourcecode evolution, or dat, ssb, ipfs, blockchain in decentralization…

0 Likes

#3

related posts:
https://community.openfoodnetwork.org/t/data-food-consortium-making-food-platforms-interoperable
https://community.openfoodnetwork.org/t/the-future-of-ofn-in-a-distributed-web-environment
https://community.openfoodnetwork.org/t/integrating-ofn-with-mailchimp-the-hacky-way
https://community.openfoodnetwork.org/t/ofn-germany

0 Likes

#4

Hello @orangeman and @Leo239 it’s great to read your post!

In terms of features:

  • I think OFN supports “continuous units”
  • PWA and service workers are one way to make WEB apps offline. We are very far from this in ofn with the current rails+angular solution.
  • regarding splitting features across components - I totally agree and that’s why I believe the OFN API and breaking OFN in domains, to start with), is the way to go. I think the OFN community is well aligned about the importance of the OFN API
  • free software :sunny:

In terms of architecture,

  • kappa seems related to the popular event sourcing (I believe it is used internally in openolitor), I love this talk about it.
  • I dont see why the Matrix protocol is necessary here.
  • I advocate for simplicity, specially in these small scale systems. So my favorite architecture is REST :heart:

Keep it going!

0 Likes