Rotki's New Year Resolutions

Introduction

As 2019 draws to a close, a lot of users have been asking us when will certain features be implemented, which features are in the pipeline and generally what’s the roadmap for the future of Rotki as an application. This short post attempts to serve as a go-to answer for these questions, clarify the short-term roadmap and give some hints on what will come in the long-term future.

Short term

Very recently we have created a develop branch in Rotki in order to facilitate all the big breaking changes that are coming. All PRs by default will now be done against develop and thus all big changes that need to be done will stay in that branch. Once a release is done, develop will merge to master and binaries will be published. PRs against master will be reserved for quick patch fixes that can be done independently of any breaking changes in develop.

The next release coming out of will be v1.1.0 and it will contain, among other things, two major features.

Release v1.1.0

Modern UI

The entire UI is being rewritten and turned from the old-school hand-made CSS + bootstrap abominaton to a proper modern framework thanks to the tireless work done by kelsos. At the time of writing this post the work is almost done and the PR is about to be merged.

What does the average user care you may ask? By far the most important advantage of this change is that adding new UI components and thus features will become much easier. Vue.js is a modular framework which makes it trivial to add new components or modify the looks of the UI. In short adding new features is now going to be made easier. God knows there is a lot in the pipeline that needs to be implemented!

Apart from that the looks of the entire app are getting modernized. All components are now more sleek and pleasing to the eye. For example here is the ethereum token selection.

Proper REST API

The current version of Rotki uses the ZMQ protocol in order for the front-end (UI) to communicate with the backend. The API developed for that communication was crude but what’s worse ZMQ libraries for both python and javascript are not kept up to date and are pulling very old dependencies. The ZMQ library is why rotki is stuck in an old version of electron and also why we maintain our own fork of an abandoned node project, the node-zerorpc client.

The entire ZMQ messaging layer is getting rooted out and replaced by a proper REST API.

What does the average user care about this you may ask? Higher electron versions allow us to have more security in the application and take advantage of all the new electron features. Also with ZMQ no longer being a dependency, a very big and fat dependency is out and final binaries would probably be smaller in size.

But more importantly this opens up the way to be able to run Rotki in a headless machine and communicate with it only via the API. That would also enable you to run rotki’s backend in a different machine than the UI.

Finally with this change Rotki will be getting a very good, well documented and tested REST API. Users will now also be able to work with Rotki via command line interfaces. Below is a screenshot of the docs in the work in progress PR that implements the ZMQ to REST API switch.

When?

When it’s ready. Soon ™.

Other releases after v1.1.0

The next big feature planned after that is implementation of support for Coinbase PRO which should hit in the release right after v1.1.0, presumably v1.2.0.

Apart from that there is a lot of issues and feature requests in the backlog that should be handled. Priority will go to supporting new exchanges such as Bitstamp and generally fulfilling user’s wishes such as support for staking in PoS cryptocurrencies.

What would you like to see in the near future implemented in Rotki? Don’t be shy, join us and write up a feature request as a github issue here.

How can I follow the evolution of the roadmap?

As an opensource application, transparency is in the core of Rotki’s ethos. As of the writing of this post our milestones are tracked by Github projects. You can see the current milestones here and inspect which features will be implemented and which bugs will be fixed in which releases.

The current milestones are:

  • Next patch release: Small issues that may pop up and need quick fixes go here. Patch releases are made if required to make quick fixes to an already existing release.
  • Next minor release (currently v1.1.0): Most of the current development always targets the next minor release. All new features that are going to be included in the next release end up going there.
  • Minor release after the next (currently v1.2.0): This is where features that are planned for development go but which we know will not be included in the next minor (feature) release.

Long term

The long term vision for Rotki is for it to become the best portfolio management, tracking and accounting application for both crypto and traditional assets. The tool that not only enables you to manage your finances but also does this in an opensource, transparent way allowing you to own your financial data and not have them lying on a centralized server somewhere in the cloud ready to fall into the hands of malicious actors.

In an ideal future it would also be able to track not only one’s investments but also everyday expenses and provide insight and analytics about the entire spectrum of a user’s finances.

There are no specific Github issues made yet for the various things that we are thinking about the long-term future but as a general idea:

  • Rotki should be able to track traditional assets such as stocks, bonds, real estate and so on.
  • Rotki should be able to manage a user’s daily expenses and provide insights and analytics into spending habits, savings and so on.
  • Users of Rotki should be able to track part of their expenses while on the move so a companion mobile app to Rotki desktop should be made.

What else would you like to see implemented in the long run in Rotki? What would you require from an application that is supposed to be the constant and trusted companion to all your financial analysis needs?

Naturally all the above largely depend on how the current userbase of Rotki grows and how succesfull is the monetization of the application. Without any steady revenue stream or funding all of the above are probably really hard to accomplish.

Conclusion

The future of Rotki is bright! There is a lot of demand in the form of feature requests, and the userbase is steadily increasing. Stay tuned for more updates and please help us in building the best transparent financial tool that enables you to take ownership of your data. Ways to do that are:

  • Try out Rotki’s latest release.
  • Provide us with feedback in the form of bug reports and feature requests.
  • Star our Github repo and follow us in Twitter.
  • Buy a premium subscription and/or support us financially.
  • Spread the word so that more people get to try and use Rotki and learn how to both manage their finances but also how to protect the privacy of their financial data.

Why creating a new asset in an immutable ledger should not reuse an old name

