Lann Martin (Feb 06 2023 at 20:37): Lann Martin (Feb 06 2023 at 20:37):I've waved my hands at the idea that a public-good registry could have some kind of externally-enforced namespacing: domain names, public repos, etc. How do we generally feel about that idea vs a Cargo-style first-come-first-serve flat namespace?
Lann Martin (Feb 06 2023 at 20:47):Concrete ideas: require a prefix of either a well-known public forge e.g. gitlab.com/lann/package or a DNS name verified somehow (probably just manually, initially) e.g. bytecodealliance.org/package. We wouldn't have to do anything special for an initial semi-private instance but it would determine the naming convention.
Peter Huene (Feb 06 2023 at 21:16):I don't think we want to repeat the mistake of having a flat namespace, so I just assumed we were going to go with a user/org name namespace scheme a la Docker. The policy around the user/org name would be first-come-first-served, but explicitly reserve the right to reclaim a user/org name that someone holds legal claim / trademark over (with perhaps some explicit dispute process).
To me, the Docker way makes a lot of sense. In terms of a "uniquely identifiable package name", it'd be prefixed with the registry it came from in some format (warg url?).
I'm completely open to alternatives, but we should keep in mind that not everyone publishing to a registry is part of a larger organization or company.
Lann Martin (Feb 06 2023 at 21:37):reclaim a user/org name that someone holds legal claim / trademark over
is a big part of what I don't love about the first-come namespace approach, but I would certainly take it over no namespace
we should keep in mind that not everyone publishing to a registry is part of a larger organization or company
Right, I don't think any solution should depend on owning a DNS name; requiring an account at a well-known forge seems like a low-enough bar to me, though it makes package names subjectively ugly
Lann Martin (Feb 07 2023 at 15:48):Wrote up some thoughts / options: https://hackmd.io/@lann/B1M7L1epj
Can discuss tomorrow too.
Robin Brown (Feb 07 2023 at 15:51):Does this proposal have any implications for warg as a protocol other than that names may need delimiters like /?
Lann Martin (Feb 07 2023 at 15:52):This form of namespacing is only meaningful for registry policy enforcement; it has no meaning in the Warg protocol. There may be additional outer namespacing by the “owning” registry itself to facilitate federation.
:smile:
Robin Brown (Feb 07 2023 at 15:53):/-delimited names will require some changes to the API. We currently use names as url parameters in a way that I don't think can handle names with slashes.
Robin Brown (Feb 07 2023 at 15:55):How much does this proposal, if at all, apply to the initial dogfood registry?
Robin Brown (Feb 07 2023 at 15:57):The plan initially iirc is to only allow BCA projects to publish anyway, so I think we can start a lot simpler.
Lann Martin (Feb 07 2023 at 15:59):If we know what we want to do we can start off prefixing those initial packages (without policy enforcement)
Robin Brown (Feb 07 2023 at 16:00):I worry that implies a level of continuity/stability across preview registry protocols/instances that we don't want.
Lann Martin (Feb 07 2023 at 16:01):We can use bytecodealliance-preview/* if we want :shrug:
Robin Brown (Feb 07 2023 at 16:04):Maybe we should just give the entire dogfood registry as a whole a name/domain that makes it very clear that we might blow it away and repopulate it whenever we feel. In fact, it might make sense to give the new registry a new subdomain each time we do so that its semantically a new registry and doesn't confuse clients/monitors.
Robin Brown (Feb 07 2023 at 16:05):e.g. dogfood0.warg.io, dogfood1.warg.io, ...
Robin Brown (Feb 07 2023 at 16:06):We could do preview0, preview1, ... but I think initially we might do that several times before hitting anything that deserves preview status and should increment a preview number.
Robin Brown (Feb 07 2023 at 16:13):@Lann Martin thoughts on using the hash of the package name (LogId) in the url params instead of the name itself?
(that will naturally take care of the slashes for us and keep url lengths in check)
Lann Martin (Feb 07 2023 at 16:15):If that makes sense semantically, sure. Otherwise we can just URL-encode.
Robin Brown (Feb 07 2023 at 16:17):It's something I was already considering and I think it makes sense.
Peter Huene (Feb 08 2023 at 21:24):@Lann Martin thanks for writing that up and sorry for the knee-jerk reaction to what was being discussed without the full context of the document ingested. My reaction was coming from a strong desire to make publishing to the registry as low-barrier as possible for individual developers given this being a nascent registry and hearing the discussion about potentially using ACME challenges for registering a namespace gave me an ignorant :upside_down: face (my misunderstanding was that it is not the only way to do so).
I think this makes a lot of sense at a policy level for the BA registry and to serve as a de facto example for other instance implementations; we can continue to use some canonical form of a package log (not delimited) identifier in the protocol itself.
Lann Martin (Feb 08 2023 at 22:22):I've updated the hackmd to use : as a namespace separator instead of / to avoid confusion with URLs. We've used : in some docs to separate version numbers; the hackmd now suggests @ for that purpose, leading to release references like:
wasi:filesystem@0.1.0example.com:package@0.2.0github.com/lann:dog-facts@0.3.0 Peter Huene (Feb 09 2023 at 00:03):I've updated the cargo-component PR to match (specifically, looking for the last @ in a short-form dependency to treat as the version delimiter)
Last updated: Oct 23 2024 at 20:03 UTC