You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Coze ("Core"/main specification and the Go Coze reference implementation)
- Coze_x (Coze extended)
- Coze_go_x (Go implementation of extended features)
- Coze_js (Javascript implementation)
- Coze_js_x (Javascript implementation of extended)
- etc...
Discussion on the main spec or the Go reference implementation should go into Coze, aka "core".
Discussion on "x" design goes into Coze_x. Future discussion on
implementing/supporting new algorithms also goes into x, as implementations of
new algorithms will live in x first before being adopted by core. Only
established and widely adopted algorithms are eventually included into core.
Every language that implements Coze should be in it's own respective language
specific directory (except the Go reference implementation).
It is suggested that implementation of "x" features should go into the
appropriate language "x" repository.
Old
This repository should be split into a few different repositories. It is usually good practice to split out documents from code so that developers aren't burdened with reviewing changes to the repository.
I suggest the following repositories:
coze
coze_go
coze_go_experimental
coze_js
coze_js_experimental
etc...
This unfortunately would probably require renaming "Coze" to "coze". "coze" would be for the main spec (README.md) which defines Coze Core, and also documents, discussion, proposals, best practices, and FAQ. Github appears to be a good place for discussion and document modification, but we don't want a large number of developers worrying about the changes happening in the repository due to simple document modification.
Experimental is for new algorithms and useful Coze related libraries not in the core spec (normal would be one such library). New algorithms are allowed time to mature first in experimental before getting accepted into "Core".
The plan for Coze Core
The only planned expansion of "Coze Core", the implementation and specification that currently lives in this repo, is adding new algorithms. No changes are currently planned to the spec other than per algorithm adjustments. However, we wanted to give this more time and receive more feedback before we made a more final decision.
There will be minor tweaks on a per algorithm basis for Coze Core. For example, @LoupVaillant suggested doing the following when handling Ed25519:
My choice for Monocypher was to do the same as Zebra:
Reject any S that equals or exceeds the order of the curve.
Accept low-order A and R.
Accept non-canonical A and R.
Use the batch verification equation (it's the forgiving one).
This needs to be specified in Coze Core so that all implementations align.
Alternative Repository Structure
We could do a less dramatic division. However, this is less normalized so I'd advocate for the aforementioned naming.
Coze - The Go (and reference) implementation of Coze. (This repo.)
Edit:
Coze repository organization
Coze
, aka "core".implementing/supporting new algorithms also goes into x, as implementations of
new algorithms will live in x first before being adopted by core. Only
established and widely adopted algorithms are eventually included into core.
specific directory (except the Go reference implementation).
appropriate language "x" repository.
Old
This repository should be split into a few different repositories. It is usually good practice to split out documents from code so that developers aren't burdened with reviewing changes to the repository.
I suggest the following repositories:
etc...
This unfortunately would probably require renaming "Coze" to "coze". "coze" would be for the main spec (README.md) which defines Coze Core, and also documents, discussion, proposals, best practices, and FAQ. Github appears to be a good place for discussion and document modification, but we don't want a large number of developers worrying about the changes happening in the repository due to simple document modification.
Experimental is for new algorithms and useful Coze related libraries not in the core spec (
normal
would be one such library). New algorithms are allowed time to mature first in experimental before getting accepted into "Core".The plan for Coze Core
The only planned expansion of "Coze Core", the implementation and specification that currently lives in this repo, is adding new algorithms. No changes are currently planned to the spec other than per algorithm adjustments. However, we wanted to give this more time and receive more feedback before we made a more final decision.
There will be minor tweaks on a per algorithm basis for Coze Core. For example, @LoupVaillant suggested doing the following when handling Ed25519:
This needs to be specified in Coze Core so that all implementations align.
Alternative Repository Structure
We could do a less dramatic division. However, this is less normalized so I'd advocate for the aforementioned naming.
The text was updated successfully, but these errors were encountered: