A Discussion With the Prolific Bitcoin Developer Unwriter

This week news.Bitcoin.com spoke with one of the most prolific developers working with the Bitcoin Cash (BCH) network. Over the past few months, the developer Unwriter has created a large swathe of censorship-resistant applications that are tethered to the BCH blockchain. We decided to get an inside glimpse of all the interesting platforms Unwriter has been launching, and the programmer tells us why they were conceived and how they operate.    

Also read: No Matter How You Slice It — Token Assets Are Coming to Bitcoin Cash

So far the programmer Unwriter has launched platforms such as Chainfeed, a Twitter bot called @_Opreturn, Read.cash, the Bitdb.network, and a few more applications that are compatible with the BCH chain. Moreover, Unwriter has also been collaborating with five other well-known Bitcoin developers and contributed to the working paper called ‘The Simple Ledger Protocol,’ a concept that aims to create representative assets using the Bitcoin Cash network. With so many projects under this developer’s belt, we decided to chat with Unwriter in order to get some perspective on some of these unique applications.

Unwriter Has Launched a Flurry of Censorship Resistant Applications

News.Bitcoin.com (BC): Can you tell us about the first three applications you created?

Unwriter: Chainfeed.org is the first application I created on BCH. Chainfeed is a web app that delivers the full firehose of real-time Bitcoin OP_RETURN transactions. It’s pretty mesmerizing to keep the site open and watch as messages flow in, especially now that there’s more variety in the types of apps being built on OP_RETURNs. Immediately after I released Chainfeed people started asking for an API, and soon I released the Chainfeed Firehose API. Now anyone with programming skills could hook into the real-time Bitcoin OP_RETURN feed with just a single function call.

Chainfeed.org

To demonstrate the Chainfeed API I built a Twitter bot called @_Opreturn. The @_opreturn account auto-replicates OP_RETURN transactions to Twitter via the Chainfeed API, effectively creating a portal from the Bitcoin world to the “real world”. Currently, it imports content from Memo.cash, blockpress, and Matter, a long-form blogging tool on the blockchain. But it may incorporate other apps in the future whenever it makes sense, pull requests and suggestions are welcome. It’s open sourced on Github so anyone can just fork it and build their own custom bot too.

The Twitter bot @_Opreturn

Read.cash was a project I spontaneously built one afternoon because I needed it myself. A lot of Bitcoin-powered apps nowadays have their own built-in wallets to provide a better user experience. You can see this in apps like Memo.cash and Yours.org. Whenever you receive money through these apps, you end up with separate wallets each tied to its parent application website. As I started playing around with these apps, I felt the need to keep track of all of these wallets in one place so I have a comprehensive view of how much money I’m making in total. And that’s what Read.cash does. It’s a read-only monitor that aggregates balances from all your wallets across the web and lets you keep track of them easily in one place.

Read.cash

You can add as many public Bitcoin addresses as you want and it doesn’t even require you to add any private key or anything, it’s 100 percent powered by public bitcoin addresses and the site is completely open source so there’s no security risk. Also, with the Money Button integration, you can even charge all your wallets in one place with one click. Some of the future improvements would be incorporating Tipbots like Tippr or Chaintip. Currently, they don’t provide a public access to user addresses so you can’t add them to Read.cash, but I heard some of them are thinking about it, so I’m looking forward to that day.

BC: Just recently you launched the Bitdb.network can you tell our readers about this project and what it can do?

Unwriter: Bitdb is a global NoSQL database backed by Bitcoin and implemented with MongoDB. Bitcoin’s blockchain is the perfect data structure to function as the single source of truth, but it’s not at all designed to facilitate flexible queries. And obviously, this is essential if you want to build any sophisticated app. Bitdb complements Bitcoin by taking all the OP_RETURN transactions on Bitcoin and creating a public MongoDB index that makes it hyper-queryable. This way you can build all kinds of apps easily which used to take months to build because all you need to focus on now are the protocol design and the frontend implementation. You no longer need to build out your entire custom backend infrastructure from scratch. For example, I recently released a new app called https://chaintrend.org – a “Google Trends for Bitcoin op_return”. Something like this would have taken me weeks to build had I started from scratch, but it took me exactly one day to build the whole thing thanks to Bitdb. It was just a matter of a single map-reduce query to the db.

The Bitdb network.

In addition to the ease of use, a more important benefit of Bitdb is that it provides a standardized way of querying Bitcoin OP_RETURNs, which is something that never existed before. Before Bitdb if you wanted to build an OP_RETURN based application, you would have had to build an entire backend infrastructure to crawl, process, index, and store OP_RETURNs in your own custom database in a queryable manner. This is exactly what the Memo.cash team did and it’s a lot of work. Furthermore, this is completely redundant for every developer who wants to work on a decentralized app powered by Bitcoin OP_RETURN. They would all end up building their own custom infrastructure that are completely incompatible with one another even though they’re all building on top of exactly the same ledger — Bitcoin.

This is where Bitdb comes in. It takes all the OP_RETURN messages, chunks them into pieces, and stores them under attributes with a standardized naming convention that goes: “b1”, “b2”, “b3”, etc. There are many benefits to this approach:

This standardized way of indexing provides a uniform interface to querying the blockchain and makes interoperability across apps a trivial matter. For example when Blockpress first launched, a lot of people complained about the protocol incompatibility between Memo and Blockpress. But with Bitdb this is a non-issue. For example, with a single query, you can even create an app that combines Memo and Blockpress into a unified feed.

Here’s a great example.  

