Last updated 3 years ago
cardano-cli is cumbersome as transaction complexity grows. Bash scripts (ugly) provide limited editing and documentation capabilities
A high level, declarative, transaction editor that fully integrates with your wallet, cardano-node and your text editor.
This is the total amount allocated to Transaction editor to replace cli.
A high level, declarative, transaction editor that fully integrates with your wallet, cardano-node and your text editor.
Implemented a prototype for spending transactions. Programming since childhood I understand the value of power tools and crafting them.
A command line is the first user interface everybody creates. It is a straightforward text interface that has access to all functions. It is a great starting point to get things done. You can extend it with shell scripts, to help you with common functionality. At that point, despite the increased programmability, you lose flexibility. Programs are sequences of instructions and you must follow the order. The bigger your tasks get the more cumbersome it becomes to use the command line or shell scripts.
You need to rethink the user interface. You move away from the command line and serial instructions into a declarative interface. Start using templates instead of memorizing commands and options. Finally drop the concept of "sequencing instructions".
I want a tool like that. A powerful tool to interact with the cardano-node, which has all the features, does not get cumbersome as you increase the complexity of your tasks, and empowers you as a user.
I couldn't find such a tool, thus I started building it myself. A text editable interface as a wallet for Cardano to create my transactions. A tool that embraces the power of my text editor instead of the limitations of the command line.
Have look at the current prototype
Implementation is on Emacs because, at the moment, it has the richest ecosystem to develop text-editor-based interfaces.
Finally, you don't need to know Emacs to use it. You only need to learn to use the wallet interface. The same way people have learned to use "magit", as a better git interface, without learning to use Emacs. Although, I would argue, learning Emacs is a good thing.
Impact
User interfaces define the usability of a product. It is not enough to provide a tool that does the job, it must enable the user to do the job. The user and the job to be done define the requirements of the user interface. There is never a UX that fits everybody.
The proposed interface is for developers, stake pool operators, and people that need low-level access to the cardano-node. A declarative interface lets you focus on the transaction its context, and not on the tool & the instructions themselves. Thus you skip learning the CLI tool, and only worry about understanding the transactions you work on. The tool provides you with context & templates.
This tool is not about making an "easier", "one-click solution", "beautiful reactive" web interface with colors and buttons for the masses. This tool is for professionals, people that do daily work not one-off tasks. The text interface, embedded in a text editor, provides high flexibility, fine control and straightforward composability.
How many times do you edit your command line instructions in your editor to copy them later to the terminal? And you are still forced to consider linebreak marks and escaping or quoting. You remain constrained by the behavior and one-dimensionality of the command line, even when working from the editor.
Better tools open more possibilities.
Feasibility
Emacs as a text editor has highly developed APIs. Emacs has a very powerful programming language(despite unpopular), to edit text, interact with foreign processes, use foreign modules and do web requests.
I already started prototyping this tool, this proposal is already the second prototype. I first started providing dialogs to select wallets, UTxOs, addresses. I was emulating what many on the internet do with their bash scripts. It was still very cumbersome, it was pipelined, it only works in one way. A task has a flow of actions, and like many bash scripts, I find doing a mistake requires canceling and starting all over again.
The insight came when working on the continuous integration configuration. You declare things, you move a level higher, from actions to tasks. You can always review, change your mind, and edit. Because there are no actions or instructions, there is no intermediate state, there are only end goals. What the transaction should look like is what the interface must look like.
The prototype works and I like the workflow it provides. Wrapping a command-line interface is a common task to do in Emacs. The cardano-cli is a moving target and care needs to be taken to still create a flexible wrapper that supports updates on the CLI tool.
Wrapping the commands to use Plutus scripts is also simple. Yet, I still iterate on the design of that interface. A database of Data and Datumhashes. A store of contracts. A translator of the Haskell isData type into the JSON values or typed JSON files is still on the design works.
Wrapping the cardano-cli is simple because it is a stand-alone binary to execute. Integrating with cardano-wallet is more challenging, as it is a service that must be running and requires a configuration of its own. I will work on that during the implementation of this project. Not all problems are solved at the outset of this proposal, which would already imply a finished product.
Auditability
The rate of work is a part-time occupation. Weekly sprints of 3 workdays(Fri, Sat, Sun) (I do work part-time in my main occupation). This spaced work is very beneficial, as it gives time for the community of users to test the tool and deliver feedback. It also helps me as a developer to gather ideas over the week, while thinking about other tasks. This influences thought, rest, and openness.
Every week, the sprint starts on Fridays with community feedback review and planning of tasks. The development follows until the end of Saturday. Sunday is reviews and reports day. Completed features are documented in a newsletter form and posted on the Cardano forum. These features are documented as part of the Handbook of the tool. A demo video is recorded, edited, and posted online(on YouTube). Yes, a full day of work is dedicated to communication. New Features are important, but getting them into the hands of users is what counts. People, even technical ones, read more tutorials and documentation than the actual source code.
Auditability is not measured on the public commits to the repo, but in people using the tool. Replying to posts to the forum, engaging. Community participation keeps accountability high too.
Timeline and Budget
Everyone has a plan until they get punched in the face -- Mike Tyson.
560 USD Cloud Infrastructure 12 months. Includes Continuous Integration & build servers. VPS to run cardano-nodes on mainnet, public testnet, and some private testnet clusters for testing. This infrastructure budget, extends duration of project to allow the growth test of the tool.
I propose an 11 Week action plan, based on my current prototyping rate. I already invested 3 weekends crafting the transaction editor for multi-input/multi-output transactions and extended the capabilities to work with Plutus contracts.
Most software development is unpredictable and has little to do with the task at hand. It always requires investigating and solving problems related to dependencies. It all takes time.
This 11-week plan at a work rate of 3 days of work, and a developer compensation average of 60USD/hour. It includes technical documentation writing, forum post updates, and video editing.
Measurable goals:
Vision of success:
Outlook for future work in later Catalyst Funds
My experience
Recently involved with Cardano. Plutus pioneer first cohort "Completed/Survived/Graduated". Awarded NFT 117 of class photo, Titan-C
See for example my pull request and issues to IOHK repos.
That is part of parallel work done while developing the transaction editor.
Released Emacs projects.
Most successful Open-Source project
Currently employed to develop for checkmk (https://github.com/tribe29/checkmk). My work range from tools to analyze monitoring data, to the user interface. Always with a direct dialog to customers.
I hold a Ph.D. in Theoretical Physics developing simulations for correlated electrons systems.
Everything summarizes into: I'm a tool builder. I build the tools I need to get the job done.
Find me on the internet:
Implemented a prototype for spending transactions. Programming since childhood I understand the value of power tools and crafting them.