API variations comparing go vs js versions

[MasterJames]

I noticed some variations of the API comparing the videos and I guess it's the go lang version to this js-ipfs version. For example... Typing just jsipfs reports various possible commands

...
files add                 Add a file to IPFS using the UnixFS data format
files cat                 Download IPFS objects
files get                 Download IPFS objects
...

while add, cat and get are not prefixed with files in the regular version. same with files being called file, or is that file being called files here vs there.

Leads one to question what the WebGUI API follows etc.?

Is it not suppose to follow the existing API? What's happening there?

Maybe there's a plan to use this API instead, like its some experimental exploration dev version? https://youtu.be/h73bd9b5pPA?t=4746

Maybe it's a typo with file(s) and it's missing add & cat aliases? Maybe there will be both file and files? not that that won't be too confusing.

I thought to mention how the MikroTik RouterOS uses a '/' slash prefix with commands and then they are relative path (if no prefix slash on subsequent commands). It's not very unixy but an interesting thought. More so when thinking about how code and DAG folders could possibly work this way in a relative folder-check for commands like some CLIs do. An executable search through current/working folder/directory/dag before going to the official shell's 'path' (config setting?) or parents etc. I do this when searching for database keys so one can have a default folder as well as in the parent, but that's another story/idea to think about. [ Add the idea of a best match key search, example: w matches width, if only width and height found, if not found check parent and/or default folder for possible matches. Kind of a regex but probably faster dictionary (aka js object) key search, as only w is needed to match width and the entire key's length doesn't need pairing-off/matching. Again better for another suggestion posting later, maybe. ] This is what I've been thinking too https://youtu.be/h73bd9b5pPA?t=4784 inject above idea into those conversations.

[daviddias]

There is a proposal open on https://github.com/ipfs/specs/issues/98

meanwhile, we intent to support both (ipfs.files.cat and ipfs.cat) https://github.com/ipfs/interface-ipfs-core

[MasterJames]

Yes thanks @diasdavid I'm starting to see that clearer now thanks for the comment and links.