blob: 9bda9f8f6a2193a3725c078b459f33dea149536a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
What to use as package identifiers?
===================================
* Arbitrary names?
* Domains?
* Plain hashes?
- These make it possible to connect a key pair to the hash.
* Hashes with non-controllable pre-image?
* Registry-assigned random?
* Numeric OIDs?
* Registry-assigned but "user-owned" names
- I.e. manual approval process,
- Risky names can be avoiding
- But trademark issues etc. can still happen.
* Registry-owned names
- Registry can and is expected to transfer package ownership
in case of abandoned packages or any other problems.
* Registry as a downstream:
- The registry decides on the names. Naming is a non-issue.
- The registry develops the APIs and pulls in code from other locations.
- I.e. the registry is a downstream of other projects.
Hybrid approach:
* Have pubkey/pubkey-set/UUID based "registry root"
* Have this root as a namespace for package names (and/or class names?)
* Could lead to merge conflicts if packages are developed in separate
registries.
* With this approach, it has to be possible to depend on packages in
different registries (since some packages might only be available
in some specific registries).
Related:
* Should class names also be IDs?
* Function names.
Arbitrary Names
---------------
* Good names might be squatted early on.
* Good names might be abandoned.
* Good names might be used by packages that shouldn't be the "go-to" package.
* Someone could register `pkg2` (or 3, 4, ...) when `pkg` already exists.
* Or someone could register `pkg` when only `pkg2` exists.
* Risk of trademark or other legal issues.
* Risk of unsuitable names.
* Words can change meaning over time.
* Words can become problematic over time. E.g. "blacklist" vs "blocklist".
Domains
-------
Strictly speaking, domains have all the problems as arbitrary names
(since domains are themselves arbitrarily chosen).
In addition, what should be done when a domain is forcibly transfered
or expired? It is probably undesirable to transfer the package ownership.
Hashes
------
Hashes can be abused by putting something bad in the pre-image,
which will then be impossible to get rid of until everything that
depends on the hash is updated (if this is even possible).
Registry-assigned random
------------------------
* Impossible to start working on packages offline?
- Depends on how the toolchain works.
* Merging registries can lead to ID conflicts.
* Problems with multiple active concurrent registries:
- Possibility of ID conflicts
- Possibility of different IDs for the same package.
* Possibility of split-brain if registry is decentralized.
|
