4 ms·

One thing I'm not sure about when reading their policy is what'll happen in another kik situation. If someone were to claim the scope Microsoft (for example) th

One thing I'm not sure about when reading their policy is what'll happen in another kik situation. If someone were to claim the scope Microsoft (for example) that had no relation to Microsoft and then Microsoft came along and wanted the scope what would happen? If MS got the scope what would happen to the packages in that scope, or if MS didn't get it what is done to clearly communicate that this is an unofficial account (presumably) asking on MS' behalf? In this early on period I'd expect a lot of people to claim the scopes of notable companies and these companies might take issue with that if they choose to use jsr down the line.

kwhinnery 3y ago
We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name). So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.
- hjadal 3y ago
  In the example of "@cocacola/foo" would it allow for the "@cocacola/foo" package to be updated with new versions by the new owners? Or would the foo package essentially be archived and read-only from this point on?
  - kwhinnery 3y ago
    The new scope owner would be able to update "@cocacola/foo" and publish new versions (previous versions would be unaffected).
- diggan 3y ago
  > but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name). So you're basically committing to repeating the Kik drama? For reference: https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_module_name https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_modu... It would be great to find a way of structuring these registries/repositories in a way so there wouldn't be any name collisions, and also avoid the built-in support for companies to take names away from individuals.
  - kwhinnery 3y ago
    Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1]. As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2]. [1] https://jsr.io/docs/immutability https://jsr.io/docs/immutability [2] https://jsr.io/go/moderator https://jsr.io/go/moderator
  - int_19h 3y ago
    There are only two ways to do it: 1. Use UUIDs. 2. Use some pre-existing centralized name registry (e.g. domain names). I don't know why the JS ecosystem is so resistant to either solution. Both are proven options (#1 used by COM, #2 used by Java). They do mean longer package names, but surely that's a small price to pay for a resilient future-proof solution? And besides, who really cares about long dependency names and why?
deleted 3y ago
[deleted]
postalrat 3y ago
I'd suggest they require a DNS entry to use a scope and all scopes have a one to one relationship with a domain.
- lucacasonato 3y ago
  What happens if the domain registration expires? Scope takeover?
  - deredede 3y ago
    Domain expiration is rare, and virtually only happens when the related projects are dead anyways; freeze existing packages (no more updates until the original key for the domain comes back online, with manual override by registry administrators for edge cases) and have a reasonable waiting period (a couple of months to a year) before allowing the new owner to use the namespace (with different project names within).
    - lucacasonato 3y ago
      How do you deal with individuals that may not have a domain? What do you tie their scope to?
      - WorldMaker 3y ago
        This is a joke: GitHub account name. If it is good enough for Golang, …
        lucacasonato 3y ago
        Doesn't this get us right back to where we started from? Where you don't want users to be able to register arbitrary names :)
        WorldMaker 3y ago
        Correct. That's a big part of why it was a joke. (It's also a contributing factor in why I wonder if golang itself is in fact a prank.)

kwhinnery 3y ago

We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name). So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.

hjadal 3y ago
In the example of "@cocacola/foo" would it allow for the "@cocacola/foo" package to be updated with new versions by the new owners? Or would the foo package essentially be archived and read-only from this point on?
- kwhinnery 3y ago
  The new scope owner would be able to update "@cocacola/foo" and publish new versions (previous versions would be unaffected).
diggan 3y ago
> but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name). So you're basically committing to repeating the Kik drama? For reference: https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_module_name https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_modu... It would be great to find a way of structuring these registries/repositories in a way so there wouldn't be any name collisions, and also avoid the built-in support for companies to take names away from individuals.
- kwhinnery 3y ago
  Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1]. As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2]. [1] https://jsr.io/docs/immutability https://jsr.io/docs/immutability [2] https://jsr.io/go/moderator https://jsr.io/go/moderator
- int_19h 3y ago
  There are only two ways to do it: 1. Use UUIDs. 2. Use some pre-existing centralized name registry (e.g. domain names). I don't know why the JS ecosystem is so resistant to either solution. Both are proven options (#1 used by COM, #2 used by Java). They do mean longer package names, but surely that's a small price to pay for a resilient future-proof solution? And besides, who really cares about long dependency names and why?

deleted 3y ago

[deleted]

postalrat 3y ago

I'd suggest they require a DNS entry to use a scope and all scopes have a one to one relationship with a domain.

lucacasonato 3y ago
What happens if the domain registration expires? Scope takeover?
- deredede 3y ago
  Domain expiration is rare, and virtually only happens when the related projects are dead anyways; freeze existing packages (no more updates until the original key for the domain comes back online, with manual override by registry administrators for edge cases) and have a reasonable waiting period (a couple of months to a year) before allowing the new owner to use the namespace (with different project names within).
  - lucacasonato 3y ago
    How do you deal with individuals that may not have a domain? What do you tie their scope to?
    - WorldMaker 3y ago
      This is a joke: GitHub account name. If it is good enough for Golang, …
      - lucacasonato 3y ago
        Doesn't this get us right back to where we started from? Where you don't want users to be able to register arbitrary names :)
        WorldMaker 3y ago
        Correct. That's a big part of why it was a joke. (It's also a contributing factor in why I wonder if golang itself is in fact a prank.)