Rename repo to `taco-ts` (or perhaps `taco`?)
Closed this issue · 10 comments
No reason to keep the nucypher-ts name before going live.
I prefer just taco rather than taco-ts. I don't see any reason to include the language in the repo's name.
taco makes sense to me. @manumonti 's point is a good one about not including the programming language in the name. Also, at the moment the npm package is @nucypher/taco - https://www.npmjs.com/package/@nucypher/taco.
Should we do a holistic thought exercise about what other repos names will be; will nucypher, nucypher-porter, nucypher-contracts remain? Then we can see if taco for this repos still makes sense.
Just wanted to note that this repo contains a monorepo with 3 different packages:
@nucypher/shared@nucypher/pre@nucypher/taco
So if we rename the repo we should give some context about how this thing works.
@piotr-roslaniec, it seems to me that 'taco', conceptually, is fit to replace the prefix of those namespaces, and that (as we discussed that one time on the call), the one that uses it as the suffix is actually erroneous.
It feels like it wants to be:
- @taco/shared
- @taco/pre
- @taco/cbd
...and yes, removing the ts from the name makes sense. But if we do that, how do we distinguish this repo from nucypher/nucypher ?
(Are we all the way back around to a discussion of them becoming the same repo?)
Should we do a holistic thought exercise about what other repos names will be; will nucypher, nucypher-porter, nucypher-contracts remain? Then we can see if taco for this repos still makes sense.
Sorry if my message sounds challenging, but I think it's a good time to rethink the repos and product naming.
In the last few years, the Nucypher ecosystem has changed a lot: Threshold merge, nucypher as an application under the Threshold umbrella, now the nucypher network is shared with Threshold also, the change of direction to follow the TACo direction instead of PRE... and if you ask me, my opinion is that the repositories naming hasn't followed these changes and it seems to be a little bit misaligned with the current status of the protocol.
Maybe I'm not the best person to rename them since I don't have the background that other nucypherinos have, but my suggestion would be something similar to:
-
Nucypher -> the company
-
nucypher-ts -> taco || taco-client || taco-api
-
nucypher-core -> taco-core
-
nucypher -> taco-network
-
nucypher-porter -> porter || network-porter
-
nucypher-contracts -> solidity-contracts
I'm aware that I am missing all the nucypher/PRE background. But, what is the real importance of this from a traction/market perspective?
Sorry if my message sounds challenging
Challenging is strongly encouraged 👏 .
Great points and I like the naming options you provided above, and it addresses what I was referring to regarding a holistic view of naming.
Minor suggestions:
- nucypher-porter -> porter || taco-porter
|| network-porter - nucypher-contracts -> taco-contracts
I have nothing against renaming all namespaces (i.e. going from nucypher-* in our projects, packages, etc.). Still, I also want to communicate that the titular TACo refers to taco, and the pre is/isn't a subset of TACo.
I guess we already covered it to some extent, i.e. there is a good separation between pre and taco packages. As far as the nucypher-ts repo goes, this difference is documented. We also wanted to document that in GitBook docs, in the future.
I have to be honest: I have a lot of personal (maybe emotional?) resistance to renaming stuff that's not absolutely necessary. IMHO, this repo should be renamed because it's the flagship representative of the TACo API, the repo and package that we expect to be used the most by our adopters, and the one that we are referencing the most in our documentation. By the way, I think that eventually, the NPM package should be @threshold-network/taco (maybe we can start now?).
Other repositories, like nucypher-porter, nucypher-core, and nucypher-contracts are practically non user-facing, and deal mostly with tooling, so I don't see any compelling reason for renaming, other than consistency (although I admit that's a very decent reason). The case of nucypher/nucypher is special, since it does have an external audience (stakers and Python devs), but probably much more reduced than the TS API (if the TS API has a lower audience then it means TACo has sort of failed). nucypher/nucypher is also special because it's the container where we as a team have poured thousands of hours of work for 6 years, and I find it personally hard to rename (yes, I'm a sentimental guy!); having said that, if the broad consensus is to rename also nucypher/nucypher, that's fine.
The reason why the taco package was published as @nucypher/taco was that I didn't have access to the @threshold-network namespace. And also we keep everything else in @nucypher, so it made sense. But eventually, I think we want to move to @threshold-network, so releasing taco is an opportunity to do that.
As for renaming, I yield back - I don't think it's necessary, but I can be convinced otherwise. On that note, as today's exercise with the demo showed, we need more eyes on user-facing stuff. So IMHO we could redirect some of our energies to docs, examples, demos, API design, etc, where it has more impact than renaming stuff.
So, currently, we have three different notions of how to use the suffix of a repo name:
nucypher-ts- languagenucypher-core- layer geographynucypher-contracts- utility
Given our (awesome and strong!) proclivity to flex to different lingual needs every few months, it's dangerous and unserious to use language names in production repos (though they're great for stub repos where people want to experiment, which is of course how nucypher-ts began).
Layer geography is probably the most interesting and informative scheme, but it suffers from the problem that so much of what we're doing here is to introduce novel views of how the internet is layered from first principles - this after all is the essence of trust burden transparency, right? In the old internet, we hand-waved away which "servers" and "clients" that you have to trust. Our critique is, in large part, a rethinking of who is a "server" and who is a "client" and who is a "node" and how much trust you have to place in each party in your ecosystem. This means that we need for different layers to be represented differently in different codebases, for different purposes.
So we are left with the other good choice: naming repos based on their utility (ie, how does this repo fit into the ecosystem).
To this end, I propose (as we just discussed):
nucypher-ts-=>taco-webnucypher-core-=>taco-commonnucypher-contracts-=>taco-contracts
Ideally, to my way of thinking, this matches with:
nucypher-=>taco
...and the message we send: "here's where you look to see the canonical, reference notion of what constitutes a test pass or failure for a given unit of logic."
And further down the road, I imagine the others becoming submodules, with the pinned version for each submodule, for a given version of the parent module, representing the version spec we have discussed.
Finally, to complete the hierarchy, we rename the npm packages:
nucypher/taco-=>taco/cbdnucypher/pre-=>taco/prenucypher/shared-=>taco/shared