Asks from other WGs

[achingbrain]

Being a list of features/requirements from different groups within Protocol Labs required to support the Package Managers usecase.

What is the Package Managers use case?

Our goal is to encourage package manager maintainers to adopt IPFS as a first-class transport mechanism alongside http, and to produce tools and apps that expose interested users to our tech stack and make happens within the network more transparent.

This will have the effect of massively driving adoption of IPFS and greatly increasing it's visbility to developers who are our early adopters.

Further discussion on this can be found in The Package Managers Use Case

Requirements

Items in this section should represent how we'd use IPFS and supporting technologies to solve problems presented in Problems with Package Managers

Speed

• Adding package manager meta data & binaries to IPFS and/or otherwise calculating CIDs for packages needs to be faster. Similar in speed to rsync.
• Retrieving packages via IPFS needs to be much faster
  • Within an order of magnitude of HTTP if there are no other copies on the local network
  • Comparable to HTTP with 1-10 copies on the local network
  • Faster than HTTP with 10+ copies on the local network

For sample datasets & observed performance, see the Experiments @andrew has been conducting.

Documentation

• Primer for registry maintainers that makes the case for IPFS simply & effectively
• Example use cases relevant to package managers
• Onboarding for new uers
• Howtos on handling massive data sets (e.g. repo types, optimisation flags, etc)
• Common gotchas

Support

• More effective and engaged help for users who are not experts in IPFS (e.g. pretty much all package manager maintainers)

Data longevity

• IPNS names need to live beyond the publishing node going offline
  • Graphs-with-friends - nominate PeerIDs as 'trusted', replicate their CIDs & IPNS names?

UI support

• Add UI to npm-on-ipfs and other package manager experiments that we wish to keep around & for people to use as learning tools
• A system tray type UI to give you stats on local use of npm-on-ipfs/gx/other IPFS based package managers

Features

• Permissions in UnixFS - obviously users/groups don't make much sense but knowing which files should be executable when mounting MFS on FUSE would be a big win
• "Polite" profiles so you can keep a daemon running without torching your battery

[andrew]

Feature:

• Storing mod times in UnixFS would be helpful for re-adding files that have changed when using the filestore

[jchris]

I started searching about "nominate PeerIDs as 'trusted', replicate their CIDs & IPNS names?" and found related discussion. Will this also enable file pinning services to pin names? That's useful for web dev, as it enables using ipns with dnslink in a serverless way. I ran into issues like those described at the end of https://www.ctrl.blog/entry/dnslink-ipns-top1m-websites and discussed in https://github.com/ipfs/go-ipfs/issues/1467 and I'm guessing it's a common hurdle.

[momack2]

@jchris - are you thinking of something like delegated IPNS record republishing (https://github.com/ipfs/go-ipfs/issues/1958)? AFAIK from https://github.com/ipfs/go-ipfs/issues/1467 you can already pin names...

[jchris]

Those are similar issues, I don't think the use case I'm thinking of works seamlessly yet:

1. You ask a pinning service to host a directory on IPFS.
2. You create a ipns record for that directory
3. You publish that ipns record via dnslink
4. You close your laptop and eventually the ipns record expires, rendering your content inaccessible.

These steps are advocated in posts like https://medium.com/textileio/the-definitive-guide-to-publishing-content-on-ipfs-ipns-dfe751f1e8d0 so I bet a lot of first time users have dead ipns dnslinks floating around (the quick workaround being to put ipfs names in your dnslink).

Fixing 4 seems like it would take https://github.com/ipfs/go-ipfs/issues/1958 but also something to handle republishing after the record expires. Delegated authority could allow a pinning service to do this. I think this same mechanism will be useful for package authors to point to latest releases, in a way that package hosts can serve robustly.