The Four Things: What do we call them?

General
1

Today, Threshold is concerned primarily with two cryptological phenomena:

  • Signing-Verification (underwritten by threshold ECDSA, an evolution of Keep)
  • Encryption-Decryption (underwritten by threshold CBD, an evolution of NuCypher PRE)

We have no formal name for the former, but atop it we hoist what is, for the moment, the most familiar and highly dogfooded Threshold application: TBTC (recently called tbtcv2). Presumably this is the first, and not the only, application that we and others intend to build using threshold signing.

Conversely, we call the latter “Threshold Access Control”, but we have no formal name for anything we’ve yet built with it. However, in our codebases, we still refer to “Threshold Access Control” as nucypher. For example, perhaps the most characteristic line we can think of, regarding access control, is:

from nucypher.characters.lawful import Alice, Bob, Enrico, Ursula

On top of this tech - particularly using the Enrico and Bob characters and their new abilities to use either PRE or CBD, several outside users have broken ground on applications, with Masterfile (which began as a hackathon project, the participants of which have been highly receptive to our coaching and suggestions, and highly communicative about their needs) as the most recognizable. Additionally, we have finally begun genuinely dogfood in the form of an application that I intend to use to release my upcoming record, “Vowel Sounds” (I have begun informally calling this application “Revealer”).

So, this gives us a 2x2 grid - The Four Things referenced in the title of this post - which need names:

╔════════════════╦════════════╗
║······· TBTC, etc. ·········· ║ · Revealer, etc.··║
╠════════════════╬════════════╣
║···threshold ECDSA·····║·····nucypher·······║
╚════════════════╩════════════╝

These are big branding questions and perhaps represent the next stage of evolution for Threshold, so let’s start small.

What do we want the above line to look like? I imagine we all agree that we want the word after from to match our website, documentation, etc. So, do we change those things to use the word “nucypher” (all lower case) to mean what we have sometimes called “threshold access control”?

Or do we change the line to look more like:

from threshold.characters.cbd.lawful import Alice, Bob...

Who has thoughts?

8 Likes
2

KeEp it as is. At its core there’s a nod to the original creators of the codebase (cool!), there are plenty (and enough) references to Threshold & threshold in many, many places.

Yet, I think we need more at BTC Miami.

Just my thoughts… I’m in the shower so excuse any tpyos!

1 Like
3

I’m in the shower

Well first let me express my appreciation that you have seen fit to delegate a portion of your showerthought bandwidth to this matter.

KeEp it as is

Fine by me.

However! Consider the full implications of what this means:

╔════════════════╦══════════════════════════════╗
║······· TBTC, etc. ·········· ║ · Revealer, etc.··║··Application/Platform··║
╠════════════════╬══════════════════════════════╣
║···threshold ECDSA·····║·····nucypher·······║·········API/Runtime········║
╚════════════════╩══════════════════════════════╝

Notice that the two things we often speak of as our offerings - TBTC and Threshold Access Control (here called ‘nucypher’ per your “leave it as is” suggestion) are on different layers of the stack!

To speak of them as if they are like things creates subliminal confusion and sometimes maybe even discomfort. There’s a logical breakage; a miscounting of the number of concepts needed to properly describe this collaboration.

And I surmise that this may be a significant part of the reason that we’ve all felt friction in the process of the Keep and nucypher teams coming together as OneAwesomeThreshold.

And lo! Again I miscount the layers! Because once we start thinking about “Keep” and “nucypher” we have again compared unlike things. For the purposes of comparing these concepts, we need to expand the chart (and allow me the liberty of one modification - replacing “threshold ECDSA” with “keep” - lower case) :
╔════════════════╦══════════════════════════════╗
║······· TBTC, etc. ·········· ║ · Revealer, etc.··║··Application/Platform·║
╠════════════════╬══════════════════════════════╣
║················keep·············║·····nucypher·······║·········API/Runtime········║
╠════════════════╬══════════════════════════════╣
║··············Thesis············║·····NuCypher·····║·······Steward Entity········║
╚════════════════╩══════════════════════════════╝