Introduction

Yesterday MakerDAO reached a very important milestone. It introduced a new type of DAI stablecoin that can have multiple underlying assets used for collateral as opposed to the old DAI which could only be supported by collateralizing ETH.

Unfortunately at the same time they decided that they were so attached to the name DAI that they wanted to give the same name to the new token. And they could only do this by renaming the old token. Which is exactly what MakerDAO went with as you can see here.

This post is going to explain in detail why from a user’s or an application’s perspective the decision to change the name is quite bluntly put idiotic. Renaming DAI to SAI has zero advantages and introduces a long list of problems as seen below.

Problems introduced by renaming

In this section we will see a writeup of all the problems that the renaming is introducing along with a short explanation for each one.

Token Symbol

A contract deployed in the Ethereum blockchain is immutable. The DAI contract is here. If you try to read the symbol attribute it will be DAI. The symbol attribute is part of the ERC20 interface and ignoring it breaks that interface. You can not arbitrarily decide to now call the token by a different name (SAI) while the symbol of the token is DAI.

Centralized Exchanges

Right now centralized exchanges are in a tough spot. They have to perform DAI to MCDAI upgrades for their users and then decide on how to name the new assets. If an exchange intends to keep both tokens listed then the naming becomes a problem.

In the end the problem is pushed to the users as can be seen from above. For users SAI is DAI but if as a user you attempt to deposit what you think is DAI to Kraken you will lose it. If that does not constitute a UX nightmare I honestly do not know what does.

Decentralized Exchanges

Decentralized exchanges do not have much of a choice. They do not hold the tokens for their users so they will not be able to automatically upgrade DAI for them. They need to offer trades in both tokens and then the naming does indeed become a problem.

Software libraries

Software needs to be making assumptions for some basic things. One of these assumptions that software in our field make is on the immutability of contracts and by extension the token contract symbols.

Software libraries that made correct assumptions in the past will now break. As an example, one of the most used javascript libraries in crypto UI applications is cryptocurrency-icons. It pulls icons for crypto assets based on the symbol name.

At the moment, the DAI symbol returns the old logo of DAI and the SAI symbol will return an error. All projects using this library (and it’s a lot) will have to update whenever a new version comes out. At the moment there is no version supporting the new naming so all projects using it are displaying the wrong icons.

External APIS

A lot of APIs, for example price feeds such as cryptocompare have had DAI listed. Now they need to update their APIs in order to point DAI to the price of the new multicollateral DAI and create a new entry for the SAI token which points to the old DAI price. And that is hoping that there is no other cryptocurrency with the SAI symbol. I am pretty sure not every one of these price feeds will follow the new naming and then end-user applications will have to maintain converters between different price feeds using different symbols. It’s a mess.

End user applications

Every single end-user application that deals with crypto and DAI has to adjust. As an example we can take Rotki. If we go with renaming DAI to SAI we have to create a new release that will upgrade the user’s databases renaming the assets and rewritting history. If we do not we will confuse our users.

What is the solution?

At this point nothing can be done. The renaming has to go through since it has already started. But due to all the reasons outlined above it was a terrible decision.

The proper solution would have been a very simple one. DAI stays as DAI and is the symbol of the single collateral DAI. And then the new multi-collateral token is called MCDAI or well … anything other than the same name as the previous token.

Conclusion

Despite all the problems with the renaming the achievement of having a multicollateral DAI is something to be proud of.

All of the above problems in isolation do not sound really bad but if you sum them all up it ends up as a nightmare for all actors involved. It’s a mess for application developers, a mess for users and a mess for service providers. And all of these could have been avoided by simply doing the obvious thing and providing a new name for a new token!

For Rotki a blog post will follow explaining how we will handle the switch from SAI to DAI and how it will be reflected in the databases of our users. If you liked this post and have not tried Rotki yet you can get the latest release from here. By using Rotki you can take ownership of your financial data! Please try it out and provide us with feedback so that the software can improve.

Rebranding to Rotki

Why rebrand?

Since launching v1.0 of the Rotkehlchen application a common theme on feedback was that it’s a nice app with a definitive use case but people simply can not spell and much less pronounce the name.

No matter the attachment to the name rebranding becomes very important when people can not write down the name of the project to recommend it to their friends or can not even google it successfuly. Projects like Rotki live and die from word of mouth so everything that can be done to facilitate it should be done.

To that end as of right now the project name has been rebranded to Rotki.

What has changed?

  • The github repo has been moved from rotkehlchenio/rotkehlchen to https://github.com/rotki/rotki.
  • We got a new domain name and the entire website can now be found at rotki.com. Same applies for the blog and the api under the equivalent subdomains.
  • All @rotkehlchen.io emails now have @rotki.com equivalents.
  • The twitter handle was renamed from rotkehlchenio to rotkiapp
  • The documentation was moved to https://rotki.readthedocs.io/en/latest/.
  • We now own the rotki.eth ethereum ENS name and it points to the ethereum donation address for the project.

The old rotkehlchen.io domain name is still ours and will keep working for at least 1 more year.

Thank you

Thank you for your continued support! It is only through feedback from our users that Rotki can become a better tool that will enable you to take ownership of your financial data.

If you see any remaining places where the name needs to be changed just let us know via Twitter and we will get to it.

If you haven’t done so yet please download the latest Release for your OS, try Rotki out and give us feedback on what you would like to see improved.