Certainly, this project has taken way too long for delivery. I had to reconsider its design many times. It went from an ambitious self-sovereign goal of hosting all infrastructure to leveraging your current web wallet for all your interactions with the blockchain. Today with many wallet options, it seems a better choice and I can focus on my particular goal.

TL;DR: The editor is finally out, it has still many rough edges but you can try it with your favorite wallet. Find the link in this post or from the project page.

Just let me give it a try!

Why did it all change in such a way?

Running your node is nowadays easy, there are lots of tutorials to set it up. That is how cardano.el expects you to start, with your node. Querying your node takes some time, but for your personal use is tolerable. Offering direct queries to your node as a service doesn’t work. The node is there to participate in the network consensus not to be a data service provider, it is not performant enough for that task.

Thus a new indirection becomes necessary, using cardano-db-sync was initially the only option, however keeping it running was a challenging project, and even worse giving it maintenance and dealing with its large resource consumption proved to be just too time-consuming for a team of one. Participating in the Vasil Hard Fork testing was a huge time consumer that kept me busy on infrastructure tasks and hindered me to work on my actual service.

Another bad choice was to craft the transactions still over the cardano-cli, I could port a lot of cardano.el instructions to build that on the backend. Yet that is above all a huge security risk, I would be opening shell access on the backend just to call the cardano-cli. Thus, I had to tame it down, how about just returning to you all the instructions and letting you execute them on your computer? Yes, it works but destroys the convenience of this tool. You would end up running your node again, because cardano-cli validates the transaction and in that case, I recommend you to use cardano.el.

Bringing these responsibilities back to the user, although they bring a lot of digital self-sovereignty to the user, turns out to be a pain for everybody. The user would need to have his node and then install even more software to connect from the browser to their local node. Yes it’s possible, you can use native messaging for it, but it is still a lot to set up for the user, and that he needs to be aware of giving maintenance. On my side I can’t give support to the user, I can’t push updates because all the components are infrastructure that I do not control. The entire mantra of web applications is: “It just works”. I can’t burden users with much setup, and I can’t burden myself expecting them to perform their updates correctly and on time. The application must run on infrastructure which the service provider controls. I do await for the day that the web browser will become an Operating System itself and allow applications to install themselves in a sand-boxed way on the browser, using a better language instead of JavaScript and pushing the computing to the end user instead of keeping it in the cloud, but that day is not today.

After all that trouble, the user is still responsible for key management and signing the transaction. That crucial step was never the responsibility of the editor, but if it doesn’t offer that convenience nobody will use it. I was still leaving that responsibility to the user, who would need again to use the cardano-cli. All the initial designs and intentions were wrong from the start. Inappropriate for open public service. Anyone that needs power and self-sovereignty ought to run his node and use cardano.el, but for everything else a web wallet must self-contain all features for the sake of convenience. There is no way in between.

Should I make a web wallet?

At some point, but now it is out of my current time and financial possibilities, my catalyst funding is already over-budget and over-time, and a wallet was never in scope. Yet I still have to deliver my project, allow people without a node to craft a transaction and submit it to the blockchain, mint a token and distribute it, and finally do a cooperative coin-join. All those tasks are already available for proficient users of cardano.el, yet they still require a lot of infrastructure for web wallet users because as stated before, cardano.el can’t be the backend of this service. cardano.el is a user-space application.

Which is then the way out?

Cardano is a growing ecosystem and it has a lot more to offer today, than when I started this project. Many teams are working on their particular use case, and their offering and if innovation is to be permissionless, we should be able to leverage the work from each other. Building a web wallet is out of scope for me, but now there are many to choose from, with well-funded and larger teams who took up that task. Pick the one that fits your style, security, and trust requirements. Some wallet creators have done it wonderfully, I will integrate with them, you as the user can verify my work over your trusted wallet and only sign transactions that you want.

What comes next?

The path is a lot easier if I leverage web wallets. I must even say when reviewing wallets that the team creating Eternl has done a great job, they even have their transaction editor, and it looks great. Now I’m lagging as a single developer against a larger and highly funded team. Yet with my current focus I’ll open up transaction crafting to everyone, to all wallets and you can try it out today.

Finally, the MVP is out. It is a web app. It is inside arsmagna, but a bit hard to find, you need to click your way from this blog post or the project description link. As it grows it will also gain a large presence here and simpler access.

Give it a try today, pick on your wallet the testnet and have fun. If you want, use the mainnet too, after all, it is in your wallet that you can audit the transaction, where you sign it, and submit it. As popular as Nami Wallet is, I would discourage it because you can’t see the transaction you are signing, Eternl, Flint, Typhon do a much better job.

How does it compare to Eternl’s TxBuilder?

I’m lagging. They are a complete wallet and can do coin selection for you. You can also add metadata to the transaction. Finally, they have tighter control of your input and correspondingly better error messages. In many cases, the errors for my transaction editor only show on the JavaScript console, not on the main interface.

That is three features behind, but I can regain parity with them, error messages are a particular priority to me. Finally, there is the design, it is a matter of taste, theirs is consistent with their wallet mine is minimalist and information-dense, there are no popping-up dialog boxes to narrow your focus, everything is on screen. I’m happy to listen to your feedback on how to improve the design.

What comes next?

The goals are still the same:

  • Token mint with metadata
  • Cooperative coin-join

The first one is not too complicated, if you take the responsibility of correctly registering your tokens and shall they have some multimedia you make that internet available yourself. The editor at the moment will only help you with the minting transaction.

Cooperative Coin-join, that one is a lot harder, because I need to solve how you can share transactions with other people, and how to partially sign transactions, as web wallets assume you are the only one spending the inputs, there is no clear notion for combined transactions and even worse they are not yet prepared for multisig transactions. I will have to push some extra clever tricks into the editor to make that happen.

Conclusion

The editor is finally out, give it a try! It has still many rough edges but you can try it with your favorite wallet. Share your feedback and I’ll make it get better.