Blockchain Commons work in the third quarter included:
- Gordian Envelope
- Gordian Envelope Attachments
- Gordian Envelope Keys & Seeds
Code & Libraries:
- Rust Libraries
- Rust Envelope CLI Tool
- Gordian Seed Tool 1.6
Articles & Discussions:
- Return to SSI
- Return to Musings
- Return to #SmartCustody
Web Site Revisions:
- Developer Website
- Life with Alacrity
Creating specifications is one of the most important things we do at Blockchain Commons, because it allows developers to work together in interoperable ways, and thus creates a more resilient ecosystem for all of our digital assets.
IETF. In July we attended IETF 117 with the goal of advancing some of our specifications into standards that will allow their wider use. We had a meeting on Gordian Envelope as well as a slot for talking about dCBOR as part of the CBOR meeting, and both allowed for notable advancement of those specs.
dCBOR. Our Internet-Draft for dCBOR has been changed from being “implementation details” to being an “application profile”, which makes it a description of how an application might implement a subset of CBOR — in this case to produce deterministic results. With this understanding in place we have released v05 of our dCBOR draft and feel confident that we are zeroing in on a spec that will be accepted by the CBOR community.
More recently we also wrote a very short research paper on our preferred encoding of dates in dCBOR.
Gordian Envelope. Our discussions at IETF 117 also allowed us to finalize negotations for which CBOR tags we can receive from IANA. As a result, we’ve been able to tighten up the Envelope spec in a new draft by simplifying the core of Envelope and minimizing the tags we used. Simultaneously, we received the registration of CBOR Tag #200 for Gordian Envelope. Note this was a breaking change, but because of the official IANA recognition and the IETF guidance and support, we feel quite comfortable with the newest iteration of Gordian Envelope going forward.
The updated spec also trimmed a lot of features from Gordian Envelope, to allow for its more general use. However, we’re reintroducing those features through new research papers, which cover known values, symmetric encryption, and compression.
Gordian Envelope Attachments. We’ve also developed a major new feature for Gordian Envelope: attachments. These encode vendor-specified data, allowing for the inclusion of specific, typed data, either in an open and interoperable way or in a private way, as an individual vendor prefers.
Gordian Envelope Keys & Seeds. Finally, we published two more research papers, covering the storage of Bitcoin output descriptors and seeds in Gordian Envelopes. We think these will again improve interoperability, and as a result Envelopes are now the preferred method for exchanging keys, seeds, and output descriptors in our reference apps.
If it’s not obvious, nailing down the fundamentals of Gordian Envelope allowed for a very creative period of expansion and extension for the format. We’re very grateful to IETF for working with us to reach this spot and are thrilled to have extended the community of Gordian developers to this larger organization.
Code & Libraries
Our specifications become reality through reference libraries and reference apps that we make available to developers interested in implementing our protocols. In addition to all our work on dCBOR and Gordian Envelope, we were able to make notable expansions here as well.
Rust Libraries. We have been developing new versions of all of our core cryptography libraries (including Envelope and SSKR) for Rust. Besides performance and type safety advantages, this also allows for easy usage on Android. The libraries are now in community review. We’re looking to see if they meet your needs, so please let us know!
Rust Envelope CLI Tool. Using our Rust libraries, we are also working on a new version of our Envelope CLI written in Rust. It’s a Rust crate called
envelope. It’s very similar to our existing Swift CLI, but without default commands, requiring more precise usage. We’ll be continuing to work on this for full release next quarter.
GST 1.6. We also have done some continued work on Gordian Seed Tool to support both the changes in the Envelope spec and the ability to exchange Envelopes containing metadata with our
envelope-cli as a proof of concept for how third-party developers can interchange data. An example of the functionality can be found in the video of our July Developers Meeting. Participants in our public Testflight for GST should also be able to download GST 1.6 at this time.
Articles & Discussions
We supplement our specs and apps with a variety of documents and articles, explaining our philosophies and documenting ways to support them.
Return to SSI. Self-sovereign identity was one of our first pushes, even prior to the incorporation of Blockchain Commons. Its ideals of independence and privacy remain some of our most important goals. This quarter Christopher followed up on his foundational “Path to Self-Sovereign Identity” article with a new look at “The Origins of Self-Sovereign Identity”. Seven years on, self-sovereign identity has prospered and spread, but in some cases it’s moved away from its original intents, which the new article discusses. Christopher also penned a piece on “Self-Sovereign Computing” which talks about self-sovereignty in the larger computing ecosystem, and how we can be the captains of our own vessels on the digital seas.
The concepts of self-sovereign identity aren’t just philosophical musings. They’re very important ideals that affects the safety of their users. In the past, incorrectly used identity has literally led to genocide. Working to prevent this sort of misusage is another of the origins of self-sovereign identity, which Christopher wrote about in an advance reading for Rebooting the Web of Trust 12, called “Echoes from History: Designing Self-Sovereign Identity with Care”.
Return to Musings. The article on “The Origins of Self-Sovereign Identity” was part of Christopher’s “Musings of a Trust Architect” column, where he writes about many of the architectural, security, and privacy decisions underlying our work at Blockchain Commons. This quarter also saw the publication of “Least & Necessary Design Patterns”, where he discussed a few different ways to look at the protection of data through minimization. Varying viewpoints in this way is important because it can give us new insights into tough security problems.
Return to #SmartCustody. #SmartCustody is a cornerstone of self-sovereign identity because it supports the resilient control of self-sovereign assets. Our multisig scenario, which describes how to use simple tools to maintain digital assets using a multisignature, received an update this quarter to integrate it with the newest versions of the Passport wallet and the Sparrow coordinator.
Web Site Revisions
Websites help us to organize our documentation and make it easily available. They saw two major expansions in Q3.
Developer Website. We have created a new website at developer.blockchaincommons.com that collects together all of our info on eleven different specifications and other projects, plus our architectural overviews — all of which was previously scattered across several different repos. The overviews of the specs are supplemented by FAQs, test vectors, use cases, and developer documentation. Take a look! And, if there’s a category of documentation that you want for a specific page, and it’s not there let us know!.
As part of this work, we also created new pages for some of our specifications that had previously received less description. This includes pages on dCBOR, LifeHash, and Object Identity Blocks (OIBs).
Life with Alacrity. Some of the foundational concepts behind Blockchain Commons were originally written for Christopher Allen’s Life with Alacrity blog. That’s where “The Path to Self-Sovereign Identity” was originally published as well as articles on Dunbar’s Number, community sizes, collective choice, and more. This last quarter we converted the old site over to a GitHub Page using Minimal Mistakes, to make sure it remains a great resource for the future. (There’s still some clean-up of tags to do, and we want to make it look a little nicer!)
For the coming quarter we’re going to by trying out a new salon style similar to our Silicon Salons and #TokenEthics meeting: Expert Round Tables. These round tables will allow experts to both answer and ask questions about a specific area of expertise, to improve our joint understanding of the topic.
Our first Expert Round Table will be on Schnorr. We’ve already got a few experts lined up, but if you are currently studying or implementing Schnorr, please contact us to apply to participate. (The whole Round Table will of course be open for viewing too, just be sure you’re signed up to our Signal channels or mailing lists to receive notice when we lock down the date and guest list.)
For the fourth quarter we also plan to finalize the Rust envelope-cli, move GST 1.6 to release (mainly pending an update to restore PSBT compatibility with Sparrow), and continue work on our reference tools for Collaborative Seed Recovery (CSR).