Crypto alias comparison — OpenCAP vs OpenAlias
Disclaimer: I’m one of the original developers that worked on OpenCAP. We used OpenAlias as a springboard to start development of OpenCAP and build on the ideas started there. As such, this will be a biased review but I will do my best to represent the differences in a fair light.
What is a cryptocurrency alias system?
In this context, an alias is a way of representing a cryptocurrency address in a more friendly way. A typical bitcoin address is long and hard to recognize:
1DxBaADfhTSWsevbzDghrhKSqQwsBpuM5A
Instead of using this obscure address directly, an alias represents it as follows:
OpenCAP: username$website.com
OpenAlias: username.website.com OR username@website.com
Format Differences
Immediately we can see that there is a difference in how aliases are represented between the two systems. I didn’t work on OpenAlias personally so I can’t give justifications for the format.
With OpenCAP we decided that we didn’t want to use the “@” symbol because aliases could be confused with email addresses. People may try to send money to email addresses or email to aliases.
We also didn’t want to use the “.” (period) because we wanted people to be able to use usernames that contain periods, as well as subdomains. For instance, I could have the alias
lane.wagner$alias.bitcoin.org
If we used periods we wouldn’t know where the username ends and the domain begins:
lane.wagner.alias.bitcoin.org
Differences for the Server — Datastore
In both the OpenCAP and OpenAlias models, address data is stored on servers. There isn’t one server that stores everything (centralized) but anyone can create their own server that hosts their aliases (decentralized).
OpenCAP only specifies a web API, or in other words, the way that addresses will be retrieved and updated. As such, any database can be used which fits the purposes of the server’s owner.
OpenAlias stores addresses in DNS records (TXT records). This means that to have your own OpenAlias domain (and associated addresses) you will probably use a DNS server owned by a third party (cloudfront, route53, bluehost, etc) This means that those providers can have their own record limits and restrictions, which is something we saw as potentially limiting the OpenAlias system.
DNS servers (OpenAlias) are configured to be updated infrequently but read from often. This works well for cryptocurrencies like nano or monero where you don’t need to change your address often, but isn’t as elegant a solution for Bitcoin where new addresses should be used for each transaction. OpenCAP can support systems that potentially create new addresses many times per second in order to preserve privacy.
Because OpenCAP doesn’t specify a datastore, developers can do what they please and develop how they want. It also make some features possible with OpenCAP that are impossible with OpenAlias. For instance, maybe I want my OpenCAP server to guarantee that a new a unique address is returned for each request for privacy reasons. This is impossible with OpenAlias but simple with OpenCAP.
Differences for the Wallets
Querying addresses using OpenAlias is a DNS TXT record lookup. This is a simple procedure that most front-end developers can figure out quickly.
Querying addresses using OpenCAP consists of 2 steps.
1. A DNS SRV lookup to find the host server’s domain name
2. A REST API call to get the address from the host server
SRV record lookups are similar to TXT record lookups so that step is near identical. The REST API call is the easiest way for a developer to query data, REST API’s are standard in the modern web.
The purpose of the SRV lookup is that it provides another feature to OpenCAP, the ability to host multiple alias domains all from the same server. For instance the aliases lane$website.com, donate$ogdolo.com, and bob$google.com could all be hosted from the same server, similar to how you can have an email “username@mybusiness.com” all hosted on gmail.
With OpenAlias only the owner of the domain can manage the aliases directly.
Security
OpenAlias and OpenCAP have roughly the same security levels. Both depend on DNS security, which can greatly be enhanced by DNSSEC. Both systems also rely on trusting the owner of the server (which could be yourself, because you can run your own server)
Conclusion
We developed OpenCAP because we love the idea of aliases but felt that OpenAlias wasn’t getting the adoption we felt it should. After trying to figure out why, our theory was that it was just too complex to create an app that manages OpenAlias aliases, and by extension there weren’t many developers using the protocol. I hope I haven’t misrepresented OpenAlias at all in this review. I wasn’t in on the development conversations for the protocol so if I have slipped up please let me know!
Free-to-use OpenCAP hosting: https://ogdolo.com/
OpenCAP protocol: https://github.com/opencap/protocol
OpenAlias: https://openalias.org/
