Unite the Files API 🗂

[daviddias]

Important note: This is not an entirely new proposal, it has been discussed several times over the course of the last 9 months in different situations with different views and opinions across the IPFS team. This comes to formalize the process so that we can commit and move it forward :)

Several of our users have been mislead to think of IPFS of File System instead of a Graph Database (fair point that is the name of the project after all:D). This mostly comes from the fact that the cat, get and addcommands come as first order commands and are the ones mostly used by demos.

Now, with the addition of the 'Files API', another layer of complexity and indirection was added. The common reaction to it is "Wait, what is Files API, weren't we adding Files all this time?".

With this, we miss the chance to lead our users to understand what a great Graph Database primitives IPFS offers and we also make it really hard for users to understand what Files API is, specially when it has such a generic name.

So, were is the proposal (this is not just me, although I'm the one writing it) that we've discussed through several points in time.

Rename the Files API to mfs, this will enable us to have one non generic keyword to call it that we can use with our users and also something that the community will be able to search for or aspect specially, since it has very technical details.

Move the cat, get and add commands to under the files umbrela.

In practical terms, this means:

# currently, the file manipulation commands are:
ipfs cat
ipfs get
ipfs add
ipfs files mkdir
ipfs files flush
ipfs files read
ipfs files cp
ipfs files ls
ipfs files stat
ipfs files rm
ipfs files write

Next:

# Manipulation of files
ipfs files cat
ipfs files get
ipfs files add

# mfs - Mutable File System
ipfs mfs mkdir
ipfs mfs flush
ipfs mfs read
ipfs mfs cp
ipfs mfs ls
ipfs mfs stat
ipfs mfs rm
ipfs mfs write

[dignifiedquire]

There is also currently ipfs files ls which needs to be reviewed in this context

[Kubuxu]

Also the names are long established so even if ipfs get was to be moved somewhere else backward support should be provided.

This separation is meaningful from interworks perspective but from user perspective it makes almost no sense. I can say that most of my ipfs command usage is ipfs get, ipfs cat, ipfs add and ipfs ls.

[hackergrrl]

This may also be a signal that the ipfs command is turning into a grab bag for too many abstractions one could build over basic IPFS blocks (object, files, and mfs).

A slightly more radical idea is to break these out into separate commands altogether, and have ipfs be a lightweight core that only manipulates objects (or maybe even just blocks) and we offer other programs to interpret those objects (or blocks) as these various things.

[whyrusleeping]

Action items:

• reference issues from go-ipfs where the decisions for the ipfs files commands were made
• discuss how ipfs add can be unified into the files api by making an entry below the files root -> Unite the Files API 🗂 #98 (comment)
• request feedback from community

[jbenet]

links to take into account:

• Change all mfs references to unixfs kubo#2233 (comment)
• Implement mfs API kubo#1550 (comments, mostly hidden)
• Implement mfs API kubo#1550 (comment)
• implement ipfs files command kubo#1769
• Update help text to avoid confusion of where files can be added from kubo#1826 (comment)
• Fast add stuff kubo#2039

[daviddias]

@whyrusleeping could you elaborate on the point number two: discuss how ipfs add can be unified into the files api by making an entry below the files root, so that everyone can participate in that discussion. Thank you!

[whyrusleeping]

What i was thinking was this:

Every call to ipfs add should make an entry inside the files api namespace, perhaps at /added/<DATE>/filename or /added/<INDEX>/filename. Doing this would accomplish two things:

1. Solve one of our oldest issues: "Where do i see the files i've added?"
2. Make the ipfs add more at home as ipfs files add