And now we see more clearly how disparate things actually are:

The “Keep Team” (maybe better to just start saying “Thesis”, even though my understanding is that Thesis internally silos of the portion of their team which works on keep), despite some whiffed deadlines and communication growing pains, has now built two things (in parallel, which I believe to be essential): the underlying API/Runtime, which we can perhaps start calling “keep” (lower case), and the Application TBTC on top of it (which they, and we, have actively dogfooded). (And I know for my part, I’m very much looking forward to seeing how Thesis exposes the keep APIs, so that other people can built signing-verifying apps, and especially about how the fee model works there - something we’re still working out for nucypher.)

So now we’re in a situation where Thesis has built one application on Threshold, and are working on others which will use our APIs/Runtimes, but which are separate from the DAO (and, if I understand correctly, from its internal regard as the boundary of the keep team), such as Embody and Tally. Cool! (I think, right?)

So the obvious question is: does this imply a standing agreement to each deploy and maintain at least one standing application on top of our respective API/Runtime?

If so, and if nucypher (distinct from nucypher, the importable python package) is the API/Runtime, then what is NuCypher (distinct from the other two, the team stewarding development) building as a dogfooded application, to maintain parity?

It is this question which has chiefly been on my mind as I have considered how to release my next record.

2 Likes
4

My thoughts on naming and how to position the various aspects of Threshold are still jumbled (so I imagine it’s even worse for our audience!), and I don’t have good answers yet.

Generally, things that have assets attached (tBTC and thUSD) are easier to explain than things that do not (TAC, threshold signing, etc.). And, broadly, I think it’s better to center Threshold as the consistent brand over NuCypher or Keep (if Threshold is successful, the majority of our future audience is going to consist of people who entered crypto post-KEaNU which means the NuCypher/Keep context serves only to distract and confuse).

I don’t think this is the right mindset. Maintaining parity in terms of shipping pieces of software at various layers is not in and of itself useful.

The Important Thing is shipping stuff that people use and that drives value for the network, whether it’s at the API/Runtime layer, the Application/Platform layer atop threshold cryptography, or neither (e.g. thUSD).

4 Likes
5

I am not a native coder, and wasn’t totally clear on the term “dogfooding”. I found this article added a little clarity for me, and wanted to share it in the discussion:

"Software engineers are hungry for excellence. Dogs are hungry for dog food. And software engineers at many companies are hungry to “dogfood.”

In the world of tech, dogfooding means consistently using a product you built, just as a user might, to figure out what works and what needs to be fixed." - Lora Kelley, NYT

What Is ‘Dogfooding’? - The New York Times.

2 Likes
6

And, broadly, I think it’s better to center Threshold as the consistent brand over NuCypher or Keep

I’m broadly inclined to agree with this. So let’s examine deeper changes.

For a significant subset of our audience, the name of the module they are asked to import is one of the most significant touchstones of nomenclature.

Do we want to consider a refactor so that we have:

from threshold.access_control.characters.lawful import Alice, Bob, ... ?

I think it’s a potentially big mistake to underestimate the importance of the word that follows “from” in an import statement.

I don’t think this is the right mindset. Maintaining parity in terms of shipping pieces of software at various layers is not in and of itself useful.

Gonna have to go ahead and disagree with you there, mo capitaine. Maintaining parity between signing-verification and encryption-decryption through the layers is what allows us to craft a narrative about why things built on top of them are properly understood as “Threshold.”

It is confusing - even to me, with all the intimate knowledge I have of the project - to try to understand why “Threshold Access Control” is part of the same basket of offerings as tBTC, when the latter is obviously built higher on the stack. Even if we don’t sink much effort into parity with respect to development and maintenance, I think it’s essential that we be able to cleanly characterize these pillars in our everyday vernacular, and in our marketing materials and technical documentation, so that our unity has a sound basis to which we can all continually refer.

