Apollo Takeaways: Benefits, Market Scope

Hackathons are always loaded experiences. They’re an immersion in a temporary society of gifted and capable people, all striving to implement something of value. There’s camaraderie in the game; everybody wants to see everyone succeed. People are generous with their time and eager to share knowledge.

We made some good connections in Apollo, both hackers and mentors from the infrastructure companies. The intention of the organizers is that these people will, over time, go beyond being colleagues and become friends. Thereby the community can flourish. (We plan to make that aspiration happen.)

Constructive critique was also plentiful. We put our concept on the virtual stage in mentor sessions and pitches. People ask pointed questions! Nothing malicious is intended and it prodded us to clarify our thinking.

Benefits of the ClimateDataPool Platform

Our use case is fairly focused. We have a model client in mind, the United Nations, but they already have a document storage system. As one of our mentors, Mike Goelzer from Protocol Labs, wrote:

“Does IPFS really solve this problem, vs better management of classic cloud servers?”

In discussion we came up with some crucial benefits:

• Files stored on IPFS cannot be copies so there’s no doubt about what is the original, canonical file. This is due to the file id being a hash of the asset.

• Uploaded files cannot be ‘taken down’, e.g. by a science-denying regime. Thanks to the decentralized nature of web3, files can’t be censored.

• The platform could be open, meaning that any entity can create their own ClimateDataPool.

Market Scope

One of the issues that surfaced was client focused, namely, what parties would be interested in using the data management capabilities? In the feedback Carson Farmer from Textile commented:

“This platform could be expanded beyond climate, e.g., civic data (cities use portals with SOAP or REST - everyone uses different).”

Our market focus since the beginning has been on climate data, specifically Paris Climate Accord data, which is stored at the United Nations. But realistically, we don’t expect to become a supplier to the UN. Large bureaucracies require certainty and shouldered responsibility, which is something that our little org can’t provide. As Josh Bijak, our fellow climate hacker and CTO of creol.io admonished, “You can’t point a finger at a contract”. Thus our intention has been to operate as a nudge, and coax the Climate Accord and UN to move in the web3 direction for their storage.

But many other government entities collect and publish data, and they all have certain requirements in common, some of which ClimateDataPool will fulfill. So we could take Carson’s advice and try to find smaller entities, like cites, who have similar needs. A prime example in these times is coronavirus reporting, which gets published and presumably archived using some document portal.

Given a functioning prototype we could try to find a visionary first user who would be willing – and understandingly tolerant – to participate in the ongoing development with the intention to use the platform once it’s production ready.

If we head down this path we may want to rename the product, since it wouldn’t necessarily be climate data getting stored. It could be any data. It would be open. So we could call it OpenDataPool.

Then any party could setup an OpenDataPool pod and start storing data. They would have all the functionality of the data management system at their disposal.

Next

Our next steps should be establishing contact with our users and gaining clarity on the benefits and scope.

In the course of Apollo we solved problems with the software stack which helped specify the technical approach. That will inevitably change, via new innovations in the ecosystem and evolution of thinking. If a developer comes on board that’ll add a practical dimension. So finding a technical collaborator is high on the ToDo too.