Hello Chris!
Thank you for offering to explore this area and getting the discussion going. I very much appreciate your efforts in this area!
There is a lot in this post - I will focus my comments on what I think are the most interesting/valuable points to explore further from my own, non-radicle-core-team, point of view:
In general, I think considering NPM packages (or any package that consists of a simple packaging of the source code, as is common in interpreted languages) is perhaps not the best example to help the reader understand which aspects of the term “package” are discussed here. Depending on context, “package” could mean:
- the library itself,
- a binary file that is attached to a specific release of the library,
- the source code that makes up a specific release of the library.
I think it is important to clarify what we want to focus on, so I would recommend we consider the case of a compiled language (java, golang, rust, etc. etc.) which will help clarify that point further. For example, in one of these languages, a specific release of the library might have several different packages attached to it (i.e. different binary files - e.g. for different platforms).
As a second point, I am not sure how the blockchain approach improves upon the proposed solution based on Radicle’s Collaborative Objects in the other thread. I mean… sure, it does offer a solution to the problem, but it introduces a new (massive) dependency on a blockchain that Radicle doesn’t have today. Collaborative Objects on the other hand will be the basis of other entities like e.g. Issues and Patch Proposals, and Releases (which would be linked to a set of (signed) binary packages) seem to be a good fit.
I see the 2 threads very closely linked and I think some of what is being discussed here has already been addressed there. Would it make sense to base the discussion herein on top of that perhaps and see specific points where that proposal falls short or points that it doesn’t cover related to signing / security ?