├── .github ├── ISSUE_TEMPLATE │ └── config.yml ├── config.yml ├── old-issue-templates │ └── 2021-theme-proposal.md └── workflows │ ├── generated-pr.yml │ └── stale.yml ├── .gitignore ├── LICENSE ├── README.md └── archive ├── 2019 WG roadmaps ├── WG_CLUSTER.md ├── WG_COMMUNITY.md ├── WG_DECENTRALIZED_DATA_STEWARDSHIP.md ├── WG_DYNAMIC_DATA_AND_CAPABILITIES.md ├── WG_GO_CORE.md ├── WG_GUI.md ├── WG_INFRASTRUCTURE.md ├── WG_INTEGRATION_IN_WEB_BROWSERS.md ├── WG_JS_CORE.md └── WG_PROJECT.md ├── 2019-IPFS-Project-Roadmap.md ├── 2020-IPFS-Project-Planning.md └── 2021-IPFS-Project-Planning.md /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: true 2 | contact_links: 3 | - name: Getting Help on IPFS 4 | url: https://ipfs.io/help 5 | about: All information about how and where to get help on IPFS. 6 | - name: IPFS Official Forum 7 | url: https://discuss.ipfs.io 8 | about: Please post general questions, support requests, and discussions here. 9 | -------------------------------------------------------------------------------- /.github/config.yml: -------------------------------------------------------------------------------- 1 | # Configuration for welcome - https://github.com/behaviorbot/welcome 2 | 3 | # Configuration for new-issue-welcome - https://github.com/behaviorbot/new-issue-welcome 4 | # Comment to be posted to on first time issues 5 | newIssueWelcomeComment: > 6 | Thank you for submitting your first issue to this repository! A maintainer 7 | will be here shortly to triage and review. 8 | 9 | In the meantime, please double-check that you have provided all the 10 | necessary information to make this process easy! Any information that can 11 | help save additional round trips is useful! We currently aim to give 12 | initial feedback within **two business days**. If this does not happen, feel 13 | free to leave a comment. 14 | 15 | Please keep an eye on how this issue will be labeled, as labels give an 16 | overview of priorities, assignments and additional actions requested by the 17 | maintainers: 18 | 19 | - "Priority" labels will show how urgent this is for the team. 20 | - "Status" labels will show if this is ready to be worked on, blocked, or in progress. 21 | - "Need" labels will indicate if additional input or analysis is required. 22 | 23 | Finally, remember to use https://discuss.ipfs.io if you just need general 24 | support. 25 | 26 | # Configuration for new-pr-welcome - https://github.com/behaviorbot/new-pr-welcome 27 | # Comment to be posted to on PRs from first time contributors in your repository 28 | newPRWelcomeComment: > 29 | Thank you for submitting this PR! 30 | 31 | A maintainer will be here shortly to review it. 32 | 33 | We are super grateful, but we are also overloaded! Help us by making sure 34 | that: 35 | 36 | * The context for this PR is clear, with relevant discussion, decisions 37 | and stakeholders linked/mentioned. 38 | 39 | * Your contribution itself is clear (code comments, self-review for the 40 | rest) and in its best form. Follow the [code contribution 41 | guidelines](https://github.com/ipfs/community/blob/master/CONTRIBUTING.md#code-contribution-guidelines) 42 | if they apply. 43 | 44 | Getting other community members to do a review would be great help too on 45 | complex PRs (you can ask in the chats/forums). If you are unsure about 46 | something, just leave us a comment. 47 | 48 | Next steps: 49 | 50 | * A maintainer will triage and assign priority to this PR, commenting on 51 | any missing things and potentially assigning a reviewer for high 52 | priority items. 53 | 54 | * The PR gets reviews, discussed and approvals as needed. 55 | 56 | * The PR is merged by maintainers when it has been approved and comments addressed. 57 | 58 | We currently aim to provide initial feedback/triaging within **two business 59 | days**. Please keep an eye on any labelling actions, as these will indicate 60 | priorities and status of your contribution. 61 | 62 | We are very grateful for your contribution! 63 | 64 | 65 | # Configuration for first-pr-merge - https://github.com/behaviorbot/first-pr-merge 66 | # Comment to be posted to on pull requests merged by a first time user 67 | # Currently disabled 68 | #firstPRMergeComment: "" 69 | -------------------------------------------------------------------------------- /.github/old-issue-templates/2021-theme-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: 2021 Theme Proposal 3 | about: Suggest a 2021 focus area for the IPFS Project 4 | title: "[2021 Theme Proposal] Theme Title" 5 | labels: 2021 Theme Proposal 6 | assignees: atopal, dchoi27 7 | --- 8 | _Note, this is part of the [2021 IPFS project planning process ](https://github.com/ipfs/roadmap/blob/master/2021-IPFS-Project-Planning.md) - feel free to add other potential 2021 themes for the IPFS project by opening a [new issue](https://github.com/ipfs/roadmap/issues/new/choose) 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](https://github.com/ipfs/roadmap/labels/2021%20Theme%20Proposal)!_ 9 | ## Theme description 10 | _Please describe the objective of your proposed theme, what problem it solves, and what executing on it would mean for the IPFS Project._ 11 | 12 | ## Hypothesis 13 | _Please describe the core hypotheses that you would need to believe for this theme to make sense as a 2021 IPFS project theme._ 14 | 15 | ## Vision statement 16 | _Please describe what the state of the IPFS project would look like if execution of this theme is massively successful._ 17 | 18 | ## Why focus this year 19 | _Please discuss why 2021 is the right year for this theme._ 20 | 21 | ## Example workstreams 22 | _Please list relevant workstreams, development milestones, and a high-level timeline for these efforts._ 23 | 24 | ## Other content 25 | _Please include links to other relevant content, notes, etc._ 26 | -------------------------------------------------------------------------------- /.github/workflows/generated-pr.yml: -------------------------------------------------------------------------------- 1 | name: Close Generated PRs 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * *' 6 | workflow_dispatch: 7 | 8 | permissions: 9 | issues: write 10 | pull-requests: write 11 | 12 | jobs: 13 | stale: 14 | uses: ipdxco/unified-github-workflows/.github/workflows/reusable-generated-pr.yml@v1 15 | -------------------------------------------------------------------------------- /.github/workflows/stale.yml: -------------------------------------------------------------------------------- 1 | name: Close Stale Issues 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * *' 6 | workflow_dispatch: 7 | 8 | permissions: 9 | issues: write 10 | pull-requests: write 11 | 12 | jobs: 13 | stale: 14 | uses: ipdxco/unified-github-workflows/.github/workflows/reusable-stale-issue.yml@v1 15 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | 8 | # Runtime data 9 | pids 10 | *.pid 11 | *.seed 12 | *.pid.lock 13 | 14 | # Directory for instrumented libs generated by jscoverage/JSCover 15 | lib-cov 16 | 17 | # Coverage directory used by tools like istanbul 18 | coverage 19 | 20 | # nyc test coverage 21 | .nyc_output 22 | 23 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 24 | .grunt 25 | 26 | # Bower dependency directory (https://bower.io/) 27 | bower_components 28 | 29 | # node-waf configuration 30 | .lock-wscript 31 | 32 | # Compiled binary addons (https://nodejs.org/api/addons.html) 33 | build/Release 34 | 35 | # Dependency directories 36 | node_modules/ 37 | jspm_packages/ 38 | 39 | # TypeScript v1 declaration files 40 | typings/ 41 | 42 | # Optional npm cache directory 43 | .npm 44 | 45 | # Optional eslint cache 46 | .eslintcache 47 | 48 | # Optional REPL history 49 | .node_repl_history 50 | 51 | # Output of 'npm pack' 52 | *.tgz 53 | 54 | # Yarn Integrity file 55 | .yarn-integrity 56 | 57 | # dotenv environment variables file 58 | .env 59 | 60 | # next.js build output 61 | .next 62 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018 IPFS 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IPFS Project Roadmap 2 | 3 | As a community-driven project, IPFS does not have a single roadmap. As of 2023, there are multiple companies and teams building IPFS implementations. 4 | 5 | To encourage both innovation and interoperability, the IPFS community focuses on [**specs and standards**](https://specs.ipfs.tech/) and uses the [IPIP process](https://specs.ipfs.tech/meta/ipip-process/) as a Lightweight Improvement Process for IPFS Specifications. 6 | 7 | To learn more about the directions IPFS see: 8 | - [**IPFS Implementations**](https://docs.ipfs.tech/concepts/ipfs-implementations/) 9 | - [**IPFS Specs**](https://specs.ipfs.tech/) 10 | - [**IPFS Principles**](https://specs.ipfs.tech/architecture/principles/) 11 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_CLUSTER.md: -------------------------------------------------------------------------------- 1 | # IPFS Cluster Working Group 2019 Roadmap 2 | 3 | The IPFS Cluster WG implements the IPFS Cluster product. IPFS Cluster facilitates the orchestration of multiple IPFS daemons, as well as collaboration maintaining IPFS pinsets and datasets. 4 | 5 | **Current Projects:** 6 | - IPFS Cluster 7 | - Pinbots 8 | - Cluster infra 9 | - Support decentralized data stewardship 10 | - IPFS Storage for partners 11 | 12 | ## 🚀 Major 2019 goals to achieve 13 | 14 | - IPFS Cluster facilitates the ingestion and replication of package repositories to IPFS 15 | - IPFS Cluster is the goto team for experience and expertise handling large files 16 | - IPFS Cluster facilitates distribution of content large IPFS datastores among different organizations and users 17 | - IPFS Cluster enables the creation of collaborative IPFS content networks 18 | - Cluster provides managed IPFS storage for select partners that need them 19 | - IPFS Cluster takes a key role in the IPFS Conf 20 | 21 | ## 💎 Milestones 22 | 23 | ### Package Managers 24 | 25 | - `M (P0)`: IPFS Cluster can be used to shard large repositories among multiple IPFS daemons 26 | - Go-ipfs supports pinning strategies 27 | - IPFS Cluster supports sharding https://github.com/ipfs/ipfs-cluster/issues/496 28 | - `M (P0)`: IPFS Cluster understands the requirements for package managers infrastructure and can become an useful layer on top of IPFS 29 | - Attend the reproducible builds summits 30 | - Produce a document that show how exactly IPFS cluster can help ipfs-based package managers 31 | - Scaling and federation 32 | - Spec out enterprise support requirements 33 | - `M (P1)`: IPFS Cluster is used to manage at least one package repository of some kind 34 | - Collaborative clusters need to be ready possibly (depends on previous) 35 | - Redirect registry.js.ipfs.io to use IPFS Cluster rather than just one IPFS node 36 | 37 | ### Large Files 38 | 39 | - `M (P1)`: IPFS Cluster team is a key participant for data-together efforts creating and storing archives 40 | - We need to start joining their meetings 41 | - Support any actual efforts with our tech 42 | - `M (P0)`: At least two organizations run a “federated” IPFS Cluster 43 | - Federated clusters is a defined usecase 44 | - We have figured out how to do this 45 | - Permissions in endpoints 46 | - Cluster API IPFS Connector 47 | Advanced allocators, priority allocators, compositionable allocators 48 | 49 | ### Decentralized Web 50 | 51 | - `M (P0)`: We run some topic networks like “cat pictures” or “tweets” and > 10 followers help pinning content for them 52 | - “Collaborative pinsets” (crdt+pubsub+trusted pinners) works 53 | - Super easy initialization of cluster configuration for this 54 | - We have an official website for this 55 | 56 | ### Support User 57 | 58 | - `M (P1)`: Cluster provides managed IPFS storage for select partners that need them and this takes less than 2h time to 1 engineer. 59 | - We can setup new clusters on AWS very easily 60 | - AWS deployment and docs 61 | - We know how much it costs to do this 62 | - We have a document outlining which partners are the best fit to do this 63 | 64 | ### Strategic Projects 65 | 66 | - `M (P1)`: We run at least four talks at IPFS Conf: IPFS Cluster 101, IPFS Cluster to back up your personal content, Federating IPFS Clouds with IPFS Cluster, IPFS Cluster for cloud administrators, IPFS Internals 67 | - Create all these talks 68 | - Make sure we participate in IPFS Conf preparation and push the project to be prominent 69 | - `M (P0)`: We need to have figured out very clear product description of Cluster and cover all the features they need 70 | - Collaborative pinsets 71 | - Federation 72 | 73 | ## Timeline 74 | 75 | - Q1 76 | - Q2 77 | - Q3 78 | - Q4 79 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_COMMUNITY.md: -------------------------------------------------------------------------------- 1 | # [The IPFS Community WG Roadmap is in the `community` repo.](https://github.com/ipfs/community/blob/master/ROADMAP.md) 2 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_DECENTRALIZED_DATA_STEWARDSHIP.md: -------------------------------------------------------------------------------- 1 | # Decentralized Data Stewardship Working Group 2019 Roadmap 2 | 3 | #### _TODO: Descoping to focus on 📦 Package Managers as main 2019 Priority_ 4 | 5 | ## 🚀 Major 2019 Goals 6 | 7 | The DDS WG is proposing to own the discovery, design, and development of Cube, a product that helps people own and manage their own pinning service (see draft proposal here). If we get a team to do this, it will allow us deliver a number of the declared 2019 IPFS priorities in ways that are driven by proper user-driven design and well-planned engineering efforts. This is the primary contribution that we would like to make for the benefit of the entire IPFS Project. Meanwhile, we’re going to spin up the Preserving the Public Records events, maintain our partnerships, and help spin up a design team. 8 | 9 | - 🗂 🔄 Product: Cube. Create a product that makes it easy for people to run their own pinning service and manage it. We will do this by creating agile teams around one or several products that iteratively solve complete, basic service journeys for managing large volumes of data on the distributed web. Collaborate closely with IPFS Cluster and Filecoin teams (see also IPFS Cluster and IPFS GUI). Relevant to the Large files and Decentralized Web 2019 IPFS Priorities. 10 | - 🔄 Events: Preserving the Public Record. launch a series of grassroots events around the world focused on addressing questions of what it means to create and preserve a public record. Relevant to the Decentralized Web 2019 IPFS Priority. 11 | - 🤝 Partnerships: Data Together. Build on existing work and open new collaborations to broaden the coalition of institutions, companies, and people who are using DDS tools to solve real problems in the world. We intend to especially focus on GLAM institutions and global-scope organizations with social benefit missions. Relevant to the Partner Use Cases 2019 IPFS Priority. 12 | 13 | ## 💎 Milestones 14 | 15 | We are using an agile approach, so we’re not putting these in a waterfall-style Gantt chart of milestones. Instead, we’re listing them in order of operations for each objective. 16 | 17 | ### Cube 18 | 19 | - `M (PX)`: Complete Cube Discovery Process: (6-8 weeks from Cube team formation) User discovery in the product space with a team of 2 or 3. This will result in clear scope and illustrated user journeys for a product that helps people run and manage their own pinning service. Techniques might include: 20 | - Desktop research 21 | - User interviews 22 | - Competitive analysis 23 | - Workshops 24 | - `M (PX)`: Complete Cube MVP Design and Build: (3 months from end of Cube Discovery phase) Prototype one complete piece of a user journey with a team of 3 or 4. We will choose to build the piece that will let us learn the most and test our riskiest product assumptions with target audiences. Techniques might include: 25 | - Paper prototypes 26 | - Click-thru prototypes 27 | - Full-build prototypes 28 | - Demos every six weeks 29 | Sprint-based build cycles, each with usability testing 30 | - `M (PX)`: Complete Cube Public Beta Design and Build: (3 months from end of Cube MVP phase) We will continue iterating through a public beta, with the goal of a launch at the end of this phase. Techniques might include: 31 | - Full-build prototypes 32 | - Continuing sprint-based build cycles, each with usability testing 33 | - Demos every six weeks 34 | 35 | ### Preserving the Public Record 36 | 37 | These Milestones are prefaced on the expectation that we will succeed at forming a team to lead the grassroots events. Once that team has formed, they will set their exact timeline of milestones. (Note: If this team doesn’t form, we can still work with PL Events team to run the High-Profile Event) 38 | 39 | - `M (PX)`:(Q1) Form Team to Convene and Lead the Preserving the Public Record events 40 | - `M (PX)`: Announce the Preserving the Public Record Project 41 | - Publish Manifesto 42 | - Call for Participation, Identify Participating Groups 43 | - `M (PX)`: Convene the first set of Parallel Preserving the Public Record Grassroots Events 44 | - Focus: What is the Public Record? Whose Public Record? What are the threats to its preservation? 45 | - Produce Facilitators Materials for first events 46 | - Lock in venues for all participating locations 47 | - Arrange for info capture and distribution across participating locations 48 | - Event signup sites go live 49 | - Publicize the events 50 | - Run the events 51 | - Publish outputs 52 | - `M (PX)`: Convene the second set of Parallel Preserving the Public Record Grassroots Events 53 | - Focus: Designing for ongoing participatory process of preserving the public record, nominating topics and key participants for high-profile event 54 | - `M (PX)`: (Q4 or early 2020) Host High-Profile Event: Preserving the Public Record 55 | - Focus on Increasing Awareness and Spurring new Participation by Depicting the Ongoing Conversation, Debate and Design Process 56 | - High Production Quality, Emphasize capturing and disseminating high-quality A/V content, with polished presentations and group discussions 57 | - Begin designing the next round of events (Stewarding the Public Record) 58 | 59 | ### Partnerships 60 | 61 | We don’t have specific milestones for any of our existing DDS partnerships. Milestones will arise as those partnerships evolve throughout 2019. 62 | 63 | In support of Large Files 2019 Priority, we are able to arrange collaboration with existing partners to outline the use cases for transferring, replicating, signing and validating large files (ie. raw video) and start design/development process for building tools to support it, 64 | 65 | Examples of other milestones we expect to happen for DDS Partnerships in 2019: 66 | - Load Partner data into the Underlay 67 | - Get Partner data loaded onto IPFS Infrastructure and supported well 68 | 69 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_DYNAMIC_DATA_AND_CAPABILITIES.md: -------------------------------------------------------------------------------- 1 | # Dynamic Data & Capabilities Working Group Roadmap for 2019 2 | 3 | #### _TODO: Descoping to focus on 📦 Package Managers as main 2019 Priority_ 4 | 5 | > Construct the building blocks that enable developers to create DApps on top of IPFS and libp2p. 6 | > More precisely: 7 | > Research and development of building blocks that enable collaborative applications, providing solutions for security, identity, access control, concurrency, synchronization, version control, offline and near-real-time collaboration that can be integrated into IPFS. The Working Group also creates proof of concept applications and works with projects looking to create and maintain production quality dynamic applications built on top of IPFS and libp2p. 8 | 9 | **Responsibilities** 10 | - Research solutions for decentralised applications that require security, identity, access control, concurrency, synchronization, offline and near-real-time collaborations. 11 | - Deliver and support a set of building blocks and frameworks that allow the construction of world-class DApps on top of IPFS and libp2p. 12 | - Ensure that, over time, IPFS core develops new features that support dynamic data. 13 | 14 | ## 🚀 2019 Major goals 15 | 16 | - Improve DX: Create the DApp Toolkit that will allow developers to easily create web DApps that have the capabilities usually provided by generic Web 2.0 dev toolkits. 17 | - Improve UX: Improve User Experience for DApps built on top of IPFS / libp2p. 18 | - End-goal: Increase developer adoption: enable the top 3 Productivity Apps to exist and be used on the DWeb. 19 | 20 | ## 💎 Milestones 21 | 22 | All these milestones are related to the “Decentralised Web” Top Level Priority for 2019 as defined in this document. 23 | 24 | ### 1. DX 25 | 26 | #### 1.1. (DX) Peer-base interfaces and types are well defined, documented, tested and implemented (P0): 27 | 28 | * **Membership**: for a given collaboration, replicate member peers (their addresses, identities and more) to other members 29 | * **Gossip**: allow peers in an application or collaboration to share a secure channel for sharing data about each other 30 | * **Identity**: allow peers to identify themselves before others and offer ways for peers to verify that identity 31 | * **Collaboration**: allow peers to form groups that will collaborate on a given task 32 | * **Persistence**: 33 | * Local persistence (allow data to be persisted locally) 34 | * Remote persistence 35 | * Collaborative pinning (allow data to be persisted remotely without any centralised service) 36 | * Pinning service (allow data to be persisted remotely through a specific service) 37 | * **Access Control**: based on identity, and for a given collaboration, allow peers to define which sets of operations they're going to accept 38 | * **Remote Presence**: allow collaborating peers to be informed about each others' presence and actions 39 | * **Authentication**: allow a peer to authenticate a given piece of data 40 | * **Identity-based P2P secret sharing**: allow a peer to share a secret that will be authenticated and secret 41 | * **Personal** **feeds**: allow any peer to expose a set of activity feeds to any permissioned peer 42 | * **Causal broadcast channel**: create a group messaging channel that respects causality 43 | * **Collaborative replication**: multi-writer-enabled data types 44 | * Op-based CRDTs (Conflict-free replicated data types that are based on a growing set of operations) 45 | * Delta state-based CRDTs Conflict-free replicated data types that are based on transmitting deltas or entire states) 46 | 47 | #### 1.2. (DX) Peer-base release management is well defined and optimal (P0) 48 | 49 | * Change logs 50 | * Support migrations for breaking changes 51 | * Long-lived schema management 52 | 53 | #### 1.3. (DX) A methodology for supporting peer-base libraries is defined and implemented (P0) 54 | 55 | (look at other OSS projects like IPFS, Node.js) 56 | 57 | #### 1.4. (DX) Developers building dynamic DApps on top of IPFS / libp2p are supported (P1) 58 | 59 | Identify package maintainers and their responsibilities. 60 | 61 | #### 1.5. (DX) Public runtime infrastructure (run by PL) exists and is stable (P1) 62 | 63 | Services: 64 | * Pinners 65 | * Gateways 66 | * Websocket-star 67 | * Replace websocket-star with: 68 | * Rendez-vous nodes 69 | * Circuit-relay nodes 70 | * Explore: 71 | * Signaling (for signal persistence and execution (support for offline delivery, push messages, etc.)) 72 | 73 | Notes: 74 | * Make sure we outsource it to the infra team. 75 | * Define QoS contract. 76 | * Gather data about infrastructure usage. 77 | * Private infrastructure: maybe start conversation about enabling this (talk about features, economics, …). 78 | * (Talk to partners, like Textile, about needs, scaling, volunteering, ...) 79 | 80 | #### 1.6. (DX) Deployment tools, code, instructions and images exist, and are supported (P2) 81 | 82 | For deploying apps and all the required services. 83 | 84 | Notes: 85 | * (Requires cooperation with IPFS core, infra, …?) 86 | * Define which tools should exist 87 | * Assess which tools exist, who maintains them 88 | * Idea: piggyback on IPFS desktop? 89 | * Idea: support infrastructure donation? 90 | 91 | #### 1.7. (DX) peer-base v1 has been released (P3) 92 | 93 | Depends on M1.1. 94 | Signifies stability to developers. 95 | 96 | What does it contain, look like? 97 | 98 | #### 1.8. (DX) Online Materials (text mainly, perhaps video) exist and are supported (P3) 99 | 100 | * Logo and Website 101 | * Text tutorials first (easier to maintain) 102 | * Beginner 103 | * Intermediate 104 | * Advanced 105 | * Video perhaps, but only for events 106 | 107 | #### 1.9. (DX) The working group has partnered with a third party on development of a production-quality collaborative application (P1) 108 | 109 | #### 1.10. (DX) peer-base interfaces and types are formally defined (language agnostic) (P4) 110 | 111 | Notes: 112 | * Discuss this with libp2p and IPFS teams. 113 | * Check out WebIDL. 114 | * Try to make this more iterative (not waterfall) as peer-base stabilizes so that we can start implementing some of these components in other languages / platforms. 115 | 116 | #### 1.11. (DX) Identity Manager PoC v0.1 is released and is easy to integrate into an existing web DApp (well tested and documented) (P4) 117 | 118 | 119 | #### 1.12. (DX/UX) Chart a collection of UX patterns for DApps (P4) 120 | 121 | Notes: 122 | 123 | * Also depends on developers and users to gain literacy about the decentralised concepts 124 | 125 | #### 1.13. (DX) Research and document tooling to help with e2e testing for DApps (P3) 126 | 127 | ### 2. UX 128 | 129 | #### 2.1. (UX) An evolving spec for human-friendly way to identify users in DApps was debated and approved - IDM Spec v0.1 (P1) 130 | 131 | IDM = Identity Manager 132 | 133 | #### 2.2. (UX) A PoC reference implementation for the IDM Spec exists (P2) 134 | 135 | Note: (Consider also having a milestone for releasing an IDM MVP). 136 | 137 | #### 2.3. (UX) Can replicate app/domain storage using Identity 138 | 139 | (Depends on M2.1) 140 | 141 | * It's expected that the same user uses the same DApps on different devices. Research and implement a way for application data produced by the same identity (user) to be synced among devices. 142 | * It should support multi-writer scenarios 143 | 144 | #### 2.4. (UX) It is possible to build web DApps based on peer-base with good performance attributes (P0) 145 | 146 | #### Performance 147 | 148 | * Reduce the number of IPFS nodes when running multiple DApps 149 | * Prevent main thread blocking when: 150 | * Doing crypto stuff, perhaps offload to web workers 151 | * Accessing IndexedDB 152 | * Explore: using WebRTC as an alternative web sockets? 153 | * Replace WS-Star with: 154 | * Rendez-vous 155 | * Circuit-relay 156 | * Suggestion: Support Companion and libdweb (libp2p p2p streams over WS + feed of discovery events, exposed by IPFS daemon) 157 | * **Required: Measure** (automated) and iterate 158 | 159 | #### Reliability 160 | 161 | * Solve concurrency problems when two tabs use the same IPFS node 162 | 163 | ### 3. DApps 164 | 165 | ### 3.1 166 | 167 | #### 3.1.1 (DApps) - PeerPad used as the primary note taking tool inside PL (not be at feature parity with Cryptpad but "good enough", internal users do not rebel) (P1) 168 | 169 | #### 3.1.2 (DApps) - PeerPad has comprehensive E2E/load tests (P2) 170 | 171 | * PP tests use common PL testbed (being developed currently by libp2p team) // _cross-team dependency_ 172 | * range of scenarios tested (single player, normal WG scale, single bad actor, overwhelming load that shows degenerate behavior, etc) 173 | 174 | #### 3.1.3 (DApps/UX) - PeerPad feature requirements established based on best industry examples (P2) 175 | 176 | * cryptpad 177 | * other \*-pad products: hackmd, dillinger, etherpad, etc 178 | * single player: gist 179 | * (bonus) richer editors: dbx paper 180 | 181 | #### 3.1.4 (DApps/UX) - Some PeerPad user testing completed (P3) 182 | 183 | * dogfooding 184 | 185 | #### 3.1.5 (DApps/DX) - PeerPad useful as teaching tool (P2) 186 | 187 | * "Make your own PeerPad (Nano)" tutorial, text + video at 1.0 188 | * event workshop 189 | 190 | #### 3.1.6 (DApps/UX) - UX improved (P3) 191 | 192 | * dead feature cleanup 193 | * polished desktop experience 194 | * adequate mobile experience 195 | 196 | #### 3.1.7 (DApps/UX) - True PeerPad 1.0 release (P1) _// depends on 3.1.4, 3.1.5, 3.1.6_ 197 | 198 | * matches requirements gathered in 3.1.3 199 | 200 | #### 3.1.8 PeerPad Core usable as whitelabeled editor backend (P1) 201 | 202 | * can build CryptPad, HackMD, etc on top of peerpad core 203 | 204 | #### 3.2. (DApps) Launch Discussify v1.0 (P1) 205 | 206 | (Depends on M2.1, 2.2, 2.3) 207 | 208 | * Basic features implemented on the extension 209 | * View discussions on any URI in a truly p2p fashion 210 | * Synchronize comments from other users, in near real-time fashion 211 | * Ability to create, edit, remove comments 212 | * Ability to reply to comments 213 | * Ability to view comment history such as edits and removals 214 | * Guarantee the persistency of the data by integrating the pinner 215 | * Have Identity & Authentication by integrating IDM 216 | * Make it cryptographically secure by signing and checking signatures of comments 217 | * Ability to verify user's identities, including their claims & proofs 218 | * Ability to view discussions I have participated in the past, including receiving notifications about new activity on any of them 219 | * Ability to subscribe/mute discussions 220 | * Ability to discuss on specific parts of the page, using Web Annotations 221 | * Ability to invite other users to a public discussion 222 | * Ability to have private discussions with other users through invitation 223 | * Ensure that it's performant, stable and not resource hungry 224 | * Define (and execute) a plan for the launch of Discussify as a decentralized product 225 | 226 | ### 4. Staffing 227 | 228 | #### 4.1 (Staffing) - Full time PM for Peer-base ecosystem (P1) 229 | 230 | 231 | 232 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_GO_CORE.md: -------------------------------------------------------------------------------- 1 | # IPFS Go Core Dev Team - Roadmap 2019 2 | 3 | #### _TODO: Descoping to focus on 📦 Package Managers as main 2019 Priority_ 4 | 5 | The Go IPFS Working Group is responsible for the development of the Go IPFS implementation and participating in the planning and development of IPFS in general. 6 | 7 | ### Responsibilities include: 8 | * Implement new features in the Go IPFS implementation 9 | * Support Go IPFS, fixing bugs and improving stability and performance 10 | * Develop specifications for new IPFS protocols and capabilities 11 | 12 | ## Current Projects 13 | * go-ipfs 14 | * IPLD 15 | * gx 16 | * Data Exchange/Transfer - improve performance of data transfer 17 | * Data Management - improve ability of Go IPFS to manage large data sets 18 | * Provider Strategies - improve efficiency of DHT use 19 | * Commands Lib 20 | * API 21 | * Base32 CIDv1 22 | 23 | ## Major 2019 goals to achieve 24 | 1. Benchmarks for Go IPFS that measure IPFS behavior across data lifecycle for a broad set of inputs. 25 | 2. ‘Indefinite’ refactors are complete; code is maintainable and understandable 26 | 3. Improve data transfer speed so that it is at least 0.8 times that of bittorrent/rsync, (whichever is faster) for a given set of peers and data 27 | 4. Support adding/getting/pinning large volumes of data efficiently. Go-IPFS can add (and provide) 10TB of small files (< 1MB each) at > 0.5 times the speed of a simple dd] copy. 28 | 5. Make storing, looking up, and retrieving provider data in the DHT reliable and fast. 29 | 6. Complete, documented, performant, stable APIs for interacting with a running Go IPFS node. 30 | 31 | ## Milestones 32 | 33 | ### 📦 Package managers 34 | 35 | For the core implementation of IPFS to support package manager needs - go-ipfs needs to be fast, efficient and stable when handling and transferring large amounts of data. It also needs to understand and support the specific tooling and usability needs of the package manager community. 36 | 37 | NOTE: “large files” = 10GB - 1TB, “many small files” = 10K-1M 1MB files. Benchmark goals refer to the speed of transferring data when already connected to IPFS nodes that have that data (not finding the data). 38 | 39 | #### Understanding Package Manager needs 40 | * `M (P0)`: The IPFS core team understands the needs of package management communities and engages their interest 41 | * Meet people from various package management communities -- both distros and language tooling -- and learn about their needs 42 | * Support interested package manager communities with DRIs 43 | * F-droid 44 | * Guix 45 | * Snapshots.debian.org ? 46 | * `M (P0)`: We have understanding and documentation of what kind of scale (in terms of size at one time; and change in size over time) mirroring a package manager archive requires. 47 | * Ex: document how long mirroring npm into IPFS takes 48 | * Ex: VictorBjelkholm/arch-mirror also exists, let’s make sure we gather stats 49 | * `M (P1)`: Develop documentation for what Package Distribution with IPFS should look like. 50 | * There is documentation and guidelines to help maintainers from existing package management communities learn about IPFS, explore common alternatives, and figure out what would work for their system 51 | * Document and highlight best practices for dealing with the common hurdles in moving to immutable-first: e.g. “save packages in a merkle tree; build a package index merkle tree; use IPNS to handle updates of the tip of package index tree”. 52 | * `M (P1)`: There is a way to prioritize different peers to optimize network utilization 53 | * Bitswap peer prioritization supports pinning local / responsive peers 54 | 55 | #### Supporting Package Manager speed and scalability needs 56 | * Q1 - `M (P0)`: Awesome go-ipfs benchmark test suite exists comparing ipfs performance and transfer size relative to bittorrent 57 | * Q2 - `M (P0)`: Expand benchmark test suite to compare relative to rsync, http, cp, dd 58 | * `M (P0)`: Go-IPFS bitswap (or equivalent) can transfer large files from many peers at 0.8 times the speed of BitTorrent. 59 | * Q1 - Bitswap session improvements that improve transfer efficiency by reducing duplicate blocks and efficiently fetching related data from many peers simultaneously. 60 | * Graphsync selector implementation that can understand non-overlapping subsets of data to select from multiple hosts and the driver that can build up graphsync requests for many peers to maximize efficiency and throughput. 61 | * `M (P0)`: Go-IPFS can transfer many small files at 0.8 times the speed of rsync (for single peers) or BitTorrent (for many peers) 62 | * Bitswap session improvements 63 | * Graph Exchange that can route requests efficiently 64 | * Q1 - Graphsync makes accessing files in large directories log(n) faster 65 | * Q1 - Flexible provider strategies 66 | * `M (P1)`: Go-IPFS can transfer large files from a single peer at 0.8 times the speed of HTTP. 67 | * Q1 - Flexible provider strategies to use the DHT efficiently (and therefore not slow IPFS down while adding/fetching files) while still preserving the reachability of data. 68 | * `M (P1)`: Go-IPFS can add a directory of many small files at 50% the speed of a simple local hard drive copy (or dd) (10k x 1MB files) 69 | * Flexible provider strategies to limit the number of DHT provider advertisements we make 70 | * Q1 - Faster datastore (Badger or equivalent) that doesn’t slow down as the number of blocks stored grows large 71 | * GC improvements (transactions, speed) 72 | * `M (P2)`: Data transferred over the network is no more than 1.2x the size of the data being transferred 73 | * Bitswap session improvements to reduce duplicates 74 | * Graphsync 75 | 76 | ### 🤝 IPFS Contributors and Developers 77 | 78 | Developers using IPFS can rely on go-ipfs as a platform on which to build their product, app, or ecosystem, and new contributors are well supported. 79 | 80 | #### Contributors 81 | * `M (P0)`: (all) Go-IPFS is approachable as a new contributor 82 | * Go-IPFS internals are well documented 83 | * Technical debt is paid off, all "indefinitely-in-progress" refactors are completed. 84 | * Cleanup/rethink abstraction layers with 20-20 hindsight. 85 | * Re-structure repos into reusable but not fragmented components. 86 | * `Q1 - M (P0)`: (all) Go-IPFS is usable without gx 87 | * Fix the versions (make them all sub-0) 88 | * Add go.mod files to every package 89 | * Merge #5435. 90 | * `M (P0)`: We have a stable core that people can add things to without breaking changes 91 | * UnixFS is stable and extensible 92 | * UnixFS v2 (with a good HAMT) 93 | * The DHT is extensible 94 | * Multi-DHT: https://github.com/ipfs/notes/issues/291#issuecomment-414495124 95 | * `Q1 - M (P0)`: Have a solution for testing/benchmarking 96 | * Available for offline testing. 97 | * Reproducibility (across different platforms). 98 | * Provide realistic Internet/WAN simulations (with delays and dropped packets). 99 | * `M (P1)`: Interfaces are future-proof enough for 1.0 100 | * CoreAPI 101 | * Plugins 102 | 103 | #### Developers (Users) 104 | * `M (P0)`: Provider lookups are efficient (<1 sec) in real-world network conditions (ex between physically distant peers) 105 | * `M (P0)`: (all) Users can reliably transfer data between any two nodes. 106 | * Reliable NAT traversal (AutoNAT, relay, TURN, etc). 107 | * Connection manager doesn't kill useful connections. 108 | * Scalable content routing 109 | * Reliable DHT: unreliable nodes don't join the DHT. 110 | * `M (P0)`: (dapps) ipfs:// and ipns:// work in web browsers 111 | * Base32 CIDs 112 | * Base32 IPNS or IPNS uses CIDs 113 | * `M (P1)`: (all) Go-IPFS is approachable as a user/app developer 114 | * User documentation. 115 | * Well designed API interface 116 | * Well designed API transport 117 | * `M (P1)`: (machine-learning/package managers) IPFS can handle (and transfer) large (>1M entries) sharded indexes (objects, directories) 118 | * Bitswap Improvements (sessions, prediction, etc) 119 | * UnixFS-V2 (better directory structure) 120 | * `M (P1)`: Fast (< 3s), mutable name resolution (IPNS) 121 | * Reliable DHT. 122 | * QUIC (for fast connection establishment). 123 | * Better protocol negotiation (multistream-2.0) 124 | * Delegated Routing 125 | * `M (P1)`: (Dapps) IPFS Realtime Story is as good as using a centralized service (e.g. Socket.io, Pusher, etc) 126 | * The API for doing secure (authenticated) broadcast updates exists 127 | * `M (P2)`: Go-ipfs can handle large datasets (>1TiB, >1M nodes) 128 | * Scalable content routing (providing) 129 | * DagSync (or at least better bitswap) 130 | * Reliable, performant datastore 131 | * `M (P2)`: (all, Dapps) IPFS is pluggable and extensible (9/10 users don't need custom features) 132 | * The go-ipfs plugins system is expanded to support new datastores, exchanges, etc 133 | * Exchanges support multiple protocols (that diagram from hack week) 134 | * Multi-DHT (https://github.com/ipfs/notes/issues/291#issuecomment-414495124) 135 | * UnixFS-V2 is implemented 136 | * `M (P3)`: (Dapps) IPFS can locally share data without a shared network 137 | * A bluetooth (or like) transport 138 | * `M (P4)`: (anti-censorship) Our IPFS implementations are secure and don't leak sensitive information 139 | * Get a security audit 140 | * Implement the privacy preserving DHT (https://github.com/ipfs/notes/issues/291#issuecomment-396003860) 141 | * Add a download-only mode (avoid serving local data) 142 | * Investigate a privacy-preserving transport 143 | 144 | 145 | ## ⏳ Timeline 146 | 147 | - Q1 148 | - Q2 149 | - Q3 150 | - Q4 151 | 152 | ## ⁉️ Want to get involved? 153 | - File an issue here with questions, or make a PR to suggest an alternate path or addition 154 | - Want to help make this happen? [Open an issue on the Go IPFS Working Group repo!](https://github.com/ipfs/go-ipfs/issues) 155 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_GUI.md: -------------------------------------------------------------------------------- 1 | # IPFS GUI Working Group Roadmap 2019 2 | 3 | #### _TODO: Descoping to focus on 📦 Package Managers as main 2019 Priority_ 4 | 5 | > Build intuitive and accessible user-interfaces for IPFS 6 | > We want the IPFS apps to support the endeavours of all the working groups, so please add your comments and suggestions to this document. 7 | 8 | **Responsibilities** 9 | - Fight complexity at every step. 10 | - IPFS must be usable and comprehensible for everyone. 11 | - Publish and promote this work. Make doing the right thing the easiest thing. 12 | - Demonstrate the nature of the system with effortless, coherent, and compelling interfaces. 13 | 14 | 15 | **Current Projects** 16 | - IPFS GUI - Team coordination point 17 | - IPFS Web UI - Graphical IPFS file manager and network explorer. 18 | - IPFS Desktop - Launch and manage IPFS from your OS GUI. 19 | - IPFS Companion - Give your browser IPFS super powers. 20 | - IPFS CSS - Single-purpose css rules and font-face config to IPFS up your UI. 21 | - IPFS UI Style Guide - The guide for for UI design in the IPFS universe. 22 | - IPFS Share Files - Share Files via IPFS 23 | 24 | ## 🚀 Major 2019 Goals 25 | - Co-hosting datasets, publishing to the dweb and sharing files via IPFS is intuitive for casual users. (Overlap with Community & Data Stewardship) 26 | - Grow the community of users and contributors (reusable components, reliable, stable release velocity, proactive maintenance, seek input, contributions welcome) 27 | - Bootstrap an IPFS Design team that leads the way on human-centered design for cryptography and decentralized apps. (See: design is the killer app for crypto) 28 | 29 | ## 💎 Milestones 30 | 31 | ### 🗂 Large files 32 | 33 | - `M (P0)` - Web UI File browser can render a view over a dir listing with 1 million entries (npm has 831,352 modules at time of writing) 34 | - `M (P0)` - WebUI can show information about a swarm of 100,000 peers without taxing the system or the daemon (requires streamable API for watching for change over time) 35 | - `M (P0)` - We have informative file transfer progress visualisations, that show the work being done by a community of peers, rather than a spinner or progress bar. 36 | - `M (P1)` - There is a Web UI for Cluster, tailored for the needs of large organisations. 37 | - `M (P1)` - There is a great IPFS app for local / small office / high trust file-sharing. (no auth / identity dependency) with customisable sharing pages for offering access to specific files 38 | 39 | ### 🔄 Decentralized Web 40 | 41 | - We share all our content via IPFS 42 | - `M (P0)` - There is an app for creating, editing, and hosting websites on IPFS 43 | - `M (P1)` - There is a mechanism for opt-in, anonymous, decentralised, usage analytics. 44 | - `M (P1)` - 1 million files are transferred via https://share.ipfs.io 45 | 46 | - The dweb web is personal and customizable 47 | - `M (PX)` - Peers can identify friends on the network with named nodes and avatars. 48 | - `M (PX)` - Our apps allow you to connect to specific peers and set up shared directories 49 | - `M (PX)` - Peers can set up ad-hoc reciprocal hosting with friends. (IPFS social graph / have your followers "sympathetically" rehost it automatically) 50 | 51 | ### 🧠 Strategic Projects 52 | 53 | - `M (PX)` - IPFS network metrics dashboard visualising public network swarm size over time and CID req/s throughput on from the gateways, number and health of co-operating public gateways. 54 | - `M (PX)` - Create apps to support decision making and collaboration between IPFS working groups as we grow. 55 | - `M (PX)` - Help build a community around design for cryptography and decentralization. Collaborate on the design challenges and establish and iterate on human-centered design guidelines. 56 | - `M (PX)` - Publish a guidebook of concepts and design patterns for decentralised apps. 57 | 58 | ## Timeline 59 | 60 | - Q1 61 | - Q2 62 | - Q3 63 | - Q4 64 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_INFRASTRUCTURE.md: -------------------------------------------------------------------------------- 1 | # IPFS Infrastructure Working Group 2019 Roadmap 2 | The IPFS Infrastructure Working Group supports infra tooling and systems for the IPFS Organization. 3 | 4 | ### Responsibilities include: 5 | * Manage and maintain the IPFS HTTP Gateway. 6 | * Manage and maintain the IPFS Bootstrapper nodes. 7 | * Manage and maintain the IPFS Preload nodes 8 | * Manage and maintain the IPFS pinning service, pinbot. 9 | * Monitor services and hosts used by the IPFS dev teams. 10 | * Provide wisdom to other users that want to host IPFS nodes. 11 | 12 | ## Current Projects 13 | * Gateway maintenance/redeployment 14 | * js preload/bootstrapper redeployment 15 | * CI prototyping for js-ipfs 16 | * kubernetes cluster standup for ipfs-cluster 17 | 18 | ## Major 2019 goals to achieve 19 | * 1) Each Package Management system implemented is supported by infra team as a 24/7 production service 20 | * ensures ease of adoption for our end users to use the management systems we provide via IPFS 21 | * 2) IPFS teams have the performance testing environments needed 22 | * aids dev teams in iterating through protocol changes quickly and safely 23 | * 3) Support teams with an interface to track project KPIs 24 | * provides visibility and tracking on progress for essential project KPIs 25 | 26 | ## Milestones 27 | 28 | * M (P?): performance testing environment is available to all IPFS working groups 🗂 🔄 🤝 🧠 📦 29 | * work between dev and infra to design & implement testing environment 30 | * M (P1): migrate gateway to .ipfs.dweb.link 🔄 31 | * M (P2): gateway is implemented in a way to discourage long term dependency on IPFS centralized services 🔄 32 | * M (P?+1): support npm-on-ipfs infra needs 📦 33 | * team of at least 4 engineers (2 js and 2 infra) designs & implements service 34 | * service SLA is designed and implemented 35 | * required specs: performance, uptime, monitoring, alerting, update workflow, oncall needs, etc. 36 | * More information on existing npm server + mirrors: 37 | * https://github.com/ipfs/infrastructure/issues/444 38 | * https://github.com/ipfs/infrastructure/issues/437 39 | * https://github.com/ipfs/infrastructure/issues/432 40 | * https://github.com/ipfs/infrastructure/issues/423 41 | * M (P?+2): support any additional ipfs-run services 📦 42 | * team of at least 4 engineers (2 ??? and 2 infra) designs & implements 43 | * production service SLA is designed and implemented 44 | * required specs: performance, uptime, monitoring, alerting, update workflow, oncall needs, etc. 45 | 46 | ## Timeline 47 | - Q1 48 | - Q2 49 | - Q3 50 | - Q4 51 | 52 | ## ⁉️ Want to get involved? 53 | - File an issue here with questions, or make a PR to suggest an alternate path or addition 54 | - Want to help make this happen? [Open an issue on the ipfs-infra Working Group repo!](https://github.com/ipfs/infra/issues) 55 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_INTEGRATION_IN_WEB_BROWSERS.md: -------------------------------------------------------------------------------- 1 | # IPFS in Web Browsers - Roadmap 2019 2 | 3 | #### _TODO: Descoping to focus on 📦 Package Managers as main 2019 Priority_ 4 | 5 | > Bringing IPFS support to Web Browsers 6 | 7 | **Responsibilities** 8 | 9 | *Browser Users* - Browser extension exposes IPFS features in a robust and intuitive form 10 | *Web Developers* - Ensure smooth experience for web developers in browser contexts 11 | *Browser Vendors* - Browser developers are addressing requirements of the distributed web 12 | 13 | **Current Projects** 14 | 15 | - [IPFS in Web Browsers](https://github.com/ipfs/in-web-browsers) - Coordination point (tracking via issues) 16 | - [IPFS Companion](https://github.com/ipfs/ipfs-companion) - Browser extension that brings IPFS integrations 17 | 18 | 19 | ## 🚀 Major 2019 Goals 20 | 21 | 1. Push forward new web standards for decentralized web 22 | 2. Remove obstacles from using IPFS in Web Applications and make the whole experience feel trivial 23 | 3. Incentivize users to install and use IPFS Companion. 24 | 25 | ## 💎 Milestones 26 | 27 | ### 🔄 Decentralized Web 28 | 29 | #### Foundation 30 | 31 | - `M(P0)` Base32 CIDv1 is the default and can be used as authority in URLs 32 | - `M(P0)` Drop-in API Provider library is the default way of integrating IPFS with web apps and browser extensions 33 | - `M(P0)` HTTP/WS /api/v1/ with proper access controls exists 34 | - `M(P1)` Docs or guidebook of developer best practices for writing decentralised web apps exists. 35 | - `M(PX)` It is possible to verify integrity of HTTP Gateway Responses 36 | - `M(PX)` URIs are officially registered (IANA etc) 37 | 38 | #### Amazement 39 | 40 | - `M(P1)` Having IPFS Companion installed is enough to create and publish a website on IPFS 41 | - `M(PX)` A complete snapshot of a web page can be saved to IPFS and shared with one click 42 | 43 | ## 🗂 Large files 44 | 45 | #### Amazement 46 | 47 | - `M(P1)` IPFS Companion enables real-time, bidirectional file sharing between two or more people over the internet 48 | - `M(P1)` IPFS Companion enables ad-hoc transfer between two people over local network 49 | 50 | ## 📦 Package managers 51 | 52 | #### Foundation 53 | 54 | - `M(P1)` Free and Open IPFS-powered CDN for JS libs exists 55 | 56 | ## 🧠 Strategic Projects 57 | 58 | - `M(P0)` Collaboration on libdweb results in landing vital APIs into Firefox 59 | - `M(P0)` IPFS is a viable distribution channel for Signed HTTP Exchanges 60 | - `M(P0)` Brave browser ships with embedded IPFS 61 | 62 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_JS_CORE.md: -------------------------------------------------------------------------------- 1 | # JS Core Dev Team 2019 Roadmap 2 | 3 | #### _TODO: Descoping to focus on 📦 Package Managers as main 2019 Priority_ 4 | 5 | > Oversees the development of the JS implementation of the IPFS protocol and related projects. 6 | 7 | **Responsibilities include:** 8 | - Implement and maintain the IPFS protocol and tools 9 | - Enable IPFS usage in Node.js, browsers and other JavaScript runtimes 10 | - Maintain interoperability with other IPFS implementations 11 | - Incubate and grow projects that will encourage IPFS adoption 12 | 13 | **Current Projects** 14 | - JS IPFS 15 | - JS IPFS API 16 | - Go & JS IPFS Interop 17 | - Npm on IPFS 18 | - IPFS Service Worker Gateway 19 | - IPFS Geo IP 20 | - IPFS Performance Profiling 21 | - benchmark-js.ipfs.io 22 | 23 | 24 | ## 🚀 Major 2019 Goals to achieve 25 | 26 | The major goals below and following milestones have been labeled with the emoji for the goal in the IPFS Project Roadmap that they contribute towards: 27 | 28 | 📦 = Package Managers 🗂 = Large Files 🔄 = Decentralized Web 🤝 = Partner Use Cases 🧠 = Strategic Projects 29 | 30 | - JS IPFS is ready for use in production. It is stable, performant, and interoperable with other IPFS implementations 📦 🗂 🔄 🤝 🧠 31 | - JS IPFS can ingest and move data with similar speeds to rsync or wget 📦 🗂 🔄 🤝 32 | - Data on JS IPFS is searchable both online and offline 📦 🔄 🤝 33 | - Developer experience is a joy 🔄 🤝 🧠 34 | 35 | ## 💎 Milestones 36 | 37 | ### `M (P0)`: Production ready 📦 🗂 🔄 🤝 🧠 38 | 39 | JS IPFS has for a long time now been under heavy development with a focus on implementing features. We’re now at a stage where it has a good level of feature parity to Go IPFS. Implementing the last key missing features and focused attention on performance, stability and security issues will allow JS IPFS to be a viable alternative to Go IPFS. 40 | 41 | - A JS IPFS daemon runs as part of the IPFS gateway cluster for at least 1 month without crashing 42 | - Performance metrics for a JS IPFS node are measurable: 43 | - Tools can process and graph performance data 44 | - Data can be queried to track down bugs and performance bottlenecks 45 | - Benchmarks exist to assert that: 46 | - Memory footprint remains stable and should not consume more than 20% more memory than a Go IPFS node 47 | - Network throughput is within an acceptable magnitude of Go IPFS 48 | - Data can be fetched with comparable speeds to tools like bittorrent, wget or rsync when 5 peers are connected who already have the data 49 | - Data can be exchanged with another IPFS node within 2x the speed a Go IPFS node would exchange it 50 | - An interoperable DHT exists and scales to hundreds of thousands of nodes 51 | - A gossipsub implementation exists 52 | - An IPFS log API is implemented and tests ensure log messages are part of the API 53 | - A security audit is conducted on the code base and all issues resolved 54 | 55 | ### `M (P1)`: Optimized for browser environments 🔄 🤝 🧠 56 | 57 | One of the biggest challenges that faces JS IPFS is that it will be used in many different environments where the tools and resources available to it differ significantly. JS IPFS can be run in a browser (Chrome, Firefox etc.), in a web extension, in Node.js on a laptop or on a server, in Electron, on mobile or even on IoT devices. Not only does the runtime differ - Node.js, Blink, SpiderMonkey etc. but the APIs available (no filesystem or low level network in a browser) as well as the hardware resources available e.g. mobile or IoT. 58 | 59 | - Default performance profiles exist and can be enabled to adapt IPFS behaviour appropriately to its environment. In addition to the profiles described here, the following profiles also exist: 60 | - Browser 61 | - Electron 62 | - Mobile 63 | - IoT 64 | - The JS IPFS build can be customised to exclude functionality or include different modules that are more appropriate for a particular runtime environment 65 | - At least 2 recommended builds for common environments will be provided in addition to the full build 66 | - Developers can tailor an IPFS build to their specific needs 67 | - Full build bundle size is monitored and does not exceed 2MB (minified) 68 | - Examples for bundling JS IPFS with common tools such as webpack/parcel exist 69 | - A JS IPFS daemon can run on a Raspberry Pi for at least 1 month 70 | - Example projects exist for running JS IPFS in a web view on iOS and Android 71 | 72 | ### `M (P1)`: Installable npm modules via JS IPFS 📦 🗂 🔄 🧠 73 | 74 | The npm registry is one of the biggest data sets JS developers interact with daily. There’s a myriad of benefits to it being accessible on the IPFS network. We’ll enable this at the same time as proving out the ability for JS IPFS to deal with large data sets. 75 | 76 | - There is an option to select IPFS as a transport on npm/yarn 77 | - A CLI tool exists to install packages directly from IPFS 78 | - JS IPFS can ingest the entire npm registry 79 | - Installing npm modules over LAN never fails (provided the module is available on another IPFS node connected to the LAN) 80 | - Installing any module is faster than using npm when 5 peers on the local network already have the package 81 | Node.js binaries are distributed via IPFS (making the whole Node.js/NPM installation process happen over IPFS) 82 | 83 | ### `M (P2)`: Discoverable npm modules via JS IPFS 📦 🗂 🔄 🧠 84 | 85 | One of the big features that IPFS lacks right now is content discoverability. A mechanism of searching for content on the IPFS network would greatly improve the situation. Considering our milestone of installing npm modules via JS IPFS, it makes sense to augment it with a search component to make it more attractive and useful as well as allowing us to achieve our major goal of adding search to JS IPFS. 86 | 87 | - Users can search for modules in the npm registry via IPFS 88 | - Users can learn about the latest registry index (module updates) via IPFS 89 | - Unixfs v2 is finalized and is the default format for new content added to IPFS 90 | 91 | ### `M (P2)`: Improved documentation, specs and examples 🔄 🤝 🧠 92 | 93 | Improving the docs, specs and having great tutorials and examples goes a long way to realising the distributed web for the simple reason that if people can’t drop by and pick up IPFS easily they’re less likely to use it. This milestone addresses that problem and also helps people already invested in IPFS to continue to build on top of it. 94 | 95 | - Code level: 96 | - Functions/methods all have meaningful descriptions 97 | - Functions/methods all have inline examples 98 | - Parameters are all documented, including types and defaults 99 | - Return values are documented, including object properties and types 100 | - Onboarding documentation exists to explain domain concepts and provide tutorials/examples for achieving common tasks 101 | 102 | ### `M (P0)`: Revamped APIs 🔄 🤝 🧠 103 | 104 | Revamping the APIs will make them easier to use and simpler to understand. Using modern syntax will make JS IPFS appealing to a wider segment of the JS community, aiding adoption and contributions. It also gives us scope to make performance optimisations and stability/debuggability improvements. 105 | 106 | - Async/await is used throughout the codebase and callback APIs are dropped 107 | - Support ArrayBuffer as an alternative to Buffer input argument 108 | - Streaming APIs switch to using async iterators/iterables 109 | - The files API is revamped: 110 | - Files functions moved to the root namespace 111 | - Non-MFS and MFS functions are merged 112 | - A revamped RESTful HTTP API exists 113 | - Old APIs are deprecated and removed (e.g. object, block) 114 | - At least one alternative API exists for JS IPFS (e.g. Graphql) 115 | 116 | ### `M (P3)`: Support for specific use cases 🔄 🤝 🧠 117 | 118 | This milestone focuses in on how JS IPFS can refine and augment it’s existing tech stack to better serve specific use cases. 119 | 120 | - Default chunkers exist for particular file types to optimise for example deduplication or seeking/direct access in tar archives and video files 121 | - High priority features requested from other working groups that have experienced pain points with the JS IPFS API are implemented e.g. Pagination and “Live” streams 122 | - IPFS nodes can discover one another for specific topics via the rendezvous protocol 123 | -star servers are no longer in use 124 | - IPFS nodes work and are compliant with the MDNS spec 125 | - Libp2p discovery and transport modules exist for bluetooth and libdweb, sound and potentially other exotic technologies 126 | 127 | ## Timeline 128 | 129 | - Q1 130 | - Q2 131 | - Q3 132 | - Q4 133 | -------------------------------------------------------------------------------- /archive/2019 WG roadmaps/WG_PROJECT.md: -------------------------------------------------------------------------------- 1 | # [IPFS Project Working Group](https://github.com/ipfs/team-mgmt/blob/master/TEAM_STRUCTURES.md#project) - 2019 Roadmap 2 | 3 | The [IPFS Project Working Group](https://github.com/ipfs/team-mgmt/blob/master/TEAM_STRUCTURES.md#project) serves as the point of coordination for the IPFS Organization. 4 | 5 | **Responsibilities include:** 6 | - Maintain the IPFS Project Roadmap and Vision. 7 | - Provide coaching to Working Groups to develop their own planning and goal-setting. 8 | - Facilitate communication and alignment across the organization. 9 | - Research, develop and build new ways to help async teams coordinate at scale. 10 | - Recognize needs of the project and develop solutions to meet them. 11 | - Spin up new working groups or projects to meet IPFS project needs. 12 | 13 | **Current Projects** 14 | - team-mgmt repo (tools and guides for the IPFS Team to coordinate with itself and the community) 15 | - IPFS Roadmap & supporting tools and materials 16 | - depviz - https://github.com/ipfs/pm/issues/132 (adopted) 17 | - 2018 Team Structure and 2019 projections 18 | 19 | ## 🚀 Major 2019 goals to achieve 20 | 21 | The major goals below and following milestones have been labeled with the emoji for the goal in the IPFS Project Roadmap that they contribute towards: 📦 = Package Managers 🤝 = Partner Use Cases 22 | 23 | _(Note: we also have many 🧠 = Strategic Projects)_ 24 | 25 | - **1)** The IPFS org has clearly communicated vision, goals, and priorities to align and accelerate project development and adoption. 📦 🤝 🧠 26 | - **2)** A baseline suite of Coordination Strategies and Tools becomes first nature to the org. These have minimal overhead without losing clarity and productivity. 📦 🤝 🧠 27 | - **3)** The IPFS org increases its ability to operate at scale (ability to support a growth of 1 order of magnitude in the number of contributors, from X,000 to X0,000). 📦 🤝 🧠 28 | 29 | ## 💎 Milestones 30 | 31 | ### Audit and improve our team guides, tools, and processes 32 | 33 | - `M (P1)`: The InterPlanetary Community Handbook is Published 🧠 34 | - A gitbook (or similar) containing the project values, how we organize ourselves, code of conduct, contributing guidelines and so on. 35 | - A new contributor spends less than a week onboarding into the community. 36 | - Roles & Responsibilities for team members and captains are well defined 37 | - It describes the Protocol Governance and how decisions are made. 38 | - `M (P1)`: Quarterly IPFS User Reports from our direct partners/collaborators and broad Users, exist and are useful to the Working Groups 🤝 39 | - Quarterly Reports are published that Highlight top user needs, feature requests, and pain points 40 | - `M (P2)`: Roadmap is updated and published with 2020+ plans 🧠 41 | - `M (P2)`: The IPFS org makes decisions based on user research 🤝 🧠 42 | - Working Groups have user researcher support to coordinate User Research efforts across the IPFS Project. Everyone can benefit from the output. 43 | - We have 6+ user researchers as full time contributors on IPFS projects 44 | - `M (P3)`: Evaluate the current set of tools/services we use to run our org and compare it with potential alternatives 🧠 45 | - List all the current ones we use 46 | - Explore and evaluate others (i.e. Gitlab) 47 | - Contribute to the analysis of the impact of OKRs in the IPFS Org 48 | 49 | ### Grow, support, and bootstrap IPFS working groups 50 | 51 | - `M (P0)`: Bootstrap a Package Managers Working group 📦 🧠 52 | - The IPFS Organization dogfoods Package Managers with IPFS 53 | - The WG adopts GX and npm-on-ipfs as their products 54 | - Gx is fast, efficient, and saves go developers time with 1+ fulltime maintainer 55 | - Create the Package Managers Working Group Roadmap in advance (even before the WG exists) containing all the insights from the 2019 Roadmapping endeavour 56 | - `M (P0)`: IPFS Events are open and planned proactively 🧠 57 | - IPFS Dev Meetings happen again 58 | - IPFSConf increases IPFS usage, # of applications on IPFS, community growth, and external awareness/engagement 59 | - Hack Weeks, Research Weeks and WG Gatherings are planned 60 | - `M (P0)`: Grow the Project WG with folks at full time capacity 🧠 61 | - We have at least the equivalent of 4 people full time 62 | - Project WG has an easy way to track cross-wg issues, blockers, and endeavors 63 | - `M (P0)`: IPFS Documentation & Specifications are organized, updated, and have 4+ active maintainers 🧠 64 | - `M (P0)`: IPFS gets a solid Security Program 📦 🤝 🧠 65 | - We have 2+ fulltime contributors to lead Security for IPFS 66 | - IPFS has a Responsible Disclosure Program 67 | - IPFS gets regularly audited 68 | - `M (P2)`: Bootstrap Offline/Mobile working groups to prepare for 2020 work towards distributed web vision 🧠 69 | 70 | ### Continue supporting a growing IPFS community while keep everyone excited and involved 🧠 71 | 72 | - `M (P1)`: The community receives Quarterly IPFS Project Reports (similar to the Filecoin updates) 🤝 73 | - Highlight achievements by each Working Group 74 | - Contain demos of what has been released 75 | - `M (P1)`: Create Large Research Contests for IPFS internals, driving adoption through enthusiasm and practice 🧠 📦 76 | - Block Exchange (Improve on Bitswap) 77 | - Graph Exchange (Improve on GraphSync) 78 | - `M (P1)`: IPFS gets a Public and Structured Dev Grant Program 🧠 📦 79 | - At least 50 projects are published under this grant program 80 | - `M (P3)`: IPFS collaborates with PL Research and creates a Public Research Grant Program dedicated to IPFS Open Problems 🧠 📦 81 | - At least 50 Open Problems are published 82 | - 100% of the proposals are evaluated 83 | 84 | ## ⏳ Timeline 85 | 86 | - Q1 87 | - `M (P0)`: Bootstrap a Package Managers Working group 📦 🧠 (Part 1: Roadmap, Onboard Owners for npm on IPFS, GX and partner relationships) 88 | - `M (P1)`: IPFS gets a Public and Structured Dev Grant Program 🧠 📦 (Part 1: Launch program) 89 | - `M (P1)`: The community receives Quarterly IPFS Project Reports (similar to the Filecoin updates) 🤝 (Part 1: Q1 Report) 90 | - `M (P1)`: Quarterly IPFS User Reports from our direct partners/collaborators and broad Users, exist and are useful to the Working Groups 🤝 (Part 1: Q1 Report) 91 | - `M (P0)`: IPFS Events are open and planned proactively 🧠 92 | - `M (P0)`: IPFS Documentation & Specifications are organized, updated, and have 4+ active maintainers 🧠 93 | - `M (P2)`: The IPFS org makes decisions based on user research 🤝 🧠 (Part 1: onboard some UXR support) 94 | - Q2 95 | - `M (P0)`: Grow the Project WG with folks at full time capacity 🧠 96 | - `M (P0)`: Bootstrap a Package Managers Working group 📦 🧠 (Part 2: Understand Package Manager Ecosystem Needs. Ensure that those are covered by the Core Impl work.) 97 | - `M (P1)`: The community receives Quarterly IPFS Project Reports (similar to the Filecoin updates) 🤝 (Part 2: Q2 Report) 98 | - `M (P1)`: The InterPlanetary Community Handbook is Published 🧠 (Part 1: Drafted) 99 | - `M (P1)`: Quarterly IPFS User Reports from our direct partners/collaborators and broad Users, exist and are useful to the Working Groups 🤝 (Part 2: Q2 Report) 100 | - `M (P0)`: IPFS gets a solid Security Program 📦 🤝 🧠 (Depends on LabOS figuring out the Security Team for PL) 101 | - `M (P2)`: The IPFS org makes decisions based on user research 🤝 🧠 (Part 2: integrate into decision making) 102 | - `M (P1)`: Create Large Research Contests for IPFS internals, driving adoption through enthusiasm and practice 🧠 📦 Part 0: preliminary planning) 103 | - Q3 104 | - `M (P0)`: Bootstrap a Package Managers Working group 📦 🧠 (Part 3: The world (the Package Managers we work with first) starts defaulting to IPFS as a transport.) 105 | - `M (P1)`: Quarterly IPFS User Reports from our direct partners/collaborators and broad Users, exist and are useful to the Working Groups 🤝 (Part 3: Q3 Report) 106 | - `M (P1)`: The community receives Quarterly IPFS Project Reports (similar to the Filecoin updates) 🤝 (Part 3: Q3 Report) 107 | - `M (P1)`: Create Large Research Contests for IPFS internals, driving adoption through enthusiasm and practice 🧠 📦 (part 1: Block Exchange grant) 108 | - `M (P1)`: The InterPlanetary Community Handbook is Published 🧠 (Part 2: LAUNCH - ?@ipfs conf?) 109 | - `M (P1)`: IPFS gets a Public and Structured Dev Grant Program 🧠 📦 (Part 2: target number of grants issued) 110 | - `M (P2)`: Bootstrap Offline/Mobile working groups to prepare for 2020 work towards distributed web vision 🧠 111 | - `M (P3)`: Evaluate the current set of tools/services we use to run our org and compare it with potential alternatives 🧠 112 | - Q4 113 | - `M (P1)`: Create Large Research Contests for IPFS internals, driving adoption through enthusiasm and practice 🧠 📦 (Part 2: Graph Exchange grant) 114 | - `M (P1)`: Quarterly IPFS User Reports from our direct partners/collaborators and broad Users, exist and are useful to the Working Groups 🤝 (Part 4: Q4 Report) 115 | - `M (P1)`: The community receives Quarterly IPFS Project Reports (similar to the Filecoin updates) 🤝 (Part 4: Q4 Report) 116 | - `M (P2)`: Roadmap is updated and published with 2020+ plans 🧠 117 | - `M (P3)`: IPFS collaborates with PL Research and creates a Public Research Grant Program dedicated to IPFS Open Problems 118 | 119 | ## ⁉️ Want to get involved? 120 | - File an issue here with questions, or make a PR to suggest an alternate path 121 | - Want to help make this happen? [Open an issue on the Project Working Group repo!](https://github.com/ipfs/project/issues) 122 | -------------------------------------------------------------------------------- /archive/2019-IPFS-Project-Roadmap.md: -------------------------------------------------------------------------------- 1 | # 2019 IPFS Project Roadmap 2 | _This is an archive of the 2019 IPFS project roadmap and goals for the year._ 3 | 4 | ## Table of Contents 5 | - [IPFS Mission Statement](#ipfs-mission-statement) 6 | - [2019 Priorities](#2019-priorities) 7 | - [2019 Working Groups Roadmaps](#2019-working-groups-roadmaps) 8 | - [2019 IPLD & libp2p Roadmaps](#2019-ipld--libp2p-roadmaps) 9 | - [2019 Epics](#2019-epics) 10 | - [2019 Goal (expanded)](#2019-goal-expanded) 11 | - [📦 Package Managers](#-package-managers-d1-e5-i3) 12 | 13 | ## IPFS Mission Statement 14 | 15 | In order to: 16 | - Ensure that all people have the ability to efficiently access and grow humanity's knowledge. 17 | - Mindfully develop new technologies that preserve and promote rights of individuals. 18 | - Support a persistent, upgradable, and open internet. 19 | 20 | We believe that: 21 | 22 | **All information on the internet should be uniquely and permanently content-addressed on a distributed peer-to-peer web.** 23 | 24 | ## 2019 Priority 25 | 26 | We will be focusing our efforts for 2019 into a single (lazer focus) priority. **📦 Package Managers** 27 | 28 | Adding end-to-end support for package managers will provide a verifiable and co-hostable foundation for a vital use-case that we rely on. It will focus us on delivering performance and stability improvements while introducing IPFS to a huge community who have the skills to contribute back. See inbound interest [here](https://github.com/ipfs/notes/issues?q=is%3Aissue+is%3Aopen+label%3A%22package+managers%22). 29 | 30 | At the same time, we will continue supporting **🤝 Community Growth** in the best way we can, without diverging too much from our main Priority. We want ensure that we are setting up our community for success by addressing key needs to unlock their growth in 2019. Making our users successful and delivering on their top needs to ensure they have a smooth and productive experience with IPFS helps us retain and gain adoption, grow our community, increase our impact, and demonstrate our maturity as a project. 31 | 32 | **Why setting a single priority?** 33 | 34 | The 2019 priority is geared to grow our maturity as a project, increase our adoption and community, and set ourselves up for the future. To be successful, we need to level-up our ability to land complete, polished, and accessible improvements that meet our user's needs for stability, scalability, privacy, and security. We need to keep growing intelligently, both by the types of communities that can help us accelerate growth and by the number of users they can help us reach. And we need to set ourselves up with the understanding and capabilities to reach our future goals for the project and scale our impact. We are confident that by aligning on *one* ambitious priority, we will be leveling up the core baseline of the IPFS Protocol, making it ready to tackle all the other goals that follow. 35 | 36 | To help us identify our top priority, we designed a sorting function to prioritize goals that 1) we can land end-to-end in 2019, 2) will bring new partners and users into the community, and 3) will set us up for future goals while delivering near-term value. After sorting, we identified what was the most achiavable (lower D) with largest Ecosystem Growth (higher E) and that would translate into Impact to our Ecosystems and Project (higher I). 37 | 38 | **Sorting Function Explanation** 39 | 40 | > **D** = Difficulty (or "Delta" or "Distance"), **E** = Ecosystem Growth, **I** = Importance 41 | 42 | Each goal was given a score from 1 (low) - 5 (high) on each axis. We sorted first in terms of low difficulty or "delta" (i.e. minimal additional requirements and fewer dependencies from the capabilities IPFS has now), then high ecosystem growth (growing our community and resources to help us gravity assist and accelerate our progress), and finally high importance (we want IPFS to have a strong, positive impact on the world). See the [2019 Goals (expanded)](#2019-goals-expanded) and [2020+ Goals](#2020-goals) sections for sorted priorities. 43 | 44 | **February Roadmap Update** 45 | 46 | We rescoped our 2019 priorities in early Q1 2019 to narrow in from 3 top-level priorities (also including [Large Files](README.md/#-large-files-d1-e4-i3) and [Decentralized Web](README.md/#-decentralized-web-d2-e4-i3)) to one ([Package Managers](README.md/#-package-managers-d1-e5-i3)) - so we could focus on doing the most important work *really well* instead of spreading ourselves too thin on many priorities, which we already felt ourselves doing. This descoping impacted the working group roadmaps we had drafted, and the Q1 OKRs we had already taken on. However, we decided to finish out our Q1 endeavors while we descoped our working group roadmaps and packaged up out-of-scope projects to set down smoothly, and to start our revamped roadmaps in Q2 with more focused and streamlined objectives, initiatives, and goals. 47 | 48 | ## 2019 Working Groups Roadmaps 49 | 50 | The IPFS project is the collective work of serveral focused teams, called Working Groups. Each group defines its own roadmap with tasks and priorities derived from the main IPFS Project Priority for 2019 described above. You can drill-down into each roadmap to get the full picture, or jump to the [2019 epics](#2019-epics) section below for the highlights. 51 | 52 | - [Project WG](2019%20WG%20roadmaps/WG_PROJECT.md) 53 | - [JS Core](2019%20WG%20roadmaps/WG_JS_CORE.md) 54 | - [Go Core](2019%20WG%20roadmaps/WG_GO_CORE.md) 55 | - [GUI](2019%20WG%20roadmaps/WG_GUI.md) 56 | - [Cluster](2019%20WG%20roadmaps/WG_CLUSTER.md) 57 | - [IPFS Infrastructure](2019%20WG%20roadmaps/WG_INFRASTRUCTURE.md) 58 | - [Community](2019%20WG%20roadmaps/WG_COMMUNITY.md) 59 | - [Integration in Web Browsers](2019%20WG%20roadmaps/WG_INTEGRATION_IN_WEB_BROWSERS.md) 60 | - [Dynamic Data & Capabilities](2019%20WG%20roadmaps/WG_DYNAMIC_DATA_AND_CAPABILITIES.md) 61 | - [Decentralized Data Stewardship](2019%20WG%20roadmaps/WG_DECENTRALIZED_DATA_STEWARDSHIP.md) 62 | 63 | ## 2019 IPLD & libp2p Roadmaps 64 | 65 | You can find the IPFS sister projects' Roadmaps for 2019 at: 66 | 67 | - [libp2p](https://docs.google.com/document/d/1Rd4yNw1TNQBvfRrKeEMSTseb6fvPzS-C--obOn0nul8/edit) 68 | - [IPLD](https://github.com/ipld/roadmap) 69 | 70 | ## 2019 Epics 71 | 72 | We've distilled the key themes from the Working Group Roadmaps into a list of **Epic Endeavours** that give an overview of the primary targets IPFS has for 2019. See the call to action (CTA) for each section below for how you can get involved. 73 | 74 | ### 1. The reference implementations of the IPFS Protocol (Go & JS) becomes Production Ready 75 | 76 | We've been working hard on improving and iterating on the IPFS Protocol to make sure it serves its users needs and achieves the goal of giving the Web a new super power: Content Addressing. In 2019 we will solidify the core components and ensure IPFS is ready for production systems. Our goals include: 77 | - IPFS core solidified and APIs revamped/crystalized to be future-proof 🔁❌ 78 | - Complete Specification of the Protocol ❌ 79 | - Security Audits and Security Program 🔁 80 | - Go and JS IPFS enable modern IPFS data formats ([UnixFSv2](https://github.com/ipfs/unixfs-v2), [CIDv1](https://github.com/ipld/cid), raw blocks) by default and in a reproducible way 🔁✅ 81 | - The migration to Base32 CIDs is completed across all projects and IPFS Gateway. ~✅ 82 | 83 | You can contribute to these Epic by testing, debugging, documenting or coding on either Go or JS IPFS. Both teams have a chat every week that you can join. [Go](https://github.com/ipfs/team-mgmt/blob/master/MGMT_GOLANG_CORE_DEV.md) & [JS](https://github.com/ipfs/team-mgmt/blob/master/MGMT_JS_CORE_DEV.md#weekly-core-dev-team-calls). 84 | 85 | ### 2. Support Software Package Managers in entering the Distributed Web 86 | 87 | Software Package Managers are an ideal use-case for Content Addressing. Developers could fetch packages team mates on their local network instead of asking a centralized Package Registries and our tools could verify that the code we run is exactly the code that the authors intended. 88 | - Kick-off a Package Managers Working Group to work closely with different Package Managers and understand each one challenges and needs. ✅ 89 | - Publish a report on the results from adding the NPM Registry to IPFS. 🔁 90 | - Meet the scalability and performance needs to serve the Package Management user-case. 🔁❌ 91 | 92 | We will be booting the Package Managers Working Group in early 2019, meanwhile, check out [NPM on IPFS](https://github.com/ipfs-shipyard/npm-on-ipfs) & [GX](https://github.com/whyrusleeping/gx) to get a feel for what IPFS can contribute to Package Management. 93 | 94 | ### 3. Scale the IPFS Network 95 | 96 | To support the continued growth of the IPFS Network, we will be testing and benchmarking the protocol at scale. 97 | - Deploy a P2P testbed for Distributed Protocols that enables us to spin up hundreds of thousands of nodes on demand and run tests on them. 🔁✅ 98 | - IPFS has an opt-in Telemetry system so that tests can collect key data to understand the experiments. ❌ 99 | 100 | Our friends from libp2p will be playing the larger role in achieving this goal. If you are a Networks specialist and/or if you like scaling systems to serve hundreds of millions, join the conversation in the [Bi-Weekly Libp2p Call](https://github.com/libp2p/team-mgmt#bi-weekly-call) and learn more. 101 | 102 | ### 4. The IPFS Community of Builders gets together for the 1st [IPFS Camp](https://github.com/ipfs/camp) 103 | 104 | Yes, you read the title right. The IPFS Community is going to meet for the first large IPFS Event. This will be an event for all the users and builders of the DWeb to come together to learn about the exciting progress that has been happening. 105 | - Host the 1st Conference for the IPFS Community. ✅ 106 | 107 | More details will be public soon. Subscribe for updates [here](https://github.com/ipfs/camp). 108 | 109 | ### 5. IPFS testing, benchmarks, and performance optimizations 110 | 111 | In order to prepare ourselves for production readiness and ensure IPFS is optimized for a variety of real-world use cases, we'll double down on testing and benchmarking in 2019. 112 | - Testing harness and environments that simulate different topologies / network configurations. ✅ 113 | - Tests for Interoperability, Performance Benchmarks, Reliability, and Network churn. ~✅ 114 | - Performance overhaul for resolving (IPNS), finding (Providers), transferring, and adding files. ✅ (to be launched) 115 | 116 | ### 6. Support the growing IPFS Community 117 | 118 | The IPFS Community is composed of many enthusiasts from the DWeb, P2P, Crypto, Privacy, builders, Web 3.0, Blockchain and many more. Today we have an impressive 3700+ contributors directly improving the IPFS, libp2p, IPLD and Multiformats repos, but there are tens of thousands more contributing to Apps, Libraries and Systems that build on top of IPFS everyday! In 2019, we want to provide a rich platform for all these contributors to share their ideas, get their questions heard, cross-pollinate and tackle new challenges! 119 | - The documentation on IPFS and its libraries gets revamped and becomes part of continuous delivery. ✅ 120 | - Increase awareness and adoption through Community outreach via presentations, guides / how-tos, meetups, and quarterly IPFS Project updates. ✅ 121 | - Support contributor productivity and impact through Quarterly User Reports, fast code reviews, and DevOps automation. ❌ 122 | - Create IPFS Dev Grant and Research Grant programs to encourage global engagement with the cutting-edge work in the IPFS ecosystem. ✅ 123 | - Launch [ProtoSchool](https://proto.school/), an interactive way to learn how to build on the P2P Web. ✅ 124 | - IPFS Community Meetups receive an upgrade with education materials (guides, tutorials, workshops, talks) to boost the leveling up DWeb communities. ✅ 125 | 126 | ## 2019 Goal (expanded) 127 | 128 | ### 📦 Package Managers (D1 E5 I3) 129 | 130 | > The most used code and binary Package Managers are powered by IPFS. 131 | 132 | Package Managers collect and curate sizable datasets. Top package managers distribute code libraries (eg npm, pypi, cargo, ...), binaries and program source code (eg apt, pacman, brew ...), full applications (app stores), datasets, and more. They are critical components of the programming and computing experience, and are the perfect use case for IPFS. 133 | 134 | Most package managers can benefit tremendously from the content-addressing, peer-to-peer, decentralized, and offline capabilities of IPFS. Existing Package Managers should switch over to using IPFS as a default, or at least an optional way of distributing their assets, and their own updates. New Package Managers should be built entirely on IPFS. --- Code libraries, programs, and datasets should become permanent, resilient, partition tolerant, and authenticated, and IPFS can get them there. Registries become curators and seeds, but do not have to bear the costs of the entire bandwidth. Registries could become properly decentralized. --- We have a number of challenges ahead to make this a reality, but we are already beyond half-way. We should be able to get top package managers to (a) use IPFS as an optional distribution mechanism, then (b) use that to test all kinds of edge cases in the wild and to drive performance improvements , then (c) get package managers to switch over the defaults. 135 | -------------------------------------------------------------------------------- /archive/2020-IPFS-Project-Planning.md: -------------------------------------------------------------------------------- 1 | # 2020 IPFS Project Planning 2 | 3 | It’s that time of the year again! Q4 is upon us, and as such it is time to reflect on IPFS progress and status, how the wider ecosystem and internet has evolved over the past year, and chart a course for our work in 2020 that optimizes for the long term success of [our mission as a Project](https://github.com/ipfs/roadmap/blob/master/README.md#ipfs-mission-statement). 4 | 5 | ## 2019 Project State 6 | This has been an absolutely huge year for IPFS adoption - be that applications building on IPFS, end users of applications powered by IPFS, or total nodes in the IPFS network (see more in [this video from IPFS Camp](https://www.youtube.com/watch?v=jpQnQbfhuBc)). More and more tools - inside and outside the web3 ecosystem - are using IPFS to benefit from content-addressing or empower their users to operate peer-to-peer. In the past year, we’ve seen a proliferation of **IPFS on mobile** with [Haven](https://gethaven.app/), [Textile](https://textile.photos), and [Berty](https://berty.tech); we’ve seen new solutions for **identity** emerge on top of IPFS in [3box](https://3box.io), [uPort](https://www.uport.me), and [IDM](https://github.com/ipfs-shipyard/pm-idm); we’ve seen great strides in support for **IPFS in web browsers** from [Brave & Opera](https://blog.ipfs.io/2019-10-08-ipfs-browsers-update/), and groups like [ENS](https://medium.com/the-ethereum-name-service/ethdns-9d56298fa38a); and we’ve seen a whole host of **supporting tools** be created like HTTP gateways ([Cloudflare](https://developers.cloudflare.com/distributed-web/ipfs-gateway/)), pinning services ([Pinata](https://pinata.cloud) & [Eternum](https://eternum.io)), and IPFS infrastructure ([Infura](http://infura.io) & [Temporal](https://temporal.cloud/)) to support IPFS users and developers. 7 | 8 | This increase in adoption also opened up new challenges for the IPFS Project - especially around accommodating new scalability needs for our DHT, infrastructure, and testing. In addition to continuing work on our core focus for the year - improving IPFS performance and tooling to support adding, updating, and fetching large directories of data from IPFS (aka our “package managers” use case) - we also launched important new work streams to improve IPFS reliability via significant investments in IPFS infrastructure, end-to-end network simulation & testing, and improved documentation ([read more about that here](https://blog.ipfs.io/2019-07-31-operation-task-force/)). We expect those threads of work to continue into 2020 as well, however we also want to hear from folks throughout the community if there are focus areas for 2020 that deserve more attention, research, or prioritization as the Project heads into planning for the next year. **We’d love your input! 👂** 9 | 10 | ## Call for _Theme_ Proposals 11 | To that end, please share your **proposals** for _themes_ for the IPFS Project to invest in more deeply in 2020. These could be specific use cases (like [IPFS for large files](https://github.com/ipfs/roadmap#-large-files-d1-e4-i3)), specific improvement areas (like IPFS developer usability), specific markets (like IPFS for enterprise), specific integrations (like IPFS x blockchain), or more! To suggest a _theme_, please create a new [**2020 Theme Proposal** issue](https://github.com/ipfs/roadmap/issues/new/choose) in this repo ([here’s a first example](https://github.com/ipfs/roadmap/issues/42)). The hope with using github issues is to help others build on your great ideas in issue comments, and also be inspired to propose their own thoughts for discussion. You aren't limited to only one! ✍️ 12 | 13 | 14 | ### The [2020 Theme Proposal template](https://github.com/ipfs/roadmap/issues/new/choose) includes: 15 | - Theme title 16 | - Problem statement description 17 | - Core needs & gaps 18 | - Why focus this year 19 | - Milestones & rough roadmap 20 | - Desired / expected impact 21 | But also feel free to include any other relevant content! 22 | 23 | ### Known 2020 Milestones 🎯 24 | To help identify **good** _themes_, here is an incomplete list of some exciting milestones coming up in the next year, which may open up new opportunities for IPFS to create value in 2020 and beyond: 25 | 1. Many IPFS-powered dapps will launch betas in early-mid 2020, including a number of teams in attendance at IPFS Camp 2019 26 | 2. Eth2.0 is launching sometime in Q1 2020, building on libp2p as their networking layer 27 | 3. Filecoin is aiming to launch their mainnet in ~March 2020 28 | 4. We will have basic ipfs:// support in 1+ browser out-of-the-box, and other browsers actively investing in more experimentation by early 2020 29 | 5. IPLD schemas work will come to fruition, along with codegen for go-ipld-prime 30 | 6. We will have more gatherings to get the wider IPFS community together! (timing TBD) 31 | 7. 32 | 33 | 34 | ### 2020 Planning Process Timeline 📆 35 | - **Oct 23 - Nov 8**: Open call for 2020 Theme Proposals _(add yours [here](https://github.com/ipfs/roadmap/issues/new/choose))_ 36 | - **Nov 11 - Nov 15**: IPFS 2020 Planning “Spike” 37 | - **Nov 18 - Nov 22**: Review and feedback on 2020 theme(s) with key stakeholders 38 | - **Dec 2 - Dec 6**: Finalize and present 2020 theme(s) and updated roadmap 39 | - **Dec 9 - Dec 20**: Project and working group Q1 2020 OKRs 40 | 41 | ### Credit 🙏 42 | In planning this year’s roadmapping process, we borrowed a lot of great ideas from the [Rust Roadmapping efforts](https://github.com/rust-lang/rfcs/blob/master/text/1728-north-star.md) of the past few years in addition to learning from what worked well and what we wanted to iterate on from [last year's IPFS planning process](https://blog.ipfs.io/78-ipfs-2019-roadmap/). Check out [the Rust 2019 Roadmap](https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md) for some great exemplars! 43 | -------------------------------------------------------------------------------- /archive/2021-IPFS-Project-Planning.md: -------------------------------------------------------------------------------- 1 | # 2021 IPFS Project Planning 2 | As 2020 comes to a close and we look ahead to 2021, it’s time to evaluate what’s important for the IPFS Project to focus on next year -- and we need your help! Get involved now and shape the IPFS project plan for the next year. Help us reflect on IPFS progress and status, how the wider ecosystem and internet has evolved over the past year, and chart a course for our work in 2021 that optimizes for the long term success of our mission. 3 | 4 | ## Potential Themes for 2021 5 | The IPFS team has started evaluating potential themes to guide the project in 2021. These themes are high level outcomes that would take a quarter or more and multiple initiatives to complete. See [the Roadmap repo](https://github.com/ipfs/roadmap/issues?q=is%3Aissue+is%3Aopen+label%3A%222021+Theme+Proposal%22) for a first pass at themes that resonate with the core IPFS Working Groups. The final north star for 2021 might be a combination of them or something that emerges from your input. As usual, this is a collaborative effort to assess what is important for the IPFS Project to achieve next year - work that we hope spans the efforts of many teams and projects - so we hope this process is a great feedback mechanism for many groups throughout the IPFS Ecosystem! 6 | 7 | ## Proposal Process 8 | We want to hear from you in the form of public Github issues. Issues should contain a potential theme that you think IPFS should tackle in 2021 - and why. Your theme proposals can be at any level of granularity — from general direction for the project, to specific features or tooling improvements, to ecosystem needs — everything is in scope. We want to hear what’s on your mind, what direction you want to take IPFS, and what your pain points are. 9 | 10 | Aside from new theme proposals, we’d also very much appreciate comments on theme proposals, especially if there are additional important workstreams you’d like to see as part of that theme. Existing proposals for themes can be found [here](https://github.com/ipfs/roadmap/issues?q=is%3Aissue+is%3Aopen+label%3A%222021+Theme+Proposal%22). 11 | 12 | To suggest a theme proposal, please create a [new 2021 Proposal issue](https://github.com/ipfs/roadmap/issues/new/choose) in this repo. The hope with using github issues is to allow for clarifying conversation in comments, help others build on your great ideas, and also be inspired to propose their own thoughts. You are welcome to submit more than one proposal! 13 | 14 | ### The [2021 Theme Proposal template](https://github.com/ipfs/roadmap/issues/new/choose) includes 15 | - **Theme title** 16 | - **Description**: What is the objective of the theme, what problem does it solve, and what would executing on it entail? 17 | - **Hypothesis**: What do you need to believe for this to make sense as a 2021 theme? 18 | - **Vision statement**: If executing on the theme or initiative is massively successful, what would the state of the IPFS project look like? 19 | - **Why focus this year**: Why does it make sense to focus on this theme or initiative this year? 20 | - **Example workstreams**: What are potential workstreams, milestones, etc. that this initiative or theme might involve? 21 | Feel free to include any other relevant content! 22 | 23 | Check out [existing proposals for themes here](https://github.com/ipfs/roadmap/issues?q=is%3Aissue+is%3Aopen+label%3A%222021+Theme+Proposal%22) if helpful. 24 | 25 | ### 2021 Planning Process Timeline 📆 26 | - **Nov 19 - Dec 7**: Open call for 2021 Proposals (add yours [here](https://github.com/ipfs/roadmap/issues/new/choose)) 27 | - **Dec 16 - Dec 20**: IPFS 2021 planning “Spike” 28 | - **Dec 20 - Jan 11**: Review and feedback on 2021 theme(s) with key stakeholders 29 | - **Jan 18**: Finalize and present 2021 theme(s) and updated roadmap 30 | --------------------------------------------------------------------------------