[2021 Theme Proposal] Local First Development for True Data Agency
autonome opened this issue · comments
Note, this is part of the 2021 IPFS project planning process - feel free to add other potential 2021 themes for the IPFS project by opening a new issue or discuss this proposed theme in the comments, especially other example workstreams that could fit under this theme for 2021. Please also review others’ proposed themes and leave feedback here!
Theme description
The objective of this theme for IPFS in 2021 is to prove out the development pathway for local-first application patterns using IPFS and the Interplanetary Stack in order to make content addressed data and peer-to-peer network architectures the first choice for modern developers, and to provide apps and services to end users which give them long-lived functional applications in which they decide what happens to their data.
Currently IPFS stands alone - a low level black box which developers do not understand and have difficulty integrating into their existing applications... if they even know where to start. Making local-first development patterns a first-class goal of the IPFS project for a year would orient the team strongly around developer needs, and result in a clear developer pathway that results in applications that truly give users control over their data.
Hypothesis
The hypothesis of this theme is that an overarching focus for a period of time on a single developer pattern will unblock longstanding challenges to adoption of IPFS: high cognitive barrier to entry due to paradigm mismatch, a focus on protocol architecture over developer and end-user patterns, lack of developer debugging tools, and lack of integration into existing popular developer tools.
Vision statement
Instead of a stack that's a toolbox that can do anything but no one thing clearly well, by the end of 2021 IPFS will make a clear statement such that developers immediately understand what it is for, the benefits and unfair advantage it provides, and how to use it. Their tools and services support it. They're able to get started quickly, the UX of the APIs and CLI are consistent and reflect this golden path, and they can use integrated debugging to get unstuck. End users get applications that still work fine when the authoring company goes out of business or is bought, their data is still local to the application usage, and they immediately feel the benefits of this architecture, and therefore prefer those applications.
Why focus this year
A continual focus on the lowest levels of the stack results in unknown and unintended consequences higher up the stack. The longer the project goes without tying itself clearly to some kind of application model, the longer it'll linger in ambiguity - and the sooner it will hit a ceiling of adoption, or be leapfrogged by something newer that speaks strongly to problems developers have today.
Example workstreams
- Identify 3-5 primary use-cases where a model of local-first development with IPFS would have significant impact on end user needs, via research and product strategy development
- Spend THE WHOLE YEAR building each use-case with teams composed of PL staff, subject matter experts, devshops and interested community who are engaging stakeholders and experts in the relevant industry or target user base, embedding in their communities, and testing with real users
- Fold the learnings from each team back into the protocol on an ongoing basis with a specification panel that evaluates and integrates the changes
- The use-case implementations each serve as examples for other developers to use as a jumping off point for their own apps and services, and the patterns and workflows developed during that time are documented and shared
- As development of the use-cases goes on, identify workflow friction, blockers and papercuts that are fixed as part of each team's development process, yielding a praxis of protocol and developer workflow at the end of the year
I definitely see a huge potential with this line of thinking. The lack of understand for IPFS represented by it's set of tools relative to general application developers is stalling wider adoption for general apps.
Currently IPFS stands alone - a low level black box which developers do not understand and have difficulty integrating into their existing applications... if they even know where to start.
I agree. IPFS main mission is a protocol layer tooling. And I think it's moving in all the right directions. The role it plays in a modern app stack is too low for the general application developer's mind models.
However, I think what is proposed is better suited for higher level solutions. Orbitdb is like the archetype for the proposed use case just at a level higher in the stack. They still have several important kinks to work through before it could be fully ready for production solutions but the main paradigm lives above IPFS. Only a general understanding of IPFS is necessary with a focus on app layer API. More support in this area of solutions would help adoption of IPFS overall.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.