Developers no longer need to worry about how to store their data. Without an open standard indexing strategy, every app developer needs to carefully think about how they will structure the protocol and how they will store the data. And since all apps have different purposes, their database will all look different and incompatible with one another therefore difficult to integrate. We don’t want that. We want all apps to seamlessly integrate with one another through the single parent protocol which is Bitcoin. And that’s Bitdb’s main goal — Interoperability. When you build your decentralized app using Bitdb your app is automatically open sourced (which is what users want) even without you doing anything (which is what you want). All you need to maintain are the protocol specification and the frontend implementation. So if the app developer decides to move on, anyone can resurrect the app easily by reconstructing the data from scratch using Bitdb — no need for the original developer to go through trouble to open source their backend, because it’s already 100% open simply by choosing to use the Bitdb scheme instead of rolling a custom backend infrastructure. You could even build an app WITHOUT a public frontend. An app developer may decide to just publish the Bitdb query recipe for their app protocol somewhere either publicly or privately, and the target users can build their own frontend locally using the Bitdb query, which means you can build truly censorship resistant apps this way if you want.

BC: How do you feel about the amount of development taking place with the BCH ecosystem since the May hard fork?

Unwriter: Two things:

OP_RETURN increase: When most people see the OP_RETURN size increase from 80 bytes to 220 bytes, they see just a three-fold increase. But when developers look at it I think they see an exponential increase. Developers are very used to creating exponential output from linear input because that’s their job description. We won’t see apps that are 3 times better, we will start seeing apps that never could exist before, which will change everything. The block size limit increase: For most people, I assume the 32 MB size probably sounds cool but not really that tangible. But what’s really important is this increase is a great signaling for all the developers and entrepreneurs who are looking for a platform to build on top of. The block size increase demonstrates the commitment to the “permissionless innovation” philosophy and I think that’s a good philosophy to bet on if you’re building an open source project such as Bitcoin.

BC: If there was something specific you wanted to add to the next hard fork what would it be?

@_Unwriter

Unwriter: To succeed, I think Bitcoin at this stage needs to focus on the application ecosystem growth instead of its own growth. This is because I believe exponential growth will come NOT from individual merchant adoptions but from entrepreneurs and developers building useful things on top of Bitcoin. These people are good at creating exponential output from linear input, therefore are the ones Bitcoin needs to win trust from if it wants to grow most efficiently. So in my humble opinion, the top priority for protocol changes should be the features that improve on these fronts — getting trust and attention from entrepreneurs and developers (instead of individual users and merchants). Individual users and merchants will follow when there are more useful things they can do with Bitcoin. Until then, individuals will only see Bitcoin as a speculative asset no matter how many buzzwordy features it adds. 

And to win trust from these people Bitcoin needs to show that it’s scalable, stable, and permissionless. Without scalability, it’s not so attractive to these people because they would rather spend their energy building things on other platforms that they can benefit exponentially from. And without the perception of permissionless innovation and stability, wise developers will not want to waste their energy building stuff on top of Bitcoin because they don’t want to wake up one day to find that the rules of the game have changed overnight and all their effort has gone to waste.

So for example, I think the recent hype and conflicts around tokens on BCH is very healthy and desirable. ICOs have acquired a bad reputation because most of them are scams, but I do believe it is a necessary evil because it will attract the type of people who are seeking exponential growth/returns on their projects and businesses. It will have been a success even if 0.01% of them end up becoming a success and the rest of them are scams or failures. Especially on BCH, since it’s all about scalable usage.

BC: As far as the BCH and BTC rivalry is concerned how do you feel about this subject as far as the future is concerned?

Unwriter: We can learn a lot from history. I think the French revolution provides a lot of insight into the future.

BC: How can other developers help you with your projects if they wanted to collaborate with you or the new applications you’ve built?

Unwriter: I think the best way to get started is actually build your own apps using all the open sourced tools such as Chainfeed API and BitDB. There are so many cool things you can build TODAY, even without running your own node but simply using BitDB/Chainfeed combination. Eventually, as you start using them you will come across pain points and maybe even improvement ideas. Feel free to make suggestions, ask questions, and send pull requests. I’ve done my best to be available as much as possible through the telegram chatroom and Twitter, so reach out anytime.

In fact, all this is already happening organically and it’s amazing. There are some really cool projects already using the Chainfeed and Bitdb infrastructure. One such example is the Chainbet protocol. It uses the Chainfeed API to deal with real-time messaging. Also, the upcoming Simple Ledger Protocol will use a unique security model that takes advantage of both SPVs and BitDB to complement each other. Also, the popular Memo++ extension by Modulus makes use of Chainfeed/Bitdb API. Lastly, I also know of a few people working on a Google-like search engine on top of Bitdb. But these are just some of the projects I’m aware of, and I’m sure there are many other people working on their cool projects, would love to hear from them.

Some people are even forking Bitdb for their own altcoin blockchains and I totally encourage them. If you’re thinking of doing this, please do so and reach out. The codebase is modular for a reason so any Bitcoin-like chains can integrate easily. I take this radical open approach because I believe strongly enough in Bitcoin that I know it can do no harm but only bring good. I also believe the most effective way for Bitcoin to grow at this stage is to gain as much external developer/entrepreneur mindshare as possible, and interface with as many external technologies as possible.

What do you think about all the applications Unwriter has launched? Let us know what you think in the comment section below.

Images via Chainfeed, Read.cash, Bitdb.network, and Twitter. 

Verify and track bitcoin cash transactions on our BCH Block Explorer, the best of its kind anywhere in the world. Also, keep up with your holdings, BCH, and other coins, on our market charts at Satoshi Pulse, another original and free service from Bitcoin.com. 

The post A Discussion With the Prolific Bitcoin Developer Unwriter appeared first on Bitcoin News.