Cyphrme / Coze

Coze is a cryptographic JSON messaging specification.
https://cyphr.me/coze
BSD 3-Clause "New" or "Revised" License
106 stars 3 forks source link

Make new repositories for the specification and implementations #13

Closed zamicol closed 1 year ago

zamicol commented 1 year ago

Edit:

Coze repository organization

- 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...

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:

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.