The Important Thing is shipping stuff that people use and that drives value for the network, whether it’s at the API/Runtime layer, the Application/Platform layer atop threshold cryptography, or neither (e.g. thUSD).

The phrase “that drives value for the network” is the part that (I imagine we can all agree) is the most flummoxing here. Because we don’t yet know how the signing-verifying layer, atop which tBTC is built, can capture value. And yet, we are spending a dramatically disproportionate amount of time on that same layer - and of course encountering identical quandaries about how this layer is monetized - with regard to the codebase that is currently still called nucypher.

It seems to me that we need to immediately begin thinking hard about:

  • How does the tBTC fee model apply to projects built on top of the encryption-decryption pillar?
  • As you have pointed out in conversation with me, tBTC is the beneficiary of obviousness insofar as the archetype most available in the blockchain zeitgeist for signatures is the asset bridge. What is the obvious zeitgeist archetype for encryption-decryption? (As you know, my sense is that I have begun to identify the features of a potential candidate, and I intend to continue to break ground thusly)
  • (the hardest one of these three) What can we know about the fee models we’re tiptoeing into for CBD based on tBTC? In other words: if instead of building tBTC ourselves, we took the route we’re taking so far with CBD adopters, and encouraged one of them to build it, how do we imagine generating fees from such a thing?

@mhluongo, have you brainstormed much about how exposure to the signing toolchain can be monetized? What are the most relevant fee models and why? And if we’re still going to attempt to monetize the decryption toolchain in a like manner, are those fee models relevant for this purpose?

2 Likes
7

I’m a big fan of “call it what it is” and it feels like this may help developers when first trying to use the product. (at least when they initially start building, since after familiarity is gained the “name shock”/confusion factor fades)

2 Likes
8

I’ve given it quite a bit of thought… and what I came up with was that it’s easier to monetize higher on the stack :grin:

I don’t know if that’s actually true, but I’ve found it difficult to search for teams building use cases atop infrastructure that we build, and even more difficult to find people who will pay a reasonable price… when in my experience, what many devs want is the quickest, cleanest demo possible. Very few projects survive in our space to mature to the point where they need (and understand they need) world-class cryptography atop a decentralized set of actors.

Which points directly to a difference in philosophies in how we’ve been developing / what we choose to work on. The Keep team built the BLS random beacon to be used by outside devs, then pivoted to tBTC as it was difficult to productize threshold ECDSA… without ever even figuring out what devs would pay for a robust random beacon. The NuCypher team has continued to focus on underlying infrastructure, and hasn’t made the jump to building up-stack.

Who else is earning protocol fees providing infrastructure like this? Does Chainlink as a protocol make money with their VRF or their oracles? L1 and L2 operators are certainly earning significant fees. I think finding a comparable would help us frame the infra vs application discussion.

9

Indeed, we do silo the work at Thesis by project and subsidiary… and to further complicate things, we have “spun out” teams like Fold and Saddle that operate entirely independently, and “internal” teams like Keep, Taho, and Embody that are in different states of maturity and independence.

The Keep team has fixed members that change infrequently, though we’ve discussed mixing that up more as some of our other projects mature and we get tBTC closer to ossification. Eg, at an onsite recently some Keep team members built early BTC support into Taho.

It doesn’t… but it does remind me of the idea of multiple dev teams building different clients for a blockchain. I don’t believe our work would yet benefit from multiple implementations, though I could see that being a good idea in the future.

What is our paradigm going forward? Right now, both the Keep and NuCypher dev teams have discretion to build whatever they want. Neither is funded by the DAO, both are building things around the DAO. The Threshold USD team is funded by the DAO, which I imagine means directed by the DAO… though I’m not involved enough to know what that entails.

I don’t have answers here. It does make a ton of sense to me that the DAO funds applications built atop the network as a way to start a flywheel, eg with grants.