Following a discussion with @sylvain, who shared with @Selmo and I his vision on what he believes the future of the web to be “distributed web”
The limits of the actual OFN system in the future of the web
Today, OFN is basically a software editor: we produce a software infrastructure that any food hub can use.
The problem is that as we want to build a global system which is at the same time resilient and collaborative, we need to find the balance between what we do together (e.g. the code) and what we do separately (e.g. build our own local instance with its own governance).
That also brings some problems on a global vision: the instances can’t really communicate with each other, so if I buy from a producer abroad, I can’t communicate with the local instance of the supplier, and this supplier has to put his data on both local instances. More broadly, as the code is open source, if in my local region another instance starts, the local suppliers have to put their data in both instances.
Today to ensure the resilience we need to create local instances, but it makes it harder to start using the platform in a country where OFN is not yet.
That may not be needed anymore in a distributed web vision, which is becoming a reality. Tadaaaaaa!
##What is distributed web / web 3.0?
Here is a small visual explanation by @sylvain about what the “distributed web” is
"https://docs.google.com/document/d/1BRln-ZmOLaOLmvvBJyWVxYZkHSJ8mb6y0be4ukh4bkQ/edit?usp=sharing
Basically the idea is that all that we develop in the OFN software, using Ruby, etc, won’t be needed anymore as each person will store its own data and share them globally.
The idea of distributed web is that we separate the data and the applications using them.
Each producer, all over the world, can say what they have for sale and when, and this data can be displayed by any application that the producer has authorized.
##What does it mean for OFN in the future?
Applied to OFN, that would mean that each hub would have its own OFN application, totally customized (white labeled, with the design they want, specific features,etc.). Of course OFN can offer to store the data on a server and develop a user friendly interface for the farmers to fill in their data. But each hub will have its own version of OFN, and the “request” will be directly displayed in the browser of the user by a universal API.
A very practical example: François sets up a hub in a French village right on the border between France and Spain in the Pyrenees. He knows farmers and potential consumers in villages on the Spanish side, where there is also a hub a few kms away. CURRENTLY the producers and consumers would have to be signed in to both the French and Spanish instances to shop in / sell to both hubs. IN A DISTRIBUTED WEB VERSION, they could access all hubs/farmers in the area or anywhere in the world with their app, as data and platforms would be separated.
To give another example, today you have friends on facebook, friends on google, friends on couchsurfing, and you need to use “proprietary API” to connect every silo. In the distributed web vision, the fact that you are friend with this person is disconnected from the application that uses that information, and this data can be used by all the people you want to authorize to use it.
W3C, the organization that defines the standards of web, including html/javascript/css…, has now published the standards for that distributed web to emerge, “.rdf” (the way we organize data > subject / predicate / object), “LDP” (the way to access data in the browser)…
Of course, today it’s not possible to build OFN in a distributed web as the latter is not yet fully operational. But we should have in mind this evolution of the web, as it will probably change the job of OFN in the coming years. We could possibly be customizing an OFN application for each hub. And OFN could be a hub directory, and offer some other marketing services and logistic cooperation tools. Supporting the hubs’ emergence, organization and cooperation is something that would still be needed, because we need to gather volumes to transport food in an efficient way.
We should probably keep that in mind in the way we envision the development of OFN, and keep an eye on the evolution of the distributed web to be ready to migrate when it’s time 
Especially when we start developing APIs (ping @lawrence), using the standards will help other people in the future 
Don’t hesitate to share your thoughts on that, react, and add your own contributions to that reflexion of the future of OFN in a distributed web environment
