You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a whole we currently waste tons of time with package managers and other events around the package lifecycle. It is my belief IPFS could make most of these pain points go away.
Current package maintainer responsibilities
Create package (tar, exe, deb, rpm, ...)
Sign package
Upload package to cloud
Pay cloud provider more money to distribute content and provide more bandwidth
Current way to install a package
Find url of package and correct download for OS
Find signing keys or verification checksum
Verify package
Install package
Upgrade package by repeating step 1-4
We have been doing this package dance for decades and packaging is still difficult.
Is there a better way? Can IPFS solve these problems?
First off, IPFS is a protocol much like HTTP. A protocol designed to delivery bits to the user. IPFS is not a package manager.
But why do we need packages in the first place?
A package provides a single downloadable file
A manifest of the contents in the package
Metadata about package
Ability to sign and validate the package
Why do we need package managers?
Way to query available packages and what is currently installed
Way to add / remove packages
An interface to query packages and contents
A mechanism to unpack a package to a filesystem
Annoying things about packages
OS specific (rpm, deb, msi, brew, yum, apt)
Why can't we have just a single file like Go does?
Where does IPFS fit in?
Some key points to take away is that a package is nothing more than a directory of files with metadata.
A package manager is nothing more than a distribution and retrieval mechanism to get the package.
What I propose
Create a manifest of contents (use ipfs-pack)
Create metadata file to instruct OS how to start and manage itself, version and other things we like see in packages.
Create a way to switch (not upgrade) to different versions of itself (automated or manual)
Add a public signing key so the the program can auto verify it was created by the maintainer and not modified by a evil person.
We could even wrap a few of these commands into a universal removal script, built inside every ipfs "package".
All of this is extremely simple but does require a few things
AIO programs that have no dependencies
Or a helper program to install dependencies via a legacy package manager
IPNS involvement
IPNS could help resolve package names to make them more discoverable and provide "official" programs and libraries to add for dependency resolution.
Auto Install
While could be dangerous maybe just allow official, validated and supported programs.
Mock Idea using IPNS to resolve program
$ xmr
No command 'xmr' found on OS:
Looking for xmr on IPNS...
Found namespace/xmr on QmWcwyqGN323iidjsoiuqhyYdvEvyS9vJ1h1Don96q
Shall I install xmr from IPFS://QmWcwyqGN323iidjsoiuqhyYdvEvyS9vJ1h1Don96q? (Y/N): Y
........ Installed
$ xmr -v
Similarities
like running programs from a shared filesystem such as NFS
Go packaging
Simple for everyone, everywhere
No matter what OS or location a program should be runnable from IPFS without much fuss.
To get this done we just need to build specifications around how things will work and what developers should implement to deliver their programs.
Create a spec for a metadata file
Create docs about how to create a package and lifecycle callbacks (install, remove, upgrade)
Figure out how programs can use IPFS based dependencies and libraries
Start using.
The text was updated successfully, but these errors were encountered:
IPFS packages
As a whole we currently waste tons of time with package managers and other events around the package lifecycle. It is my belief IPFS could make most of these pain points go away.
Current package maintainer responsibilities
Current way to install a package
We have been doing this package dance for decades and packaging is still difficult.
Is there a better way? Can IPFS solve these problems?
First off, IPFS is a protocol much like HTTP. A protocol designed to delivery bits to the user. IPFS is not a package manager.
But why do we need packages in the first place?
Why do we need package managers?
Annoying things about packages
Why can't we have just a single file like Go does?
Where does IPFS fit in?
Some key points to take away is that a package is nothing more than a directory of files with metadata.
A package manager is nothing more than a distribution and retrieval mechanism to get the package.
What I propose
Example "Installation"
We could even wrap a few of these commands into a universal install script, built inside every ipfs "package".
Example "Upgrades"
Upgrades are really just about switching out the unique id
We could even wrap a few of these commands into a universal upgrade script, built inside every ipfs "package".
Example "Removal"
We could even wrap a few of these commands into a universal removal script, built inside every ipfs "package".
All of this is extremely simple but does require a few things
IPNS involvement
IPNS could help resolve package names to make them more discoverable and provide "official" programs and libraries to add for dependency resolution.
Auto Install
While could be dangerous maybe just allow official, validated and supported programs.
Mock Idea using IPNS to resolve program
Similarities
Simple for everyone, everywhere
No matter what OS or location a program should be runnable from IPFS without much fuss.
To get this done we just need to build specifications around how things will work and what developers should implement to deliver their programs.
The text was updated successfully, but these errors were encountered: