Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application: AIO programs run from IPFS #39

Open
logicminds opened this issue Oct 24, 2018 · 0 comments
Open

Application: AIO programs run from IPFS #39

logicminds opened this issue Oct 24, 2018 · 0 comments

Comments

@logicminds
Copy link

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

  1. Create package (tar, exe, deb, rpm, ...)
  2. Sign package
  3. Upload package to cloud
  4. Pay cloud provider more money to distribute content and provide more bandwidth

Current way to install a package

  1. Find url of package and correct download for OS
  2. Find signing keys or verification checksum
  3. Verify package
  4. Install package
  5. 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?

  1. A package provides a single downloadable file
  2. A manifest of the contents in the package
  3. Metadata about package
  4. Ability to sign and validate the package

Why do we need package managers?

  1. Way to query available packages and what is currently installed
  2. Way to add / remove packages
  3. An interface to query packages and contents
  4. A mechanism to unpack a package to a filesystem

Annoying things about packages

  1. 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

  1. Create a manifest of contents (use ipfs-pack)
  2. Create metadata file to instruct OS how to start and manage itself, version and other things we like see in packages.
  3. Create a way to switch (not upgrade) to different versions of itself (automated or manual)
  4. 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.
  5. Run the program directly from IPFS

Example "Installation"

ipfs get QmWcwyqGNiqokiii321XuqhyYdvEvyS9vJ1h1Don86q -o /opt/ipfs_programs/xmr-stak
ipfs pin add QmWcwyqGNiqokiii321XuqhyYdvEvyS9vJ1h1Don86q
ln -nfs  /opt/ipfs_programs/xmr-stak/run /usr/bin/xmr-stak
xmr-stak -v 

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

ipfs pin rm QmWcwyqGNiqokiii321XuqhyYdvEvyS9vJ1h1Don86q
rm -rf  /opt/ipfs_programs/xmr-stak
ipfs get Qm1cwyqGNiqokiii321XuqhyYdvEvyS9vJ1h1Don86q -o /opt/ipfs_programs/xmr-stak
ipfs pin add QmWcwyqGNiqokiii321XuqhyYdvEvyS9vJ1h1Don86q
ln -nfs  /opt/ipfs_programs/xmr-stak/run /usr/bin/xmr-stak
xmr-stak -v 

We could even wrap a few of these commands into a universal upgrade script, built inside every ipfs "package".

Example "Removal"

ipfs pin rm QmWcwyqGNiqokiii321XuqhyYdvEvyS9vJ1h1Don86q
rm -rf  /opt/ipfs_programs/xmr-stak
rm -f /user/bin/xmr-stak

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

  1. AIO programs that have no dependencies
  2. 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.

  1. Create a spec for a metadata file
  2. Create docs about how to create a package and lifecycle callbacks (install, remove, upgrade)
  3. Figure out how programs can use IPFS based dependencies and libraries
  4. Start using.
@hsanjuan hsanjuan transferred this issue from ipfs/ipfs Mar 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant