docs: (de-scoping) first pass at updating the JS Core Roadmap #22
Conversation
ghost
assigned
| @@ -50,7 +52,7 @@ JS IPFS has for a long time now been under heavy development with a focus on imp | |||
| - An IPFS log API is implemented and tests ensure log messages are part of the API | |||
| - A security audit is conducted on the code base and all issues resolved | |||
|
|
|||
| ### `M (P1)`: Optimized for browser environments 🔄 🤝 🧠 | |||
| ### `M (P1)`: Optimized for browser environments 📦 🤝 | |||
There was a problem hiding this comment.
This Milestone will enable the Web Browsers Working Group to ship an amazing DWebCDN using JS IPFS and given that the <script> tag is still the most widely used package manager of the Web, it will have a tremendous impact.
Consider dropping priority for Electron, Mobile and/or IoT
WG_JS_CORE.md
Outdated
| @@ -111,11 +113,11 @@ Revamping the APIs will make them easier to use and simpler to understand. Using | |||
| - Old APIs are deprecated and removed (e.g. object, block) | |||
| - At least one alternative API exists for JS IPFS (e.g. Graphql) | |||
|
|
|||
| ### `M (P3)`: Support for specific use cases 🔄 🤝 🧠 | |||
| ### `M (P3)`: Increased support for Package Managers, specifically 📦 🤝 | |||
There was a problem hiding this comment.
@alanshaw, @achingbrain, you probably can fold this Milestone into L81 and L93
WG_JS_CORE.md
Outdated
| - Q2 | ||
| - Q3 | ||
| - Q4 | ||
| `TODO` |
There was a problem hiding this comment.
@alanshaw I believe I remember you telling me that this was already done. If so, can you add it here as well?
daviddias
changed the title
License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
There was a problem hiding this comment.
I've pushed to the branch to implement the suggestions and remove some other nice to have things. Do you think that's enough @achingbrain @daviddias?
| - Benchmarks exist to assert that: | ||
| - Memory footprint remains stable and should not consume more than 20% more memory than a Go IPFS node | ||
| - Network throughput is within an acceptable magnitude of Go IPFS | ||
| - Data can be fetched with comparable speeds to tools like bittorrent, wget or rsync when 5 peers are connected who already have the data | ||
| - Data can be exchanged with another IPFS node within 2x the speed a Go IPFS node would exchange it | ||
| - An interoperable DHT exists and scales to hundreds of thousands of nodes | ||
| - JS IPFS nodes can discover one another for specific topics via the rendezvous protocol | ||
| - \*-star servers are no longer in use | ||
| - JS IPFS nodes use, and are compliant with the MDNS spec |
There was a problem hiding this comment.
Moved from deleted milestone "Support for specific use cases"
| - Streaming APIs switch to using async iterators/iterables | ||
| - The files API is revamped: | ||
| - Files functions moved to the root namespace | ||
| - Non-MFS and MFS functions are merged | ||
| - A revamped RESTful HTTP API exists | ||
| - Old APIs are deprecated and removed (e.g. object, block) | ||
| - At least one alternative API exists for JS IPFS (e.g. Graphql) | ||
| - 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 |
There was a problem hiding this comment.
Moved from deleted milestone "Support for specific use cases"
| - Streaming APIs switch to using async iterators/iterables | ||
| - The files API is revamped: | ||
| - Files functions moved to the root namespace | ||
| - Non-MFS and MFS functions are merged | ||
| - A revamped RESTful HTTP API exists | ||
| - Old APIs are deprecated and removed (e.g. object, block) | ||
| - At least one alternative API exists for JS IPFS (e.g. Graphql) |
There was a problem hiding this comment.
This is a nice to have - lets get the APIs we have already in line before we branch out to others.
| - IPFS nodes can discover one another for specific topics via the rendezvous protocol | ||
| -star servers are no longer in use | ||
| - IPFS nodes work and are compliant with the MDNS spec | ||
| - Libp2p discovery and transport modules exist for bluetooth and libdweb, sound and potentially other exotic technologies |
There was a problem hiding this comment.
Dropped this last point - libdweb is now very unlikely to be available to all web extensions (potentially will be available to "blessed" extensions). From the sounds of it bluetooth might be difficult or involve complicated user flows (@vasco-santos might be able to confirm) but either way, exotic discovery methods are a nice to have because they'll reach a much smaller audience than the discovery methods we have already.
| - The JS IPFS build can be customised to exclude functionality or include different modules that are more appropriate for a particular runtime environment | ||
| - At least 2 recommended builds for common environments will be provided in addition to the full build | ||
| - Developers can tailor an IPFS build to their specific needs | ||
| - Full build bundle size is monitored and does not exceed 2MB (minified) | ||
| - Examples for bundling JS IPFS with common tools such as webpack/parcel exist | ||
| - A JS IPFS daemon can run on a Raspberry Pi for at least 1 month | ||
| - Example projects exist for running JS IPFS in a web view on iOS and Android |
|
|
||
| - Default chunkers exist for particular file types to optimise for example deduplication or seeking/direct access in tar archives and video files |
There was a problem hiding this comment.
Dropped this - it's not critical to using IPFS with package managers or being production ready and dropping it gives us scope to improve in the future.
License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
| - IPFS nodes can discover one another for specific topics via the rendezvous protocol | ||
| -star servers are no longer in use | ||
| - IPFS nodes work and are compliant with the MDNS spec | ||
| - Libp2p discovery and transport modules exist for bluetooth and libdweb, sound and potentially other exotic technologies | ||
|
|
||
| ## Timeline |
There was a problem hiding this comment.
@achingbrain @daviddias I've had a go at organising the roadmap milestones and goals into a timeline (below). Please take a look and let me know if it looks sensible - I've tried to leave Q4 with slightly fewer tasks than the preceeding quarters so we have a bit of a buffer for overflow. Q1 is essentially stuff I know is in progress or done.
cc-ing @vasco-santos because I believe gossipsub is on your libp2p roadmap - does that align with when you were hoping to look at it?
There was a problem hiding this comment.
It looks good but there's quite a lot in Q2.
License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
|
question for web support would the JS version or go compiled to wasm version be better? |
|
|
||
| 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. | ||
|
|
||
| - Async/await is used throughout the codebase and callback APIs are dropped | ||
| - Support ArrayBuffer as an alternative to Buffer input argument | ||
| - ArrayBuffer is supported as an alternative to Buffer input argument | ||
| - Streaming APIs switch to using async iterators/iterables | ||
| - The files API is revamped: | ||
| - Files functions moved to the root namespace | ||
| - Non-MFS and MFS functions are merged | ||
| - A revamped RESTful HTTP API exists | ||
| - Old APIs are deprecated and removed (e.g. object, block) |
There was a problem hiding this comment.
Maybe add 'Support the DAG API over http', otherwise we can't really remove the object API.
There was a problem hiding this comment.
I'd like to see the object API being removed, but I think the block API still makes sense even if we have a proper DAG API.
There was a problem hiding this comment.
I’d like to see the Block API stay unless we have another way for developers to grab blocks by some other means and add to IPFS.
|
|
||
| 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. | ||
|
|
||
| - Async/await is used throughout the codebase and callback APIs are dropped | ||
| - Support ArrayBuffer as an alternative to Buffer input argument | ||
| - ArrayBuffer is supported as an alternative to Buffer input argument |
There was a problem hiding this comment.
It'd be good to expand this to support more types so we can use bl to avoid Buffer creation and also some sort of Buffer pool one day.
Would we also not want to support typed arrays (Uint8Array and friends)?
|
|
||
| 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. | ||
|
|
||
| - Async/await is used throughout the codebase and callback APIs are dropped | ||
| - Support ArrayBuffer as an alternative to Buffer input argument | ||
| - ArrayBuffer is supported as an alternative to Buffer input argument | ||
| - Streaming APIs switch to using async iterators/iterables | ||
| - The files API is revamped: | ||
| - Files functions moved to the root namespace | ||
| - Non-MFS and MFS functions are merged | ||
| - A revamped RESTful HTTP API exists |
There was a problem hiding this comment.
It needs some love, but see: https://github.com/ipfs-shipyard/ipfs-http
| - IPFS nodes can discover one another for specific topics via the rendezvous protocol | ||
| -star servers are no longer in use | ||
| - IPFS nodes work and are compliant with the MDNS spec | ||
| - Libp2p discovery and transport modules exist for bluetooth and libdweb, sound and potentially other exotic technologies | ||
|
|
||
| ## Timeline |
There was a problem hiding this comment.
It looks good but there's quite a lot in Q2.
Following #21, this is my first pass/suggestions. @alanshaw, @achingbrain please review.