Summary of Gordian Developer Meeting @ January 10, 2024

[shannona]

The January 10th meeting was held at a Europe-friendly time (10am PT), which continues to be popular among our participants, many of whom hailed from Europe.

Blockchain Commons welcomes any participants interested in the Gordian Principles of independence, privacy, resilience, and openness, or the Gordian architecture and its various specifications such as URs, Bytewords, and Envelope. Please sign up for our Gordian Developer Announcement List and/or Signal group, and you'll receive info and links for every meeting. They tend to be held on the first Wednesday of each month.

dCBOR: The Latest Update

dCBOR is Blockchain Commons' deterministic version of CBOR. It's now in v7 through work with CBOR WG at IETF as a "profile" of CBOR. As a profile, it restricts usage of CBOR (to ensure determinism).

We have Rough Consensus & Running Code, and are hopeful the dCBOR I-D will become a RFC.

Gordian Seed Tool: 25519 Interop & Tezos

Gordian Seed Tool (GST) is Blockchain Commons' developer exemplar. We're now moving it beyond secp256k1 to also support ed25519. We've begun this work by offering support for the Tezos blockchain.

So GST can now show private & public keys & addresses for TZ1 addresses (ed25519)

Output Descriptors

GST now can also store output descriptors with a seed, so you know which path you're using to hold assets!

This is just one important part of metadata. We need to hear from wallet creators what other metadata they might need!

Multi-Part UR Implementation Guide for URs

Animated QRs are Blockchain Commons' biggest success.

New documents now make it easier to implement without having to go to code!

Here's the summary:

URs are a method to encode data. Fountain codes are used to generated larger, animated QRs for URs, but those were previously only documented in source code.

Animated QRs are channels that are simplex and unordered and you don't know if you missed data! Yet they're necessary for large content such as PSBTs. So how do you reliably transmit the fragmented data?

Rateless codes allow retransmission of lost content without having to resend everything. They converge toward optimal transmission time.

Fountain Codes, used in Blockchain Commons' Animated QRs, are a type of rateless code.

But Blockchain Commons' MUR actually starts off with fixed rate codes and then moves on to rateless codes. So maybe you get everything from the original batch, but if not the rateless codes will fill in missing data.

The rateless codes vary between simple fragments and fragments that are XORed (mixed) together

• Mixed parts are deciphered when sufficient simple parts are received!

Can even be used without URs! They're for any data transmission through a lossy channel.

Research Statuses

We have new statuses for our research specifications:

Symbol	Title	Description
❌❌	Withdrawn	Of historic interest only. Withdrawn either because never came into use or proved sufficiently problematic that we do not recommend its usage in any way.
❌	Superseded	Superseded by a newer BCR. We do not suggest implementing as an output format, but you may still wish to implement as an input format to maintain backward compatibility.
📙	Research	Contains original research or proposes specifications that have not yet been implemented by us. Offered to the community for consideration.
⭐️	Reference Implementation	At least one reference implementation has been released, usually as a library, and may include demos or other supporting tools. This specification still remains very open to change because it has not yet (to our knowledge) been implemented by additional parties.
⭐️⭐️	Multiple Implementations	At least two (known) implementations exist, at least one not by the owner of the reference implementation. Has demonstrable community support. May still change due to the needs of the community, but community feedback will be sought.
⭐️⭐️⭐️	Standards Track	Typically at least two implementations, and is considered stable and ready for standardization. Being proposed as a BIP, IETF Internet Draft, or some other standardization draft format. Will typically be moved to the BCP repo. Though changes may still be made to the specification, these changes will exclusively be to allow for standardization, and will be conducted with community feedback.
⭐️⭐️⭐️⭐️	Standardized	A specification has been standardized as a an IETF RFC, BIP, or approved by some other standards body.

We want to be clear about statuses to talk about how stable a specification was.

See the Blockchain Common Research repo.

Secure NFCs

An important future.

URs & Animated QRs have been widely adopted, but URs are transport-agnostic. This has advantages that allow us to start leveraging NFCs. For example a share could be stored to a share server or an NFC card or even a smart NFC card that can do cryptographic operations on the card.

This is an emerging project this year! We want it to be open & inspectable, unlike some NFC alternatives to date.

JavaCard is the leading contender in this capability.

• JCOP Java Card is a nice cheap but functional option

Initial goal: Bitcoin PSBTs, signing from cards; as well as Envelope-based SSKR; and to sign other sorts of messages.

Blockchain Commons is looking for interest & expertise! Let us know if you're interested!