Blockchain Commons 2024 Overview

--- robots: noindex, nofollow --- # Blockchain Commons 2024 Overview ![](https://www.blockchaincommons.com/images/2024-Yearly.jpg) ## Making Visions Reality We've often written in our yearly reports that the goal of Blockchain Commons is "the creation of open, interoperable, secure & compassionate digital infrastructure to enable people to control their own digital destiny and to maintain their human dignity online". Our architecture is ultimately based on these and other values, as Christopher wrote in ["How My Values Inform Design"](https://www.blockchaincommons.com/musings/ValuesDesign/), which we published at the start of this year. Obviously, we can't just create infrastructure on our own, so we've worked toward our values-focused goals by bringing principals together for regular [developer meetings](https://www.blockchaincommons.com/subscribe/) and by advocating for the adoption of specifications that we believe achieve these goals (and in many cases by creating those specifications ourselves). In 2024, much of our work in this regard focused on three different specifcations: dCBOR, Envelope, and FROST. ## dCBOR <a href="https://cbor.me/"><img src="https://www.blockchaincommons.com/images/cbor-me.jpg" width=300 style="float: right; padding-left: 16px; padding-bottom: 2px;"></a> [dCBOR](https://developer.blockchaincommons.com/dcbor/) is our deterministic profile for the CBOR data format. We adopted CBOR itself for [a variety of reasons](https://www.blockchaincommons.com/introduction/Why-CBOR/), including it being self-describing, extensible, and great for constrained devices. However it had one lack (for our purposes): you couldn't guarantee that two different devices would encode the same data in the same way, at least not for a variety of weird edge cases (such as whether "1.0" and "1" get encoded the same way, and what you should do for maps with illegally duplicated keys, and how to deal with NaN). This was problematic when we were developing Gordian Envelope, which depends on the same data always being represented the same way so that it always hashes the same—hence the need for dCBOR. dCBOR received a lot of attention from us in the first half of 2024. We went through [five drafts](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/) of the specification, revising some of our original definitions and incorporating things like Unicode Normalization Form C (NFC). We're very grateful to our partners from the IETF CBOR group who laid a foundation for us with the [CBOR Common Deterministic Encoding draft](https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/), which has been advancing in parallel with dCBOR, and who helped us fill in these gaps in dCBOR itself. We increasingly think we have a strong foundation for deterministic CBOR, as seen by its incorporation into [the CBOR playground](https://cbor.me/) and a [variety](https://github.com/cabo/cbor-dcbor) [of](https://github.com/hildjj/cbor2) [libraries](https://github.com/laurencelundblade/QCBOR). Implementation by two or more parties is always our mark of success for a Blockchain Commons specification, and we exceeded that for dCBOR in 2024. ## Envelope Of course dCBOR is just the prelude. Our work on dCBOR was done to make [Gordian Envelope](https://developer.blockchaincommons.com/envelope/) a reality. Gordian Envelope is our "smart document" format for the storage and transmission of data. It's focused on privacy and more specifically on the goals of [data minimization & selective disclosure](https://www.blockchaincommons.com/musings/musings-data-minimization/). More and more personal data is going online, and so we need data formats where we each control our own data and decide what to disclose to whom. That's what the hashed data elision of Gordian Envelope allows: any holder of data can chose what's redacted, without changing the validity of the data package. One thing we increasingly saw in 2024 was the need to better explain Envelope: its advantages, how it works, and why it's important. We kicked that off with a [presentation to the IETF](https://github.com/BlockchainCommons/Gordian-Developer-Community/blob/master/meetings/2024/03-18/presentation.pdf) on why hashed data ellision is important. We also produced a trio of videos on Envelope: [a teaser](https://www.youtube.com/watch?v=uDI5ihfTB2Y), ["Understanding Gordian Envelope"](https://www.youtube.com/watch?v=-vcLCFKQvik) and ["Understanding Gordian Envelope Extensions"](https://www.youtube.com/watch?v=uFxStP3ATkw). Meanwhile, we're continuing to extend Gordian Envelope. To start with, we've done a lot more with the [Gordian Sealed Transaction Protocol (GSTP)](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-014-gstp.md) extension that we introduced right at the end of 2023, to support the transmission of sensitive data across telecommunications means that are insecure, unreliable, or both! A [feature presentation on the underlying Request/Response system](https://www.youtube.com/watch?v=ZXDf2cmfX1k), explained the fundamentals followed by a [feature presentation on GSTP itself](https://www.youtube.com/watch?v=QnH14LkJOnI), which detailed what GSTP looks like now. Our new [GSTP developer page](https://developer.blockchaincommons.com/envelope/gstp/) has even more info. We've also done some investigation into using [GSTP with MuSig2](https://developer.blockchaincommons.com/musig/sequence/). We also introduced [XIDs](https://developer.blockchaincommons.com/xid/), or Extensible Identifiers, a new decentralized identifier that's built using Envelopes. You can experiment with it in code with our new [bc-xid-rust library](https://github.com/BlockchainCommons/bc-xid-rust). Decentralized identifiers have been one of our major interests since the topic was first considered at the first [Rebooting the Web of Trust workshop](https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/final-documents/dpki.pdf), but they've never been a big focus at Blockchain Commons due to the simple fact that we haven't had a patron focused on the topic. (If that could be you, <a href="mailto:team@blockchaincommons.com">drop us a line</a>!) We were happy to finally offer a little bit of our own on the topic by presenting an ID that's really _decentralized_. Other Envelope experiments in 2024 were about [graphs](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-006-envelope-graph.md), [decorrelation](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-007-envelope-decorrelation.md), and [signatures](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-009-signature-metadata.md). The privacy preserving Envelope format has a lot of legs. We're looking forward to seeing how they're used in the years to come! <table width="100%"> <tr> <td width="640px"> Teaser: {% include video id="uDI5ihfTB2Y" provider="youtube" %} </td> <td width="640px"> Understanding Envelope: {% include video id="-vcLCFKQvik" provider="youtube" %} </td> <td width="640px"> Understanding Extensions: {% include video id="uFxStP3ATkw" provider="youtube" %} </td> </tr> </table> ## FROST [FROST](https://developer.blockchaincommons.com/frost/) was the third major specification that Blockchain Commons focused on in 2024. This is a specification that we didn't develop ourself: it's based on a [paper by Chelsea Komlo and Ian Goldberg](https://eprint.iacr.org/2020/852.pdf). However, we think it's very important because it allows for resilient, compact, private multisigs, and so we've been giving it all the support that we can. Our prime work here was holding three FROST meetings in 2024 (the last two [sponsored by the Human Rights Foundation](https://www.blockchaincommons.com/news/HRF-FROST-Grant/)). We held [one meeting](https://developer.blockchaincommons.com/frost/meeting2/) for implementers, to help them share information on the continued design of FROST, and we also held [two](https://developer.blockchaincommons.com/frost/developers1/) [meetings](https://developer.blockchaincommons.com/frost/developers2/) for developers, focused on helping them to actually get FROST into wallets in the next year. Our [recordings and presentations from the meetings](https://developer.blockchaincommons.com/frost/) are full of great FROST resources from [an introduction that we put together](https://developer.blockchaincommons.com/assets/pdfs/frost-dev2-intro.pdf) to a presentation from [the first major wallet to implement FROST](https://developer.blockchaincommons.com/assets/pdfs/frost-dev2-stack.pdf). We've also done some work to incorporate FROST into our own Rust and Swift Gordian stacks as a reference, by moving over to fully BIP-340 compliant Schnorr signatures. We'd like to do more, including creating a `signtool` reference, but we'll have to see if that opportunity arises in 2025. <table width="100%"> <tr> <td width="640px"> Developers Meeting 1 (2024): <a href="https://developer.blockchaincommons.com/frost/developers1"> <img src="https://developer.blockchaincommons.com/assets/images/frost-developers-2024-1.png"> </a> Jesse Posner & Christopher Allen overviewed FROST in our <a href="https://developer.blockchaincommons.com/frost/developers1">first meeting for wallet developers</a>. </td> <td width="640px"> Implementers RT 2 (2024): <a href="https://developer.blockchaincommons.com/frost/meeting2"> <img src="https://developer.blockchaincommons.com/assets/images/frost-implementers-2024.png"> </a> Our <a href="https://developer.blockchaincommons.com/frost/meeting2">second Round Table for Implementers</a> includes presentations from six FROST implementers on their projects. </td> <td width="640px"> Developers Meeting 2 (2024): <a href="https://developer.blockchaincommons.com/frost/developers2"> <img src="https://developer.blockchaincommons.com/assets/images/frost-developers-2024-2.png"> </a> An introduction, UX challenges, the UNiFFI SDK, and a FROST Federation were at our <a href="https://developer.blockchaincommons.com/frost/developers2">second meeting for wallet developers</a>. </td> </tr> </table> Of course, FROST is just a single member of the new class of Multi-Party Computation (MPC) technology. [MuSig](https://developer.blockchaincommons.com/musig/) falls into the same category, as another Schnorr-based technology where key creation is divided among multiple locations. We talked a bit about [MuSig and how it could work with Gordian Envelope](https://www.youtube.com/watch?v=FaNypFsGczg) at our November Gordian meeting. We think that all of the Schnorr variants are pretty important for the future of the digital world because of their advantages in resilience, security, and privacy. ## Keeping it Real Obviously, not all of Blockchain Commons' work is focused on high-level specifications. We also produce ready-to-go libraries that developers can use to implement our specs, as well as reference apps that can be used for experimentation and as examples of best practices. Our app releases in 2024 included [Gordian Seed Tool 1.6](https://github.com/BlockchainCommons/GordianSeedTool-iOS) (and more recently [Gordian Seed Tool 1.6.2](https://apps.apple.com/us/app/gordian-seed-tool/id1545088229)), [Gordian Server 1.1](https://github.com/BlockchainCommons/GordianServer-macOS/releases/tag/v1.1.0), and the brand-new [seedtool-cli for Rust](https://github.com/BlockchainCommons/seedtool-cli-rust) (with a full [user manual](https://github.com/BlockchainCommons/seedtool-cli-rust/blob/master/MANUAL.md)). We've also updated our entire Swift stack to Swift 6 and continued the development of Rust libraries such as [bc-dcbor-rust](https://github.com/BlockchainCommons/bc-dcbor-rust), [bc-depo-rust](https://github.com/BlockchainCommons/bc-depo-rust), [bc-envelope-rust](https://github.com/BlockchainCommons/bc-envelope-rust), [bc-components-rust](https://github.com/BlockchainCommons/bc-components-rust), and many more! ## Hello to the Wider Wallet Community Our work has always focused on interactions with a larger community, from our IETF work on dCBOR to our Envelope work with our own Gordian community to our FROST meetings. In 2024, we were thrilled to expand that community to include even more experts in the world of digital assets and identity. Besides our trio of FROST meetings, which brought together most of the principals in that space, we also hosted other expert-talks at our [Gordian Developer meetings](https://www.blockchaincommons.com/subscribe/). That included a presentation on BIP-85 by Aneesh Karve, a look at the Ledger Seed Tool (which uses Blockchain Commons technology) by Aido, and an overview of Payjoin from Dan Gould. <table width="100%"> <tr> <td width="640px"> BIP-85: {% include video id="4W4kmV-oHrA" provider="youtube" %} </td> <td width="640px"> Ledger Seed Tool: {% include video id="2GjnZjZloec" provider="youtube" %} </td> <td width="640px"> Payjoin: {% include video id="oMGL-Y498ZQ" provider="youtube" %} </td> </tr> </table> If you have a topic that might be of interest to wallet developers, <a href="mailto:team@blockchaincommons.com">drop us a line</a>, as we'd love to welcome you to the Gordian Developers community and get you on the schedule for a presentation in 2025. ## A Focus on Identity As we said, decentralized identity (including decentralized identifiers) has been a topic of interest to Blockchain Commons since before the foundation of the company. Christopher Allen previously founded the [Web of Trust workshops](https://www.weboftrust.info/) specifically to investigate how to fulfill the promise of PGP by returning to the idea of decentralized, peer-to-peer identity. Over the course of a dozen workshops, the conference germinated and developed the idea of [DIDs](https://www.w3.org/TR/did-core/) and also supported the development of [Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/). Though we've never had an identity partner at Blockchain Commons, we're still involved in these topics as of 2024. Christopher is an Invited Expert to the new W3C DID 1.1 Working Group and participated in the face-to-face plenary at TPAC. He also is an Invited Expert to the Verifiable Claims 1.1 Working Group. Our biggest presentation to the W3C community last year was on how to create DID documents in dCBOR and what the possibilities are for using Envelope to add elision to DID Controller Docs and Verifiable Claims. This inspired our own work on XIDs, which is our own potential proof-of-concept for a DID 2.0 spec. We'll be working more with these communities in the next year. We also published a number of articles on decentralized identity in 2024 that were intended to either offer warnings about our current direction for identity or provide new ways forward. * [Foremembrance Day Presentation](https://www.blockchaincommons.com/videos/Foremembrance2024/) * [Edge Identifiers & Cliques](https://www.blockchaincommons.com/musings/musings-cliques-1/) * [Open & Fuzzy Cliques](https://www.blockchaincommons.com/musings/musings-cliques-2/) * [Has our SSI Ecosystem Become Morally Bankrupt?](https://www.blockchaincommons.com/musings/musings-ssi-bankruptcy/) We think that our articles on Edge Identifiers and different sorts of Cliques offer a whole new approach to identity. It models identity not just as something held by a singular individual, but as something shared between pairs and groups of people, who together share a context. (And this is another area that we'd love to do more work on: if you would too, let us know!) Our other two articles focused on the dangers of identity. The Foremembrance Day article (and video) talked about how dangerous identity became in WWII, a topic we've used as a touchstone when considering what we're creating today. Then our last article talked about how we think the modern identity work that Christopher kicked off with [his foundational article on self-sovereign identity](https://www.lifewithalacrity.com/article/the-path-to-self-soverereign-identity/) may now be going in the wrong direction. {% include video id="R9KuIlAg4wg" provider="youtube" %} ## Git Open Integrity Project Our biggest project that didn't quite see release in 2024 was the GitHub Open Integrity project. The idea here is simple: use GitHub as a source of truth by turning a repo into a decentralized identifier. We've worked through some CLI setup programs and have [a repo](https://github.com/BlockchainCommons/open_integrity-git_inception_pocs) that demonstrates the verification we're doing. We've also released the [SSH Envelope program](https://github.com/BlockchainCommons/ssh-envelope-python) that we wrote that supported this project by allowing the signing and validation of SSH keys. (Since, we've incorporated the signing into the main `envelope-cli-rust`). We're still working on a README that lays out the whole project, but at the moment it's backburnered for other work ... ## Coming Soon! <a href="https://z.cash/"><img src="https://www.blockchaincommons.com/images/zcash.png" style="float: right" width=150></a> The last few years have been hard on our partners in the digital identity space, due to high interest rates sucking the money out of Web3 seed funds. That in turn has hurt their ability to support us. As a result, we've been applying for grants for some of our work. At the very end of 2024, we had a [grant application approved](https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/3) by the Zcash Foundation to produce an extensible wallet interchange format ("ZeWIF") for Zcash. Though much of our work to date has been used by the Bitcoin ecosystem, advances like [animated QRs](https://developer.blockchaincommons.com/animated-qrs/), [Lifehash](https://developer.blockchaincommons.com/lifehash/) and [SSKR](https://developer.blockchaincommons.com/sskr/) are of use to anyone working with digital assets (and likely a number of other fields). So, we're thrilled to get to work with Zcash and share some of our principles such as independence, privacy, and openness (which were all part of our "ZeWIF" proposal). We hope this will also lead to adoption of some of our other specifications in the Zcash ecosystem. Obviously, more on this in Q1, as we have it laid out as a three-month project, running from January to March. Though we're thrilled with one-off grants like the HRF and Zcash grants that were approved in 2024, Blockchain Commons is also looking for more stable funding sources to continue our work making the digital-asset space safer and more interoperable. You can help this personally by lending your name to Blockchain Commons as a [patron](https://github.com/sponsors/BlockchainCommons), but we're also looking for companies who are interested in using and expanding our specs, who want to partner with us to do so. Contact [us directly](mailto:team@blockchaincommons.com) to discuss that! With your support, we'll be able to produce another report on great advance in 2026. --- _Picture Frames Designed by Freepik._