In a nutshell, Factom is a Merklized, recursively-embeddable, data-agnostic distributed ledger with a federated consensus model. Put differently, it’s a general-purpose data-ledger designed to be able to “piggyback” off of other blockchains’ (im)mutability assurances.
I've gotten to build a lot of cool stuff with Factom.
In 2015, I was hired on as an engineer at Factom, Inc. I remember that towards the end of my job interview, Paul Snow asked me, “Have you ever programmed in Go before?” I confessed that no, I had not. He just chuckled and said “You’ll pick it up, no problem,” with a confident smile.
Early on, I built a GUI wallet for factoids and entry credits, rewrote the Factom Explorer (starting with the back-end and then tackling the front), built a couple of demo applications (and more than a couple developer-oriented tools and scripts), and extended the factomd RPC APIs.
I soon developed a reputation as a go-to engineer within the organization, and I found myself hopping from project to project as different priorities sprang up in the company. For a while, my job title was the one-and-only Code Warrior at Factom:
This was my actual business card.
My prior experience at HostGator made me the obvious choice when it came to technical website administration. This proved to be a wise decision; when the official .com website content was somehow lost or corrupted at the host (on more than one occasion, no less), it was my personal, just-to-be-safe backups that ultimately saved the day.
I loved every minute of this crazy period. Every time someone had an idea for a proof-of-concept or demo application, it was enthusiastically thrust into my lap. I hopped from one thing to another; one day I’d be building an on-chain-data sourced price chart in d3.js, and the next I’d be writing a web-app to demonstrate automated hierarchical hash-checking utilities for mortgage and securities bundles. Sometimes a new API endpoint needed to be implemented and added to the set of RPCs or a bug in the core node software would need investigating, and I’d be called in to figure it out and get everything working.
When it came time to implement the faulting/election component of the consensus algorithm for Factom’s from-the-ground-up Milestone 2 build, I was chosen to spearhead it. Thus began a multiple-months-long rigorous journey into the subtleties and nuances of consensus algorithms, distributed fault-tolerance, and network topologies which taught me firsthand just how complex and frustrating these subjects could be. It’s difficult to truly appreciate the depth of such things until you’ve gotten your hands dirty on them and stared head-on into the wondrous and horrific abyss that they represent.
During this time, I obsessively researched and carefully reimplemented a RAFT engine using the Factom server message protocol, and because vanilla RAFT systems are not Byzantine Fault Tolerant out-of-the-box and Byzantine vulnerabilities would adversely impact Factom’s censorship resistance properties, I set to work extending and hardening the protocol along this axis. At one point, a new manager expressed skepticism regarding the formal soundness of our election protocol, and he emphatically suggested that we instead pursue a CRDT-based consensus/messaging approach. It fell to me to investigate the feasibility and worthiness of doing so.
I remember feeling intuitively that this idea was “off” rather quickly, but it took me a couple of days before I was able to concretely pin down and express why: namely, CRDT consensus schemes are eventually-consistent in nature, while Factom’s minute-and-block-based model is fundamentally delineated into discrete epochs. In other words, even though both of these approaches to distributed consensus are valid and practical in different real-world applications and contexts, they can’t realistically (or, at least, fruitfully) be combined into a “hybrid” ledger model. This was a subtle case of trying to square the circle, or at minimum a case of inadvertently asking for a total architectural overhaul.
Fortunately, when I presented this hard-earned insight on the matter, everyone else was just as grateful as I was that the question had been concretely and definitively answered, and we continued coding, testing, debugging, and pushing forward with everything we had to ship Milestone 2. There were often days where I'd need to remind myself to take "eye-breaks" after combing through 32-byte hashes for hours on end.
Once again, I loved every excruciating minute.
After a sabbatical beginning in late 2017, I returned to a much more mature State of the Factom Union. Not only had Milestone 3 shipped and the decentralization of the Factom network begun in earnest, but a community (and more locally, a team) of very cool, very smart folks had assembled during my absence. I was impressed, and eager to get back into the mix with all my new lessons, experience, and personal growth to guide and fuel me.
I ramped up-to-speed on the new Kubernetes-managed deployment artifacts, learned the ins-and-outs of the new Billing System and Connect architecture, and spent some time familiarizing myself with the new workflows, team members, and community projects that had sprung up while I was away. Before long, I found myself assigned as the lead (and for a while, sole) developer on Factom’s new Harmony Integrate initiative.
For many months, I was steeped in the Verifiable Credentials, DID, and JSON-LD data models, building a fully conformant suite of credential and presentation management tools in Javascript that offered seamless blockchain registration and integration, along with the relevant associated cryptographic proofs. The W3C spec was evolving during much of this time, so it was my job to keep a bead on the moving target that it represented. This was both challenging and eye-opening; in a way, it represented a “peek behind the curtain” at the various components, committees, processes, and politics that go into digital standards. It wasn't always pretty but it was certainly quite a sight to behold.
As far as metaprotocols on top of Factom go, PegNet is by far the most successful right now. I had the honor of taking part in the brainstorming and design process of PegNet's DeFi mechanisms and structure, and I also helped to build the Prosper mining pool software (which basically involved porting Stratum to support PegNet) alongside the brilliant and prolific Steven Masley.
While other projects (e.g. Peter Todd’s treechains or Tierion’s Chainpoint) have echoed similar value propositions, Factom is an exceptionally robust platform in the niche that it targets and occupies. Since its launch, the specifics of Factom’s vision have been validated time and time again, in ways that are often too subtle for most to even notice. If anything, Factom’s biggest “problem” in execution is often being too ahead of the curve!
Factom has been such an amazing opportunity for me, in so many ways, that there’s no way that I could summarize my time or work there in a way that does it real justice. Suffice to say, it has been a Dream Job getting to build and tinker with this stuff, and I’ve cherished my time as I’ve gotten to play a part in the still-unfolding tale of the project.