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
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…
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
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
@Leo239@orangeman thanks for this post, I do support 100% your vision and that’s what I’m working towards since 2,5 years now through Data Food Consortium. Our ambition is to build that “universal open community managed standard” to enable exchange of data in a standardized format between small modular apps. The way we build that standard also aims at supporting decentralized storage of data, but there are steps we need to go through as we need to transition a whole ecosystem from centralized silo apps to apps able to read data from a diversity of sources (which means basically rewrite all front ends and evolve server architectures towards SOLID type of servers as far as I understand, but I’m not tech so forgive me if I’m mistaken ;-))
Here is where we are at documenting the DFC standard : https://docs.google.com/document/d/1vLYI4pv-lqcy7WLoMN9XWROPh1FayXFU5g4zA5blmEQ/edit?usp=sharing
We will finish in the coming days the first version and publish it through a gitbook associated to the DataFoodConsortium repository on Github. So the idea is that anyone can suggest also modifications not only of the ontology (if they have a use case that doesn’t fit in it) but also the technical specifications like protocols, etc. We know it is not yet what we want it to be, we made some “centralized” choices but see that as a first step, we need first to be able to solve the problem of having 5 catalogs for the same producers on 5 different platforms with various ids and conflictual info, etc. We will learn as we go
We are also starting to prototype how we can connect ontologies using some “same as” and other similar logics to navigate semantically between apps seamlessly. All this is learning step by step process. I’m going to publish the DFC ontology on LOV next week.
I also would like to invite @sylvain in that conversation who is building a cooperative to organize coinvestment and codevelopment of web-components based / SOLID based interoperable small modular apps, that any agent can then aggregate like lego blocks. There might be some interesting connection between your respective work.
I hope that clarifies things. Happy to organize a call (after the 24th May as we have a global gathering starting in a week !). We will have a full day dedicated to that topic on the 15th May so we can have this conversation in mind also when we discuss @maikel@sauloperez@luisramos0@Matt-Yorkley@lin_d_hop and all
Indeed, at Startin’blox, we’re already building stuff much like what you’re talking about @Leo239 and @orangeman , except it’s based on Solid and not on Matrix. I guess what we’ve built could be of interest for you.
We don’t have much communication materials yet, but I’d be happy to have a call with you guys if you like.
for 