vision

A command line for the web. Yes, how original? But it doesn’t exist, not really. There is yubnub.org and ubiquity firefox extension (if it still works) and that’s about it.

Well, not exactly. There is also ifttt and other alternatives http://alternativeto.net/software/ifttt/

None of them do what I desire though: an enhanced command line

What is there to enhance?

Here is an example: youtube-dl https://rg3.github.io/youtube-dl/

I like to convert podcast videos to mp3 and put them on my player. I have a sophisticated script for that which:

  • downloads the video using youtube-dl

  • converts them to mp3 using avconv

  • puts them on my mp3 player using rsync

The first 2 parts happen on a remote server because I can download videos much faster than my local computer.

If you go to Zapier, there isn’t a single mention of youtube download or conversion or anything like that. And yet, you go to google, type "youtube" and it’s followed by "downloader" and "to mp3"

This isn’t about youtube-dl however. This is about the panoply of tools and open source software that are:

  1. completely hidden to the average user

  2. often impossible to execute (unless you’re on macosx or linux and know your way around)

  3. developers do not have a source of monetization and no incentive to maintain or enhance the software (other than personal ones)

  4. poor interfaces

The goal

  1. Provide a location where users can access commands and view recipies (like Zapier) for a particular site or software

  2. Provide a clear UI using the web

  3. Rely on the ease of the web for computation and results.

  4. Provide developers a place to publish their software and monetize it (using nanopay)

  5. Easy scripting (ala Zapier) to stitch different tools

  6. Organized / Curated content (unlike yubnub).

No need to install packages, figure out CLI options, configure dotfiles etc. You enter your input, say how you want to transform it and get your output. That’s it.

Competitors

  1. Zapier and alternatives

  2. API marketplaces

API marketplaces have great relationships with developers but rarely any user facing stuff.

Zapier-like companies have great user relations but no developer relations.

I believe Zapier is a greater threat than API marketplaces.

workflows

User input

  1. user enters input (text input, textarea, upload file, other service)

  2. cw input is recognized and list of actions sorted by popular/context/frequency/recent etc.

  3. user can type or speak an action and the search is done recursively.

  4. cw if input is not handled, an attempt is made to find a path and transform an input to something it would take (based on existing patterns, recipies and such)

  5. user picks an action

  6. cw data is transformed into output

  7. output becomes new input and repeat

  8. user can save as script and run it again later with different input

  9. user can reuse script with aliases and hook it into other scripts or share it

specific hooks available e.g if/forEach/unless
value is displayed, progress bar available for long actions

Example by converting my current youtube downloader script:

  1. enter url(s)

  2. cw detects youtube url and offers actions. one them is download to mp4 file but the user could search for mp3 and based on previous recipies, cw would know it needs first to download it as mp4 then pass it to the mp3 converter

  3. select download action and specify what to do with output (where to store it). Different storage options are available (dropbox, ssh (if user added a personal server), s3 etc.)

  4. from "mp4 file output", cw lists other actions of what can be done with it. One of them being convert to mp3

  5. user selects that + picks where to store the mp3

  6. user can save script, bookmark it. cw offers browser extension + mobile app to ease calling scripts and creating new ones

  7. in the background, all actions are provided on the cloud and do specific things

  8. url gets broadcasted to all apis to return a list of available actions (or vice-versa). Developers would register the inputs they can handle and match with their program’s actions. They would also register the type of outputs. That registry is used to find paths and list actions. Registry doesn’t need to be built manually, it can be determined dynamically as well if needed.

  9. url gets passed as JSON api call to youtube-dl which in turns produces a JSON file URL of the stored content

  10. it also produces invoices/bills for consumed bandwidth / resources. again, machine learning can be applied to provide accurate estimates based on previous runs

  11. from the browser, using an extension, when visiting youtube, the user can list saved actions, browse for more or fork them and customize to his needs

Reduce programming plumbing

  1. developer writes a specific program

  2. wants to handle multiple inputs easily without additional plumbing

  3. adds a hook to cw

  4. cw recognizes and transforms user input into desired program input (e.g user input is url but program only accepts file. cw would convert input in background and provide a file.)

  5. developer can do other transformations using API

Monetization open source

Hire

  1. algorithmic specification and broken down

  2. task focused and input/output focused

Programming paradigm/language / future of programming

  1. write programs easily and use API hooks

  2. share them as easily as cw scripts created from a UI