# B, P & S planning 2023

Agenda
* (20m) Vision / mission review and framing
* (10m) Divergence: Pain points and gaps list
* (15m) Convergence: Speed prioritization
* (10m) Themes from list
* (30m) Objectives - what we want to be true
* (15m) KRs - facts if the objectives were true
* (30m) Roadmap 2023 - 2025
* (10m) Hiring -
* (2m) Team name bikeshedding :banana:

## Vision / mission review

https://hackmd.io/kPj-PqO2RzSZbFkdnIhPxw

Vision notes
* missing: we make modular things to pick and choose, not tightly coupling things - things remain composable, for the long term view in making them useful
* missing: web technology in non-http contexts to achieve some outcomes
* missing: the why - user agency , anchor vision into the why

Mission notes

## Divergence: Current pain points and gaps
- Implementation complexity + lack of good mental models = adoption barrier 4,4, 4
- Trust / Threat Modeling not being explicit part of specs process, design process → do not end up in end user docs and specs 5,5 5
- Privacy does not exist, but could (DHT, Delegated Routing / Indexers [double hashing](https://pl-strflt.notion.site/Double-Hashing-for-Privacy-ff44e3156ce040579289996fec9af609)) 5, 5
- Existing libraries do not fit into all of the places we want them to 5 5
- Specs are scattered all over the place 3 4 5
- Explaining IPFS to FOSS entities who don't know IPFS at all yet. 4 5
- Difficult for even devs to understand why "IPFS" would be useful for them. 4 4
- Unclarity of use cases to a wider audience limits conversations 4 4
- Lack of a unified testing implementation across the board (à la WPT) 5
- no privacy model means our stuff is still "crazy" 4
- no developer environment or debugging tool 4
- super slow and complex to bring ipfs to other environments (need to be present and embedded) 3
- Need more small, reusable components in order to integrate in other places quicker
- we have way too many fucking projects, i haven't told you about half of them
- team structure and communications need an upgrade - how/where/when should we meet and communicate
- Unclear integration into the Web stack (origin, meaning of verbs like POST, mapping of SRI to CIDs)
- No one outside of IPFSland has heard of IPLD, etc. (slight exaggeration, but still)
- duplicated effort across org

## Convergence: Themes

- privacy, security, trust-model
- UX
- explaining, educating, mental models
- obscurity
- complexity
- bridges, integration, interoperability
- DX
- complexity

(meta)
- team scope/time

## 2023 Objectives and Key Results

Objectives: what we want to be true at the end of 2023
Key results: facts if those objectives were true

### O: We have regular presence and participation in relevant standards/governance/policy arenas, easing adoption choice of content-addressing and IPFS

* KR: We've identified key standards and policy participation fora required for adoption at scale
* KR: We're members and actively participating in the relevant fora, demonstrated by at least one draft proposal or key decision we influenced in each
* KR: At least one piece of the interplanetary stack has been proposed at W3C, IETF, DIF or CASA

Initiatives/milestones:
* Strategy document - published, feedback'd
* Multi* at IETF
* Dapp manifests proposed at CASA
* CID at IETF
* Addressing roadmap defined and published (schemes, urn namespace, etc)
* IPID vs Key for DID schemes - determine strategy and stakeholders (eg web3/nft.storage folks)

### O: Interoperable IPFS is implementable using specifications without reading Kubo source code (shared with Stewards)

* KR: Specifications one-stop-shop exists for builders and implementers
* KR: Implementers use a unified test suite and testing infrastructure as they implement (eg. WPT)
* KR: Implementers use canonical end-to-end test(s) to understand the level of conformance and interoperability (eg ACID)

Initiatives/milestones
* look up

### O: IPFS client integrations default to verifiable retrieval and are not reliant on a single HTTP endpoint :vhs: :floppy_disk:

* KR: The IPFS verifiable retrieval racing client spec is defined and published
* KR: There is at least one implementation of IPFS verifiable retrieval client in production use
* KR: Developers use IPFS without being dependent on PL-run infrastructure
* KR: Developers use IPFS without having to rely on single hardcoded, centralized HTTP endpoints

Notes
* (examples: KIO/GVFS/GDAL, etc.. [more](https://github.com/ipfs/integrations/issues))
* Ok to have centralized services to improve performance, but there should always be a decentralized/robust way of doing things that is not tied to infra maintained by a single company.

Initiatives/milestones:
* IPFS client IPIP published and finalized
* Demonstrate this pattern in Durin
* Curl
* FFmpeg

Dependencies
* Content routing work by stewards to not hardcode cid.contact

### O: An IPFS device-to-device connectivity pattern is specified, implemented and used by mobile apps

* KR: PoC Application-level pattern implemented and demonstrated in Durin
* KR: Pattern formalized in a specification
* KR: Two other integrations or applications have implemented or shipped the pattern

Initiatives/milestones:
- Phase 1 of this is defined for Durin

### O: The values, use cases, and model of the interplanetary Web are findable and usable

* KR: Core use cases which illustrate trade-offs that are different from those made by browsers are catalogued in a single document
* KR: A threat model exists which addresses privacy, security, trust/verifiability, developed against the use-cases document for at least one runtime context
* KR: We've published reference materials for what the interplanetary stack unlocks, both inside and outside browsers, and our position on user agency
* KR: We've documented and published a review of existing efforts towards IPFS privacy and other parts of the threat model
* KR: We have explainers and educational material which articulate the mental-model of the distributed web to point at as a reference to quickly onboard new and interested deciders

Notes:
- key strategic work blocking adoption at scale
- See DID Core use cases for a good approach to the "whys"
- Contrast with what can and can't be done with:
- https://www.w3.org/2001/tag/doc/ethical-web-principles/
- https://www.rfc-editor.org/rfc/rfc8890
- https://www.w3.org/TR/design-principles/
- https://w3ctag.github.io/privacy-principles/
- list of "red flags" - dns dependent, hardcoded http endpoints
- explaining upgrading the web - clearly, what to expect, what it looks like, roadmap
- see also decentralization rubric from DID-Core
- see notes in https://hackmd.io/@robin-berjon/trust

Initiatives/milestones:

### O: Content addressing is present, understood and has demonstrated value in the web platform

* KR: IPFS native protocol support is in at least one browser engine
* KR: NFT health, pinning, detection, other use-cases are ready to be implemented when browsers add NFT features
* KR: Web platform consideration of CIDs in integrity features like SRI

Notes
* native protocol support
- LBL building verifiable racing client in Chromium
* SRI
- Can specify CIDs instead of explicit hash function
- Fallback content loading
- https://discuss.ipfs.tech/t/supporting-large-ipld-blocks/15093

Initiatives/milestones:
* Igalia/LBL Chromium implementation
* Brave NFT pinning
* Igalia SRI collaboration
* DNSLink integrity guarantees
* Demonstrating content-addressing alternative approaches to SXG

### O: We've refined and demonstrated core use cases for applications in alternative environments, verticals and specific communities through integrations and collaborations

* KR: We've built out use cases or experiments with at least three verticals to showcase the ecosystem in ways that carry within specific communities of practice
* KR: We've built out uses cases or experiments in collaboration with at least three groups to meet critical marginalized user needs, such as internet shutdowns

Initiatives/milestones
* ShutDAOn - internet shutdown
* Flaki on video for RustConf
* OmniLingo
* XR/metaverse - collab w/ OMI, Igalia
* Pin-tweet -

Notes:
* use-case verticals
* Identify and collaborate with partners who could work with us towards this goal
* eg video, IoT, browser "reinventers", folks looking for browser business models
* http://la3.org/~kilburn/blog/catalan-government-bypass-ipfs/

### FIXME: O: IPFS is reasonably usable and chooseable by developers in environments where running a node is not an option, with examples demonstrating usage

* KR: A simple pattern for using IPFS in browser extensions is developed and published
* KR: IPFS can be used in native mobile applications
* KR: IPFS can be used in cloud-native environments
* KR: Web Developers can choose IPFS and get value and consistent DX across UAs w/o needing browser support

Initiatives/milestones
* IPIP for racing verifiable http client
* Durin
* Extensions
* Curl
* FFmpeg
*

* a lot wrapped up:
* self hosting on your own http app deployment
* ipfs as a fallback
* verifiable client adoption

* web and SW:
- ServiceWorker polyfills for loading content-addressed data
- see Saturn sw work
- see DagHouse racing gateway sw
- moves verification to client

### O: We have published a recommended architecture for IPFS integrations which is implemented in multiple keystone collaborations

* KR: `Q1` We've published an IPIP for an architectural approach to integrate IPFS into stateless libraries/tools, OS file explorers
* KR: `Q2` We've identified and prioritized keystone integrations which unlock broad scale adoption of IPFS
* KR: `Q3` We have two explorations and collaborations for desktop OS integrations of IPFS
* KR: `Q3` Three keystone open source libraries and tools have IPFS integrations
* KR: `Q4` IPFS integrations exist in key web frameworks and libraries which unlock more/easier adoption of IPFS addresses

Initiatives/milestones
* IPIP published
* integration strategy and targets identified
*

Notes
- Desktop related integrations (libipfsclient requirement)
- KDE/Gnome in their IO layers (KIO/GVFS)
- Windows and macOS too though those need more research
- libraries/tooling
- Tooling like (potentially) wget, pip, brew, vstudio, KODI and VLC
- Library integration like libcloud and GDAL
- web frameworks
- Examples are markdown libraries, forum software (discourse), chat applications (slack/matrix) and video/media libraries in js
- Media player frameworks to support IPFS playback (Eg. video.js, hls.js)
- Communication software like Matrix and Discourse
- And other web frameworks like markdown libraries

## O: We've implemented key opportunities to improve the web2 platform in ways that enable value-aligned technology upgrades

* KR: Ed25519 is implemented in the WebCrypto API
* KR: "immutable" is a valid cache control header value
* KR: Local discovery and P2P opportunities are explored via the Web-RTC and Second Screen WGs
* KR: As IPFS improves its privacy, loading resources off of IPFS can become more privacy-preserving than loading over HTTP. This could make it an attractive option for some parts of the reformed ad stack (FLEDGE, IPA).

### O: Presence and participation in decentralized identity governance, standardization and implementation activity

- KR: We have a document explaining each of the relevant decentralized identify efforts
- [new WebId](https://github.com/mfosterio/WebID), Trust Tokens, Filecoin in wallets, IPID (DID+IPLD), [UCAN](https://github.com/ucan-wg/spec) (DID+delegation), Blue Sky's [AT Protocol](https://atproto.com/)
- KR: We've identified where we have strategic needs, and participate in those communities
- KR: We are guiding/participating in browser or web standards related to managing keys on behalf of user

## References

- integration verticals: space, metaverse, phones, embedded/iot, science, games, audio, video, photo, 3d, art, search (eg. CommonCrawl), civic/govt

## Parking lot

- KR: specifying a form of "dumb loading" for browsers that could get content-addressed data inside of the origin if it can make the right guarantees
- IPFS integration in an IDE (vscode?) or at least researching/documenting how to make such an integration. (potentially hire external party)
- ODU lifetime of a web page research

## Things we we're doing now

* Explaining IPFS over and over again in very specific details (like how to get content from it, that there is no URL spec, etc...)
* Adjusting to the community contributing rules/guidelines to get a patch acceptable in their standards (think curl)
* providing IPFS Stewards and other stakeholders with real world use cases and constraints
* Sometimes trying to manage a dumpster fire (like curl influencing ffmpeg)
* Durin mobile development (IPFS light client~ish )
* Coordinating with trigram on development on certain projects (been a big time saver so far)
* Developing Web extensions targeted to "end users" to educate about IPFS, webrecorder, and web3.storage (ie: pin-tweet-to-ipfs)
* https://chrome.google.com/webstore/detail/pin-tweet-to-ipfs/bkbejdaeamaehgpodkjdbkhkofpijagn?hl=en&authuser=0
* Design and discussions for the IPFS Client API
* Working on next steps for companion after getting UR results
* mv3 companion
* coordinating with gui team to try and solve dx problems
* identifying gaps in documentation and tooling
* efforts around improving public gateway checker
* consolidating IPFS tooling into diagnostic view)
* blogging about everything we do
* discussing mv3 issues with companion #666
* Chromium integration
* Igalia
* Little Bear Labs
* Ed25519
* Igalia
* Space
* Lockheed Martin
* Little Bear Labs
* Libre Space Foundation
* CryptoSat
* Metaverse
*
* Gecko
* Capyloon
* Smartphone OS
* Capyloon
* Lifetime of a web page w/ ODU

## Roadmap 2023 - 2025

Key milestones:

## Roles

* Dietrich Ayala - figurehead
* David Justice - browser extension, mobile app development
* Mark Gaiser - OS and library integrations
* Robin Berjon - standards and governance lead
* TBH - technical project manager
* TBH - browser engineer
* TBH - open source emissary / CX designer
* TBH - DX / tools / integration developer

## Team Name

* browsers / web
* platforms
* standards
* alternative
* interplanetary
* integrations
* user agency
* Outer Planets
* Outer Planets Alliance
* INTEGRAL
INTergrating
Eternally
GRateful
AppLications
* OMEGA
Open to
Massively
Enhanced and
Grateful
Applications

## Notes on threat model

- Topology definitions - single http, * http, device to device, device to n devices, DHT, non-DHT
- party visibility topologies
- device to device
- client to local subnet
- client to gateway
- client to dht

TODO:
- We should have a list of companies where we have leads/contacts, and have they been contacted yet (like… a CRM system?)