The future of OFN in a distributed web environment

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 :slight_smile:
Especially when we start developing APIs (ping @lawrence), using the standards will help other people in the future :wink:

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 :slight_smile:

1 Like

Great input, we should absolutely aim towards a distributed framework.

We could try having a “parallel implementation” based on/using Apache Marmotta, an open source implementation of the LDP.

1 Like

Ping @sylvain :slight_smile: @sigmundpetersen, I actualyl wanted to connect you with Sylvain, I think you too have a lot to talk about :smile:
Does anyone know if there are funding/research opportunities to finance that “parallel implementation” in order to prepare the transition toward distributed web? As it’s new, I guess some foundations / research institutes may be interested in using OFN as a use case if we can have funds for that… I will talk about it to SINTEF, but maybe you have other ideas?

I guess SINTEF/NTNU have quite a few activities going on about web 3.0/semantic/distributed web. Maybe we could even suggest OFN as use case for Master’s work or PhD. But we should keep in mind there may be challenges in keeping the work open access. At least SINTEF I guess will want to keep their funded work proprietary.

I strongly suggest that we focus on open licensing when collaborating with research institutions.

1 Like

Indeed, Marmotta is probably a good choice, although I have been mostly playing around with RwwPlay! so far.

But I think an easier transition plan could be to implement an API on the existing OFN software, respecting the LDP spec, at least on unauthenticated features. Then it would be easy to add new all-javascript user interfaces, waiting for the right time to switch to a full LDP server.

I have been working on a LDP framework recently. It’s still very young, but one can already use it for simple stuff. I’m working on improving the documentation.

I would strongly recommend this post http://talk.growstuff.org/t/open-food-interoperability-entities-unique-ids-and-semantic-equivalence/93 by Skud who is an expert in this stuff. I doubt full RDF support or using a linked data store would make sense for OFN. Its already complex software and very transactional. What would be great is to develop the API capabilities further and include entity references to common identifiers such as Wikidata (see post).

Thank you @pmackay for that link :slight_smile: I have to admit that I didn’t understand everything… I would need a drawing to illustrate your vision @pmackay :smile: And I’m looking forward to read other feebacks on that… I feel very excited about this conversation, as it’s about our common vision of where OFN is going technically :smile:

Very nice post indeed! I think it’s definitely the way OFN should go. Any plan in that direction?

JUst a heads up - Etherium is at 98% production ready status and will probably launch within weeks. Are we connected with anyone there. Maybe they will be interested in using OFN as a POC or pilot?

I think the future of the OFN in a distributed web will soon have to been discussed more deeply…https://medium.com/@therealopenbazaar/openbazaar-2-0-p2p-trade-takes-the-next-step-4d75b7f23ec8#.1etm5keox
Logistics might be a bit more complex in delivering food, but I’m sure in this distributed web model we’ll have some algorythms that will build intelligent mutualized shipping based on Commons data!
Ping @pmackay and I’m sure @sylvain you have seen this article :slight_smile:

Thanks for the post!
OpenBazaar is an interesting initiative, but I don’t think you need to use tehchnologies as young and complex as blockchains in OFN today. The web standards of APIs are already a good move, and probably enough for what OFN needs for now. And it’s much simpler to implement, you only need to understand the standards and keep going with you json API.

As for the logistics, I’m no expert, but I have the feeling that studying UberEats would give us some clues.

Inspiring Exciting long-term big picture vision here!

One could amend that Openbazaar goes even beyond distributed. It is decentralized :wink:

(Depending on definitions) a distributed system is comprised of independent computers that have an established trust relationship with each other. Interconnecting (neighbouring) OFN instances and/or offline apps to exchange and synchronize “interoperability” does distribute economic responsibility and infrastructure costs more evenly than one big server. Distribution is definitely a direction that OFN is aiming at http://community.openfoodnetwork.org/t/connecting-food-cooperatives

Every connection in a distributed system requires permission and trust. A decentralized system otoh is permissionless and trustless, i.e. it “works” even if participants might not know each other and behave hostile. Hence there is no need to register accounts or API-keys with each other. Instead provably strong integrity guarantees are included in the data itself s.t. everyone can verify everything for themselves. No need to trust. Decentralization is not discrete but a continuum and it comes at a cost which is computational efficiency. Ideally a global web of food would be just decentralized enough for its integrity to be uncorruptable but not more.

I really like OFN as it is as it can be used right now and I see great need for it!

A giant monolythic rails app is perfect to find out what we actually need and iterate rapidly. Integrating with offline apps and foodsofts will make it more distributed gradually and long-term we can transition towards a “more” decentralized future… Money/Payments might be a good start. Including trustless (digital) money can finally enable true p2p transaction between producer and consumer while the hub does not need to be a trader in between and neither does need a money transfer business license. If there is no need to trust then no hub can (technically) steal any money. If there is no way to steal money then there is no need for a payment service provider license. So even though the logistical coordinative enabling communication done by a hub can provide a similar (if not better) experience for farmers and eaters than a traditional middleman could provide, there is technically (and legally?) no middleman. Does this reasoning make sense?

1 Like

Interesting thread!
I didnt know about openbazaar.org, really interesting and inspiring for OFN.

I just learned that JSON-LD is actually compatible with RDF. It’s an implementation of RDF. That is great because we can forget about the abstract theory of semantic web and just use JSON-LD on our API :slight_smile:
I see two dimensions to it:

  • JSON-LD to give meaning to the data - links to schemas, the @context tag for example
  • HATEOAS - basically, links between related resources
    Anyway, first, we need to clean up and define our basic REST API, then we can start to build these beautiful things on top.

Some interesting links:

1 Like