Fossil SCM

Greatly expanded the simple definition of "blockchain" in the eponymous doc to include more details of common blockchain implementations to draw clearer parallels. This causes our conclusion to flip around from the prior version of this doc, but it's worth keeping the doc because it serves to compare and contrast Fossil to other systems.

wyoung 2020-10-11 06:51 trunk merge
Commit 1ddb400886783aeb8374c504cdcfb66bdbcd9665e69c96cfe6f7c103cb52f893
Parent e32214a40901de4…
11 files changed +469 -32 +5 -5 +1 -1 +1 -1 +1 -1 +1 -1 +3 -3 +5 -5 +1 -1 +2 -2 +2 -2
~ www/blockchain.md ~ www/caps/admin-v-setup.md ~ www/caps/impl.md ~ www/caps/ref.html ~ www/checkin_names.wiki ~ www/fileedit-page.md ~ www/fossil-v-git.wiki ~ www/mirrorlimitations.md ~ www/mkindex.tcl ~ www/permutedindex.html ~ www/shunning.wiki
M www/blockchain.md
+469 -32
--- www/blockchain.md
+++ www/blockchain.md
@@ -1,32 +1,469 @@
1
-# Fossil As Blockchain
2
-
3
-Fossil is a version control system built around blockchain.
4
-
5
-Wikipedia defines "blockchain" as
6
-
7
->
8
- "a growing list of records, called blocks, which are linked using
9
- cryptography. Each block contains a cryptographic hash of the previous
10
- block, a timestamp, and transaction data..." [(1)][]
11
-
12
-
13
-By that definition, Fossil is clearly an implementation of blockchain.
14
-The blocks are ["manifests" artifacts](./fileformat.wiki#manifest).
15
-Each manifest has a SHA1 or SHA3 hash of its parent or parents,
16
-a timestamp, and other transactional data. The repository grows by
17
-adding new manifests onto the list.
18
-
19
-Some people have come to associate blockchain with cryptocurrency, however,
20
-and since Fossil has nothing to do with cryptocurrency, the claim that
21
-Fossil is built around blockchain is met with skepticism. The key thing
22
-to note here is that cryptocurrency implementations like BitCoin are
23
-built around blockchain, but they are not synonymous with blockchain.
24
-Blockchain is a much broader concept. Blockchain is a mechanism for
25
-constructing a distributed ledger of transactions.
26
-Yes, you can use a distributed
27
-ledger to implement a cryptocurrency, but you can also use a distributed
28
-ledger to implement a version control system, and probably many other kinds
29
-of applications as well. Blockchain is a much broader idea than
30
-cryptocurrency.
31
-
32
-[(1)]: https://en.wikipedia.org/wiki/Blockchain
1
+# Is Fossil A Blockchain?
2
+
3
+The Fossil version control system shares a lot of similarities with
4
+other blockchain based technologies, but it also differs from the more common
5
+sorts of blockchains. This document will discuss the term’s
6
+applicability, so you can decide whether applying the term to Fossil
7
+makes sense to you.
8
+
9
+
10
+## The Dictionary Argument
11
+
12
+The [Wikipedia definition of "blockchain"][bcwp] begins:
13
+
14
+>
15
+ "A blockchain…is a growing list of records, called blocks, which are linked using
16
+ cryptography. Each block contains a cryptographic hash of the previous
17
+ block, a timestamp, and transaction data (generally represented as a Merkle tree)."
18
+
19
+
20
+By that partial definition, Fossil is indeed a blockchain. The blocks
21
+are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each
22
+manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to
23
+one or more “parent” blocks. The manifest also contains a timestamp and
24
+the transactional data needed to express a commit to the repository. If
25
+you traverse the Fossil repository from the tips of its [DAG] to the
26
+root by following the parent hashes in each manifest, you will then have
27
+a Merkle tree. Point-for-point, Fossil follows that definition.
28
+
29
+Every change in Fossil starts by adding one or more manifests to
30
+the repository, extending this tree.
31
+
32
+[bcwp]: https://en.wikipedia.org/wiki/Blockchain
33
+[DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
34
+[SHA-1]: https://en.wikipedia.org/wiki/SHA-1
35
+[SHA-3]: https://en.wikipedia.org/wiki/SHA-3
36
+
37
+
38
+
39
+<a id="currency"></a>
40
+## Cryptocurrency
41
+
42
+Because blockchain technology was first popularized as Bitcoin, many
43
+people associate the term with cryptocurrency. Fossil has nothing to do
44
+with cryptocurrency, so a claim that “Fossil is a blockchain” may fail
45
+to communicate the speaker’s concepts clearly due to conflation with
46
+cryptocurrency.
47
+
48
+Cryptocurrency has several features and requirements that Fossil doesn’t
49
+provide, either because it doesn’t need them or because we haven’t
50
+gotten around to creating the feature. Whether these are essential to
51
+the definition of “blockchain” and thus disqualify Fossil as a blockchain
52
+is for you to decide.
53
+
54
+Cryptocurrencies must prevent three separate types of fraud to be useful:
55
+
56
+* **Type 1** is modification of existing currency. To draw an analogy
57
+ to paper money, we wish to prevent someone from using green and
58
+ black markers to draw extra zeroes on a US $10 bill so that it
59
+ claims to be a $100 bill. Cryptocurrencies apply digital signatures
60
+ to each block so that a given block of currency’s face value cannot
61
+ be changed after it is created. The [proof-of-work][pow] aspect
62
+ prevents the creator from setting its initial value fraudulently.
63
+
64
+* **Type 2** is making new counterfeit $10 bills that look
65
+ sufficiently like the original to pass in commerce. Cryptocurrencies
66
+ chain blocks together and establish a sufficiently hard work problem
67
+ to create new currency that Type 2 frauds are impractical short of
68
+ doing the actual mining needed to produce legitimate cryptocurrency.
69
+
70
+* **Type 3** is double-spending existing legitimate cryptocurrency.
71
+ There is no analogy in paper money due to its physical form; it is a
72
+ problem unique to digital currency due to its infinitely-copyable
73
+ nature. Cryptocurrencies prevent Type 3 frauds by making the
74
+ *prior* owner of a block sign it over to the new owner. To avoid an
75
+ O(n²) auditing problem as a result, cryptocurrencies also use a
76
+ chain of hashes to make checking for double-spending quick and easy.
77
+
78
+How does all of this compare to Fossil?
79
+
80
+1. <a id="signatures"></a>**Signatures.** Cryptocurrencies use a chain
81
+ of [digital signatures][dsig] to prevent Type 1 and Type 3 frauds. This
82
+ chain forms an additional link between the blocks, separate from the
83
+ hash chain that applies an ordering and lookup scheme to the blocks.
84
+ [_Blockchain: Simple Explanation_][bse] explains this “hash chain”
85
+ vs. “block chain” distinction in more detail.
86
+
87
+ Fossil has [a disabled-by-default feature][cs] to call out to an
88
+ external copy of [PGP] or [GPG] to sign commit manifests before
89
+ inserting them into the repository. You may wish to couple that with
90
+ a server-side [after-receive hook][arh] to reject unsigned commits.
91
+
92
+ Although there are several distinctions you can draw between the way
93
+ Fossil’s commit signing scheme works and the way block signing works
94
+ in cryptocurrencies, only one is of material interest for our
95
+ purposes here: Fossil commit signatures apply only to a single
96
+ commit. Fossil does not sign one commit over to the next “owner” of
97
+ that commit in the way that a blockchain-based cryptocurrency must
98
+ when transferring currency from one user to another, beacuse there
99
+ is no useful analog to the double-spending problem in Fossil. The
100
+ closest you can come to this is double-insert of commits into the
101
+ blockchain, which we’ll address shortly.
102
+
103
+ What Fossil commit signatures actually do is provide in-tree forgery
104
+ prevention, both Type 1 and Type 2. You cannot modify existing
105
+ commits (Type 1 forgery) because you do not have the original
106
+ committer’s private signing key, and you cannot forge new commits
107
+ attesting to come from some other trusted committer (Type 2) because
108
+ you don’t have any of their private signing keys, either.
109
+ Cyrptocurrencies also use the work problem to prevent Type 2
110
+ forgeries, but the application of that to Fossil is a matter we get
111
+ to [later](#work).
112
+
113
+ If Fossil signatures prevent Type 1 and Type 2 frauds, why then are
114
+ they not enabled by default? Because they are defense-in-depth
115
+ measures, not the minimum sufficient measures needed to prevent
116
+ repository fraud in Fossil. Fossil provides its primary protections
117
+ through other means.
118
+
119
+ Although you have complete control over the contents of your local
120
+ Fossil repository clone, you cannot perform Type 1 forgery on its
121
+ contents short of executing a [preimage attack][prei] on the hash
122
+ algorthm. ([SHA3-256][SHA-3] by default in the current version of
123
+ Fossil.) Even if you could, Fossil’s sync protocol will prevent the
124
+ modification from being pushed into another repository: the remote
125
+ Fossil instance says, “I’ve already got that one, thanks,” and
126
+ ignores the push. Thus, short of breaking into the remote server
127
+ and modifying the repository in place, you couldn’t even make use of
128
+ a preimage attack if you had that power. This is an attack on the
129
+ server itself, not on Fossil’s data structures, so while it is
130
+ useful to think through this problem, it is not helpful to answering
131
+ our questions here.
132
+
133
+ The Fossil sync protocol also prevents the closest analog to Type 3
134
+ frauds in Fossil: copying a commit manifest in your local repo clone
135
+ won’t result in a double-commit on sync.
136
+
137
+ In the absence of digital signatures, Fossil’s [RBAC system][caps]
138
+ restricts Type 2 forgery to trusted committers. Thus once again
139
+ we’re reduced to an infosec problem, not a data structure design
140
+ question. (Inversely, enabling commit clearsigning is a good idea
141
+ if you have committers on your repo whom you don’t trust not to
142
+ commit Type 2 frauds. But let us be clear: your choice of setting
143
+ does not answer the question of whether Fossil is a blockchain.)
144
+
145
+ If you’re wondering why Fossil’s current commit signing feature is
146
+ not enabled by default and why it doesn’t verify signatures on
147
+ commits, it is because Fossil is not itself a [PKI], and there is no
148
+ way for regular users of Fossil to link it to a PKI, since doing so
149
+ would likely result in an unwanted [PII] disclosure. There is no
150
+ email address in a Fossil commit manifest that you could use to
151
+ query one of the public PGP keyservers, for example. It therefore
152
+ becomes a local policy matter as to whether you even *want* to have
153
+ signatures, because they’re not without their downsides.
154
+
155
+2. <a id="work"></a>**Work Contests.** Cryptocurrencies prevent forgery
156
+ by setting up some sort of contest that ensures that new coins can come
157
+ into existence only by doing some difficult work task. This “mining”
158
+ activity results in a coin that took considerable work to create,
159
+ which thus has economic value by being a) difficult to re-create,
160
+ and b) resistant to [debasement][dboc].
161
+
162
+ Fossil repositories are most often used to store the work product of
163
+ individuals, rather than cryptocoin mining machines. There is
164
+ generally no contest in trying to produce the most commits. There
165
+ may be an implicit contest to produce the “best” commits, but that
166
+ is a matter of project management, not something that can be
167
+ automatically mediated through objective measures.
168
+
169
+ Incentives to commit to the repository come from outside of Fossil;
170
+ they are not inherent to its nature, as with cryptocurrencies.
171
+ Moreover, there is no useful sense in which we could say that one
172
+ commit “re-creates” another. Commits are generally products of
173
+ individual human intellect, thus necessarily unique in all but
174
+ trivial cases. This is foundational to copyright law.
175
+
176
+3. <a id="lcr"></a>**Longest Chain Rule.** Cryptocurrencies generally
177
+ need some way to distinguish which blocks are legitimate and which
178
+ not. They do this in part by identifying the linear chain with the
179
+ greatest cumulative [work time](#work) as the legitimate chain. All
180
+ blocks not on that linear chain are considered “orphans” and are
181
+ ignored by the cryptocurrency software.
182
+
183
+ It inverse is sometimes called the “51% attack” because a single
184
+ actor would have to do slightly more work than the entire rest of
185
+ the community using a given cryptocurrency in order for their fork
186
+ of the currency to be considered the legitimate fork. This argument
187
+ soothes concerns that a single bad actor could take over the
188
+ network.
189
+
190
+ The closest we can come to that notion in Fossil is the default
191
+ “trunk” branch, but there’s nothing in Fossil that delegitimizes
192
+ other branches just because they’re shorter, nor is there any way in
193
+ Fossil to score the amount of work that went into a commit. Indeed,
194
+ [forks and branches][fb] are *valuable and desirable* things in
195
+ Fossil.
196
+
197
+This much is certain: Fossil is definitely not a cryptocurrency. Whether
198
+this makes it “not a blockchain” is a subjective matter.
199
+
200
+[arh]: ./hooks.md
201
+[bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction
202
+[caps]: ./caps/
203
+[cs]: /help?cmd=clearsign
204
+[dboc]: https://en.wikipedia.org/wiki/Debasement
205
+[dsig]: https://en.wikipedia.org/wiki/Digital_signature
206
+[fb]: ./branching.wiki
207
+[GPG]: https://gnupg.org/
208
+[PGP]: https://www.openpgp.org/
209
+[PII]: https://en.wikipedia.org/wiki/Personal_data
210
+[PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure
211
+[pow]: https://en.wikipedia.org/wiki/Proof_of_work
212
+[prei]: https://en.wikipedia.org/wiki/Preimage_attack
213
+
214
+
215
+
216
+<a id="dlt"></a>
217
+## Distributed Ledgers
218
+
219
+Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If
220
+we can convince ourselves that Fossil is also a distributed
221
+ledger, then we might think of Fossil as a peer technology,
222
+having at least some qualifications toward being considered a blockchain.
223
+
224
+A key tenet of DLT is that records be unmodifiable after they’re
225
+committed to the ledger, which matches quite well with Fossil’s design
226
+and everyday use cases. Fossil puts up multiple barriers to prevent
227
+modification of existing records and injection of incorrect records.
228
+
229
+Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean
230
+Fossil cannot be a distributed ledger?
231
+
232
+These features only remove existing commits from the repository. If you want a
233
+currency analogy, they are ways to burn a paper bill or to melt a [fiat
234
+coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet”
235
+file, effectively destroying money in a similar way. These features
236
+do not permit forgery of either type described above: you can’t use them
237
+to change the value of existing commits (Type 1) or add new commits to
238
+the repository (Type 2).
239
+
240
+What if we removed those features from Fossil, creating an append-only
241
+Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil
242
+is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means
243
+there can be no guaranteed consensus on the content of the ledger at any
244
+given time. If you had an AP-mode accounts receivable system, it could
245
+have different bottom-line totals at different sites, because you’ve
246
+cast away “C” to get AP-mode operation.
247
+
248
+Because of this, you could still not guarantee that the command
249
+“`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil
250
+variant would guarantee that everyone got the same result. (Everyone not
251
+partitioned away from the majority of the network at any rate, in the CP
252
+case.)
253
+
254
+What are the prospects for CA-mode or CP-mode Fossil? [We don’t want
255
+CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter
256
+exists, this author believes Fossil is not a distributed ledger in a
257
+technologically defensible sense.
258
+
259
+The most common technologies answering to the label “blockchain” are all
260
+DLTs, so if Fossil is not a DLT, then it is not a blockchain in that
261
+sense.
262
+
263
+[ctap]: ./cap-theorem.md#ap
264
+[ctca]: ./cap-theorem.md#ca
265
+[ctcp]: ./cap-theorem.md#cp
266
+[cap]: https://en.wikipedia.org/wiki/CAP_theorem
267
+[dlt]: https://en.wikipedia.org/wiki/Distributed_ledger
268
+[DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control
269
+[fc]: https://en.wikipedia.org/wiki/Fiat_money
270
+[purge]: /help?cmd=purge
271
+[shun]: ./shunning.wiki
272
+
273
+
274
+<a id="dpc"></a>
275
+## Distributed Partial Consensus
276
+
277
+If we can’t get DLT, can we at least get some kind of distributed
278
+consensus at the level of individual Fossil’s commits?
279
+
280
+Many blockchain based technologies have this property: given some
281
+element of the blockchain, you can make certain proofs that it either is
282
+a legitimate part of the whole blockchain, or it is not.
283
+
284
+Unfortunately, this author doesn’t see a way to do that with Fossil.
285
+Given only one “block” in Fossil’s putative “blockchain” — a commit, in
286
+Fossil terminology — all you can prove is whether it is internally
287
+consistent, that it is not corrupt. That then points you at the parent(s) of that
288
+commit, which you can repeat the exercise on, back to the root of the
289
+DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks]
290
+does.
291
+
292
+If cryptocurrencies worked this way, you wouldn’t be able to prove that
293
+a given cryptocoin was legitimate without repeating the proof-of-work
294
+calculations for the entire cryptocurrency scheme! Instead, you only
295
+need to check a certain number of signatures and proofs-of-work in order
296
+to be reasonably certain that you are looking at a legitimate section of
297
+the whole blockchain.
298
+
299
+What would it even mean to prove that a given Fossil commit “*belongs*”
300
+to the repository you’ve extracted it from? For a software project,
301
+isn’t that tantamount to automatic code review, where the server would
302
+be able to reliably accept or reject a commit based solely on its
303
+content? That sounds nice, but this author believes we’ll need to invent
304
+[AGI] first.
305
+
306
+A better method to provide distributed consensus for Fossil would be to
307
+rely on the *natural* intelligence of its users: that is, distributed
308
+commit signing, so that a commit is accepted into the blockchain only
309
+once some number of users countersign it. This amounts to a code review
310
+feature, which Fossil doesn’t currently have.
311
+
312
+Solving that problem basically requires solving the [PKI] problem first,
313
+since you can’t verify the proofs of these signatures if you can’t first
314
+prove that the provided signatures belong to people you trust. This is a
315
+notoriously hard problem in its own right.
316
+
317
+A future version of Fossil could instead provide [consensus in the CAP
318
+sense][ctcp]. For instance, you could say that if a quorum of servers
319
+all have a given commit, it “belongs.” Fossil’s strong hashing tech
320
+would mean that querying whether a given commit is part of the
321
+“blockchain” would be as simple as going down the list of servers and
322
+sending each an HTTP GET `/info` query for the artifact ID, concluding
323
+that the commit is legitimate once you get enough HTTP 200 status codes back. All of this is
324
+hypothetical, because Fossil doesn’t do this today.
325
+
326
+[AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence
327
+[rcks]: /help?cmd=repo-cksum
328
+
329
+
330
+
331
+<a id="anon"></a>
332
+## Anonymity
333
+
334
+Many blockchain based technologies go to extraordinary lengths to
335
+allow anonymous use of their service.
336
+
337
+As typically configured, Fossil does not: commits synced between servers
338
+always at least have a user name associated with them, which the remote
339
+system must accept through its [RBAC system][caps]. That system can run
340
+without having the user’s email address, but it’s needed if [email
341
+alerts][alert] are enabled on the server. The remote server logs the IP
342
+address of the commit for security reasons. That coupled with the
343
+timestamp on the commit could sufficiently deanonymize users in many
344
+common situations.
345
+
346
+It is possible to configure Fossil so it doesn’t do this:
347
+
348
+* You can give [Write capability][capi] to user category “nobody,” so
349
+ that anyone that can reach your server can push commits into its
350
+ repository.
351
+
352
+* You could give that capability to user category “anonymous” instead,
353
+ which requires that the user log in with a CAPTCHA, but which doesn’t
354
+ require that the user otherwise identify themselves.
355
+
356
+* You could enable [the `self-register` setting][sreg] and choose not to
357
+ enable [commit clear-signing][cs] so that anonymous users could push
358
+ commits into your repository under any name they want.
359
+
360
+On the server side, you can also [scrub] the logging that remembers
361
+where each commit came from.
362
+
363
+That info isn’t transmitted from the remote server on clone or pull.
364
+Instead, the size of the `rcvfrom` table after initial clone is 1: it
365
+contains the remote server’s IP address. On each pull containing new
366
+artifacts, your local `fossil` instance adds another entry to this
367
+table, likely with the same IP address unless the server has moved or
368
+you’re using [multiple remotes][mrep]. This table is far more
369
+interesting on the server side, containing the IP addresses of all
370
+contentful pushes; thus [the `scrub` command][scrub].
371
+
372
+Because Fossil doesn’t
373
+remember IP addresses in commit manifests or require commit signing, it
374
+allows at least *pseudonymous* commits. When someone clones a remote
375
+repository, they don’t learn the email address, IP address, or any other
376
+sort of [PII] of prior committers, on purpose.
377
+
378
+Some people say that private, permissioned blockchains (as you may
379
+imagine Fossil to be) are inherently problematic by the very reason that
380
+they don’t bake anonymous contribution into their core. The very
381
+existence of an RBAC is a moving piece that can break. Isn’t it better,
382
+the argument goes, to have a system that works even in the face of
383
+anonymous contribution, so that you don’t need an RBAC? Cryptocurrencies
384
+do this, for example: anyone can “mine” a new coin and push it into the
385
+blockchain, and there is no central authority restricting the transfer
386
+of cryptocurrency from one user to another.
387
+
388
+We can draw an analogy to encryption, where an algorithm is
389
+considered inherently insecure if it depends on keeping any information
390
+from an attacker other than the key. Encryption schemes that do
391
+otherwise are derided as “security through obscurity.”
392
+
393
+You may be wondering what any of this has to do with whether Fossil is a
394
+blockchain, but that is exactly the point: all of this is outside
395
+Fossil’s core hash-chained repository data structure. If you take the
396
+position that you don’t have a “blockchain” unless it allows anonymous
397
+contribution, with any needed restrictions provided only by the very
398
+structure of the managed data, then Fossil does not qualify.
399
+
400
+Why do some people care about this distinction? Consider Bitcoin,
401
+wherein an anonymous user cannot spam the blockchain with bogus coins
402
+because its [proof-of-work][pow] protocol allows such coins to be
403
+rejected immediately. There is no equivalent in Fossil: it has no
404
+technology that allows the receiving server to look at the content of a
405
+commit and automatically judge it to be “good.” Fossil relies on its
406
+RBAC system to provide such distinctions: if you have a commit bit, your
407
+commits are *ipso facto* judged “good,” insofar as any human work
408
+product can be so judged by a blob of compiled C code. This takes us
409
+back to the [digital ledger question](#dlt), where we can talk about
410
+what it means to later correct a bad commit that got through the RBAC
411
+check.
412
+
413
+We may be willing to accept pseudonymity, rather than full anonymity.
414
+If we configure Fossil as above, either bypassing the RBAC or abandoning
415
+human control over it, scrubbing IP addresses, etc., is it then a public
416
+permissionless blockchain in that sense?
417
+
418
+We think not, because there is no [longest chain rule](#lcr) or anything
419
+like it in Fossil.
420
+
421
+For a fair model of how a Fossil repository might behave under such
422
+conditions, consider GitHub: here one user can fork another’s repository
423
+and make an arbitrary number of commits to their public fork. Imagine
424
+this happens 10 times. How does someone come along later and
425
+*automatically* evaluate which of the 11 forks of the code (counting the
426
+original repository among their number) is the “best” one? For a
427
+computer software project, the best we could do to approximate this
428
+devolves to a [software project cost estimation problem][scost]. These
429
+methods are rather questionable in their own right, being mathematical
430
+judgement values on human work products, but even if we accept their
431
+usefulness, then we still cannot say which fork is better based solely
432
+on their scores under these metrics. We may well prefer to use the fork
433
+of a software program that took *less* effort, being smaller, more
434
+self-contained, and with a smaller attack surface.
435
+
436
+
437
+[alert]: ./alerts.md
438
+[capi]: ./caps/ref.html#i
439
+[mrep]: /help?cmd=remote
440
+[scost]: https://en.wikipedia.org/wiki/Software_development_effort_estimation
441
+[scrub]: /help?cmd=scrub
442
+[sreg]: /help?cmd=self-register
443
+
444
+
445
+# Conclusion
446
+
447
+This author believes it is technologically indefensible to call Fossil a
448
+“blockchain” in any sense likely to be understood by a majority of those
449
+you’re communicating with.
450
+
451
+Within a certain narrow scope, you can defend this usage, but if you do
452
+that, you’ve failed any goal that requires clear communication: it
453
+doesn’t work to use a term in a nonstandard way just because you can
454
+defend it. The people you’re communicating your ideas to must have the
455
+same concept of the terms you use.
456
+
457
+
458
+What term should you use instead? Fossil stores a DAG of hash-chained
459
+commits, so an indisputably correct term is a [Merkle tree][mt], named
460
+after [its inventor][drrm]. You could also use the more generic term
461
+“hash tree.”
462
+
463
+Fossil is a technological peer to many common sorts of blockchain
464
+technology. There is a lot of overlap in concepts and implementation
465
+details, but when speaking of what most people understand as
466
+“blockchain,” Fossil is not that.
467
+
468
+[drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle
469
+[mt]: https://en.wikipedia.org/wiki/Merkle_tree
33470
--- www/blockchain.md
+++ www/blockchain.md
@@ -1,32 +1,469 @@
1 # Fossil As Blockchain
2
3 Fossil is a version control system built around blockchain.
4
5 Wikipedia defines "blockchain" as
6
7 >
8 "a growing list of records, called blocks, which are linked using
9 cryptography. Each block contains a cryptographic hash of the previous
10 block, a timestamp, and transaction data..." [(1)][]
11
12
13 By that definition, Fossil is clearly an implementation of blockchain.
14 The blocks are ["manifests" artifacts](./fileformat.wiki#manifest).
15 Each manifest has a SHA1 or SHA3 hash of its parent or parents,
16 a timestamp, and other transactional data. The repository grows by
17 adding new manifests onto the list.
18
19 Some people have come to associate blockchain with cryptocurrency, however,
20 and since Fossil has nothing to do with cryptocurrency, the claim that
21 Fossil is built around blockchain is met with skepticism. The key thing
22 to note here is that cryptocurrency implementations like BitCoin are
23 built around blockchain, but they are not synonymous with blockchain.
24 Blockchain is a much broader concept. Blockchain is a mechanism for
25 constructing a distributed ledger of transactions.
26 Yes, you can use a distributed
27 ledger to implement a cryptocurrency, but you can also use a distributed
28 ledger to implement a version control system, and probably many other kinds
29 of applications as well. Blockchain is a much broader idea than
30 cryptocurrency.
31
32 [(1)]: https://en.wikipedia.org/wiki/Blockchain
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
33
--- www/blockchain.md
+++ www/blockchain.md
@@ -1,32 +1,469 @@
1 # Is Fossil A Blockchain?
2
3 The Fossil version control system shares a lot of similarities with
4 other blockchain based technologies, but it also differs from the more common
5 sorts of blockchains. This document will discuss the term’s
6 applicability, so you can decide whether applying the term to Fossil
7 makes sense to you.
8
9
10 ## The Dictionary Argument
11
12 The [Wikipedia definition of "blockchain"][bcwp] begins:
13
14 >
15 "A blockchain…is a growing list of records, called blocks, which are linked using
16 cryptography. Each block contains a cryptographic hash of the previous
17 block, a timestamp, and transaction data (generally represented as a Merkle tree)."
18
19
20 By that partial definition, Fossil is indeed a blockchain. The blocks
21 are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each
22 manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to
23 one or more “parent” blocks. The manifest also contains a timestamp and
24 the transactional data needed to express a commit to the repository. If
25 you traverse the Fossil repository from the tips of its [DAG] to the
26 root by following the parent hashes in each manifest, you will then have
27 a Merkle tree. Point-for-point, Fossil follows that definition.
28
29 Every change in Fossil starts by adding one or more manifests to
30 the repository, extending this tree.
31
32 [bcwp]: https://en.wikipedia.org/wiki/Blockchain
33 [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
34 [SHA-1]: https://en.wikipedia.org/wiki/SHA-1
35 [SHA-3]: https://en.wikipedia.org/wiki/SHA-3
36
37
38
39 <a id="currency"></a>
40 ## Cryptocurrency
41
42 Because blockchain technology was first popularized as Bitcoin, many
43 people associate the term with cryptocurrency. Fossil has nothing to do
44 with cryptocurrency, so a claim that “Fossil is a blockchain” may fail
45 to communicate the speaker’s concepts clearly due to conflation with
46 cryptocurrency.
47
48 Cryptocurrency has several features and requirements that Fossil doesn’t
49 provide, either because it doesn’t need them or because we haven’t
50 gotten around to creating the feature. Whether these are essential to
51 the definition of “blockchain” and thus disqualify Fossil as a blockchain
52 is for you to decide.
53
54 Cryptocurrencies must prevent three separate types of fraud to be useful:
55
56 * **Type 1** is modification of existing currency. To draw an analogy
57 to paper money, we wish to prevent someone from using green and
58 black markers to draw extra zeroes on a US $10 bill so that it
59 claims to be a $100 bill. Cryptocurrencies apply digital signatures
60 to each block so that a given block of currency’s face value cannot
61 be changed after it is created. The [proof-of-work][pow] aspect
62 prevents the creator from setting its initial value fraudulently.
63
64 * **Type 2** is making new counterfeit $10 bills that look
65 sufficiently like the original to pass in commerce. Cryptocurrencies
66 chain blocks together and establish a sufficiently hard work problem
67 to create new currency that Type 2 frauds are impractical short of
68 doing the actual mining needed to produce legitimate cryptocurrency.
69
70 * **Type 3** is double-spending existing legitimate cryptocurrency.
71 There is no analogy in paper money due to its physical form; it is a
72 problem unique to digital currency due to its infinitely-copyable
73 nature. Cryptocurrencies prevent Type 3 frauds by making the
74 *prior* owner of a block sign it over to the new owner. To avoid an
75 O(n²) auditing problem as a result, cryptocurrencies also use a
76 chain of hashes to make checking for double-spending quick and easy.
77
78 How does all of this compare to Fossil?
79
80 1. <a id="signatures"></a>**Signatures.** Cryptocurrencies use a chain
81 of [digital signatures][dsig] to prevent Type 1 and Type 3 frauds. This
82 chain forms an additional link between the blocks, separate from the
83 hash chain that applies an ordering and lookup scheme to the blocks.
84 [_Blockchain: Simple Explanation_][bse] explains this “hash chain”
85 vs. “block chain” distinction in more detail.
86
87 Fossil has [a disabled-by-default feature][cs] to call out to an
88 external copy of [PGP] or [GPG] to sign commit manifests before
89 inserting them into the repository. You may wish to couple that with
90 a server-side [after-receive hook][arh] to reject unsigned commits.
91
92 Although there are several distinctions you can draw between the way
93 Fossil’s commit signing scheme works and the way block signing works
94 in cryptocurrencies, only one is of material interest for our
95 purposes here: Fossil commit signatures apply only to a single
96 commit. Fossil does not sign one commit over to the next “owner” of
97 that commit in the way that a blockchain-based cryptocurrency must
98 when transferring currency from one user to another, beacuse there
99 is no useful analog to the double-spending problem in Fossil. The
100 closest you can come to this is double-insert of commits into the
101 blockchain, which we’ll address shortly.
102
103 What Fossil commit signatures actually do is provide in-tree forgery
104 prevention, both Type 1 and Type 2. You cannot modify existing
105 commits (Type 1 forgery) because you do not have the original
106 committer’s private signing key, and you cannot forge new commits
107 attesting to come from some other trusted committer (Type 2) because
108 you don’t have any of their private signing keys, either.
109 Cyrptocurrencies also use the work problem to prevent Type 2
110 forgeries, but the application of that to Fossil is a matter we get
111 to [later](#work).
112
113 If Fossil signatures prevent Type 1 and Type 2 frauds, why then are
114 they not enabled by default? Because they are defense-in-depth
115 measures, not the minimum sufficient measures needed to prevent
116 repository fraud in Fossil. Fossil provides its primary protections
117 through other means.
118
119 Although you have complete control over the contents of your local
120 Fossil repository clone, you cannot perform Type 1 forgery on its
121 contents short of executing a [preimage attack][prei] on the hash
122 algorthm. ([SHA3-256][SHA-3] by default in the current version of
123 Fossil.) Even if you could, Fossil’s sync protocol will prevent the
124 modification from being pushed into another repository: the remote
125 Fossil instance says, “I’ve already got that one, thanks,” and
126 ignores the push. Thus, short of breaking into the remote server
127 and modifying the repository in place, you couldn’t even make use of
128 a preimage attack if you had that power. This is an attack on the
129 server itself, not on Fossil’s data structures, so while it is
130 useful to think through this problem, it is not helpful to answering
131 our questions here.
132
133 The Fossil sync protocol also prevents the closest analog to Type 3
134 frauds in Fossil: copying a commit manifest in your local repo clone
135 won’t result in a double-commit on sync.
136
137 In the absence of digital signatures, Fossil’s [RBAC system][caps]
138 restricts Type 2 forgery to trusted committers. Thus once again
139 we’re reduced to an infosec problem, not a data structure design
140 question. (Inversely, enabling commit clearsigning is a good idea
141 if you have committers on your repo whom you don’t trust not to
142 commit Type 2 frauds. But let us be clear: your choice of setting
143 does not answer the question of whether Fossil is a blockchain.)
144
145 If you’re wondering why Fossil’s current commit signing feature is
146 not enabled by default and why it doesn’t verify signatures on
147 commits, it is because Fossil is not itself a [PKI], and there is no
148 way for regular users of Fossil to link it to a PKI, since doing so
149 would likely result in an unwanted [PII] disclosure. There is no
150 email address in a Fossil commit manifest that you could use to
151 query one of the public PGP keyservers, for example. It therefore
152 becomes a local policy matter as to whether you even *want* to have
153 signatures, because they’re not without their downsides.
154
155 2. <a id="work"></a>**Work Contests.** Cryptocurrencies prevent forgery
156 by setting up some sort of contest that ensures that new coins can come
157 into existence only by doing some difficult work task. This “mining”
158 activity results in a coin that took considerable work to create,
159 which thus has economic value by being a) difficult to re-create,
160 and b) resistant to [debasement][dboc].
161
162 Fossil repositories are most often used to store the work product of
163 individuals, rather than cryptocoin mining machines. There is
164 generally no contest in trying to produce the most commits. There
165 may be an implicit contest to produce the “best” commits, but that
166 is a matter of project management, not something that can be
167 automatically mediated through objective measures.
168
169 Incentives to commit to the repository come from outside of Fossil;
170 they are not inherent to its nature, as with cryptocurrencies.
171 Moreover, there is no useful sense in which we could say that one
172 commit “re-creates” another. Commits are generally products of
173 individual human intellect, thus necessarily unique in all but
174 trivial cases. This is foundational to copyright law.
175
176 3. <a id="lcr"></a>**Longest Chain Rule.** Cryptocurrencies generally
177 need some way to distinguish which blocks are legitimate and which
178 not. They do this in part by identifying the linear chain with the
179 greatest cumulative [work time](#work) as the legitimate chain. All
180 blocks not on that linear chain are considered “orphans” and are
181 ignored by the cryptocurrency software.
182
183 It inverse is sometimes called the “51% attack” because a single
184 actor would have to do slightly more work than the entire rest of
185 the community using a given cryptocurrency in order for their fork
186 of the currency to be considered the legitimate fork. This argument
187 soothes concerns that a single bad actor could take over the
188 network.
189
190 The closest we can come to that notion in Fossil is the default
191 “trunk” branch, but there’s nothing in Fossil that delegitimizes
192 other branches just because they’re shorter, nor is there any way in
193 Fossil to score the amount of work that went into a commit. Indeed,
194 [forks and branches][fb] are *valuable and desirable* things in
195 Fossil.
196
197 This much is certain: Fossil is definitely not a cryptocurrency. Whether
198 this makes it “not a blockchain” is a subjective matter.
199
200 [arh]: ./hooks.md
201 [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction
202 [caps]: ./caps/
203 [cs]: /help?cmd=clearsign
204 [dboc]: https://en.wikipedia.org/wiki/Debasement
205 [dsig]: https://en.wikipedia.org/wiki/Digital_signature
206 [fb]: ./branching.wiki
207 [GPG]: https://gnupg.org/
208 [PGP]: https://www.openpgp.org/
209 [PII]: https://en.wikipedia.org/wiki/Personal_data
210 [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure
211 [pow]: https://en.wikipedia.org/wiki/Proof_of_work
212 [prei]: https://en.wikipedia.org/wiki/Preimage_attack
213
214
215
216 <a id="dlt"></a>
217 ## Distributed Ledgers
218
219 Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If
220 we can convince ourselves that Fossil is also a distributed
221 ledger, then we might think of Fossil as a peer technology,
222 having at least some qualifications toward being considered a blockchain.
223
224 A key tenet of DLT is that records be unmodifiable after they’re
225 committed to the ledger, which matches quite well with Fossil’s design
226 and everyday use cases. Fossil puts up multiple barriers to prevent
227 modification of existing records and injection of incorrect records.
228
229 Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean
230 Fossil cannot be a distributed ledger?
231
232 These features only remove existing commits from the repository. If you want a
233 currency analogy, they are ways to burn a paper bill or to melt a [fiat
234 coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet”
235 file, effectively destroying money in a similar way. These features
236 do not permit forgery of either type described above: you can’t use them
237 to change the value of existing commits (Type 1) or add new commits to
238 the repository (Type 2).
239
240 What if we removed those features from Fossil, creating an append-only
241 Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil
242 is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means
243 there can be no guaranteed consensus on the content of the ledger at any
244 given time. If you had an AP-mode accounts receivable system, it could
245 have different bottom-line totals at different sites, because you’ve
246 cast away “C” to get AP-mode operation.
247
248 Because of this, you could still not guarantee that the command
249 “`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil
250 variant would guarantee that everyone got the same result. (Everyone not
251 partitioned away from the majority of the network at any rate, in the CP
252 case.)
253
254 What are the prospects for CA-mode or CP-mode Fossil? [We don’t want
255 CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter
256 exists, this author believes Fossil is not a distributed ledger in a
257 technologically defensible sense.
258
259 The most common technologies answering to the label “blockchain” are all
260 DLTs, so if Fossil is not a DLT, then it is not a blockchain in that
261 sense.
262
263 [ctap]: ./cap-theorem.md#ap
264 [ctca]: ./cap-theorem.md#ca
265 [ctcp]: ./cap-theorem.md#cp
266 [cap]: https://en.wikipedia.org/wiki/CAP_theorem
267 [dlt]: https://en.wikipedia.org/wiki/Distributed_ledger
268 [DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control
269 [fc]: https://en.wikipedia.org/wiki/Fiat_money
270 [purge]: /help?cmd=purge
271 [shun]: ./shunning.wiki
272
273
274 <a id="dpc"></a>
275 ## Distributed Partial Consensus
276
277 If we can’t get DLT, can we at least get some kind of distributed
278 consensus at the level of individual Fossil’s commits?
279
280 Many blockchain based technologies have this property: given some
281 element of the blockchain, you can make certain proofs that it either is
282 a legitimate part of the whole blockchain, or it is not.
283
284 Unfortunately, this author doesn’t see a way to do that with Fossil.
285 Given only one “block” in Fossil’s putative “blockchain” — a commit, in
286 Fossil terminology — all you can prove is whether it is internally
287 consistent, that it is not corrupt. That then points you at the parent(s) of that
288 commit, which you can repeat the exercise on, back to the root of the
289 DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks]
290 does.
291
292 If cryptocurrencies worked this way, you wouldn’t be able to prove that
293 a given cryptocoin was legitimate without repeating the proof-of-work
294 calculations for the entire cryptocurrency scheme! Instead, you only
295 need to check a certain number of signatures and proofs-of-work in order
296 to be reasonably certain that you are looking at a legitimate section of
297 the whole blockchain.
298
299 What would it even mean to prove that a given Fossil commit “*belongs*”
300 to the repository you’ve extracted it from? For a software project,
301 isn’t that tantamount to automatic code review, where the server would
302 be able to reliably accept or reject a commit based solely on its
303 content? That sounds nice, but this author believes we’ll need to invent
304 [AGI] first.
305
306 A better method to provide distributed consensus for Fossil would be to
307 rely on the *natural* intelligence of its users: that is, distributed
308 commit signing, so that a commit is accepted into the blockchain only
309 once some number of users countersign it. This amounts to a code review
310 feature, which Fossil doesn’t currently have.
311
312 Solving that problem basically requires solving the [PKI] problem first,
313 since you can’t verify the proofs of these signatures if you can’t first
314 prove that the provided signatures belong to people you trust. This is a
315 notoriously hard problem in its own right.
316
317 A future version of Fossil could instead provide [consensus in the CAP
318 sense][ctcp]. For instance, you could say that if a quorum of servers
319 all have a given commit, it “belongs.” Fossil’s strong hashing tech
320 would mean that querying whether a given commit is part of the
321 “blockchain” would be as simple as going down the list of servers and
322 sending each an HTTP GET `/info` query for the artifact ID, concluding
323 that the commit is legitimate once you get enough HTTP 200 status codes back. All of this is
324 hypothetical, because Fossil doesn’t do this today.
325
326 [AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence
327 [rcks]: /help?cmd=repo-cksum
328
329
330
331 <a id="anon"></a>
332 ## Anonymity
333
334 Many blockchain based technologies go to extraordinary lengths to
335 allow anonymous use of their service.
336
337 As typically configured, Fossil does not: commits synced between servers
338 always at least have a user name associated with them, which the remote
339 system must accept through its [RBAC system][caps]. That system can run
340 without having the user’s email address, but it’s needed if [email
341 alerts][alert] are enabled on the server. The remote server logs the IP
342 address of the commit for security reasons. That coupled with the
343 timestamp on the commit could sufficiently deanonymize users in many
344 common situations.
345
346 It is possible to configure Fossil so it doesn’t do this:
347
348 * You can give [Write capability][capi] to user category “nobody,” so
349 that anyone that can reach your server can push commits into its
350 repository.
351
352 * You could give that capability to user category “anonymous” instead,
353 which requires that the user log in with a CAPTCHA, but which doesn’t
354 require that the user otherwise identify themselves.
355
356 * You could enable [the `self-register` setting][sreg] and choose not to
357 enable [commit clear-signing][cs] so that anonymous users could push
358 commits into your repository under any name they want.
359
360 On the server side, you can also [scrub] the logging that remembers
361 where each commit came from.
362
363 That info isn’t transmitted from the remote server on clone or pull.
364 Instead, the size of the `rcvfrom` table after initial clone is 1: it
365 contains the remote server’s IP address. On each pull containing new
366 artifacts, your local `fossil` instance adds another entry to this
367 table, likely with the same IP address unless the server has moved or
368 you’re using [multiple remotes][mrep]. This table is far more
369 interesting on the server side, containing the IP addresses of all
370 contentful pushes; thus [the `scrub` command][scrub].
371
372 Because Fossil doesn’t
373 remember IP addresses in commit manifests or require commit signing, it
374 allows at least *pseudonymous* commits. When someone clones a remote
375 repository, they don’t learn the email address, IP address, or any other
376 sort of [PII] of prior committers, on purpose.
377
378 Some people say that private, permissioned blockchains (as you may
379 imagine Fossil to be) are inherently problematic by the very reason that
380 they don’t bake anonymous contribution into their core. The very
381 existence of an RBAC is a moving piece that can break. Isn’t it better,
382 the argument goes, to have a system that works even in the face of
383 anonymous contribution, so that you don’t need an RBAC? Cryptocurrencies
384 do this, for example: anyone can “mine” a new coin and push it into the
385 blockchain, and there is no central authority restricting the transfer
386 of cryptocurrency from one user to another.
387
388 We can draw an analogy to encryption, where an algorithm is
389 considered inherently insecure if it depends on keeping any information
390 from an attacker other than the key. Encryption schemes that do
391 otherwise are derided as “security through obscurity.”
392
393 You may be wondering what any of this has to do with whether Fossil is a
394 blockchain, but that is exactly the point: all of this is outside
395 Fossil’s core hash-chained repository data structure. If you take the
396 position that you don’t have a “blockchain” unless it allows anonymous
397 contribution, with any needed restrictions provided only by the very
398 structure of the managed data, then Fossil does not qualify.
399
400 Why do some people care about this distinction? Consider Bitcoin,
401 wherein an anonymous user cannot spam the blockchain with bogus coins
402 because its [proof-of-work][pow] protocol allows such coins to be
403 rejected immediately. There is no equivalent in Fossil: it has no
404 technology that allows the receiving server to look at the content of a
405 commit and automatically judge it to be “good.” Fossil relies on its
406 RBAC system to provide such distinctions: if you have a commit bit, your
407 commits are *ipso facto* judged “good,” insofar as any human work
408 product can be so judged by a blob of compiled C code. This takes us
409 back to the [digital ledger question](#dlt), where we can talk about
410 what it means to later correct a bad commit that got through the RBAC
411 check.
412
413 We may be willing to accept pseudonymity, rather than full anonymity.
414 If we configure Fossil as above, either bypassing the RBAC or abandoning
415 human control over it, scrubbing IP addresses, etc., is it then a public
416 permissionless blockchain in that sense?
417
418 We think not, because there is no [longest chain rule](#lcr) or anything
419 like it in Fossil.
420
421 For a fair model of how a Fossil repository might behave under such
422 conditions, consider GitHub: here one user can fork another’s repository
423 and make an arbitrary number of commits to their public fork. Imagine
424 this happens 10 times. How does someone come along later and
425 *automatically* evaluate which of the 11 forks of the code (counting the
426 original repository among their number) is the “best” one? For a
427 computer software project, the best we could do to approximate this
428 devolves to a [software project cost estimation problem][scost]. These
429 methods are rather questionable in their own right, being mathematical
430 judgement values on human work products, but even if we accept their
431 usefulness, then we still cannot say which fork is better based solely
432 on their scores under these metrics. We may well prefer to use the fork
433 of a software program that took *less* effort, being smaller, more
434 self-contained, and with a smaller attack surface.
435
436
437 [alert]: ./alerts.md
438 [capi]: ./caps/ref.html#i
439 [mrep]: /help?cmd=remote
440 [scost]: https://en.wikipedia.org/wiki/Software_development_effort_estimation
441 [scrub]: /help?cmd=scrub
442 [sreg]: /help?cmd=self-register
443
444
445 # Conclusion
446
447 This author believes it is technologically indefensible to call Fossil a
448 “blockchain” in any sense likely to be understood by a majority of those
449 you’re communicating with.
450
451 Within a certain narrow scope, you can defend this usage, but if you do
452 that, you’ve failed any goal that requires clear communication: it
453 doesn’t work to use a term in a nonstandard way just because you can
454 defend it. The people you’re communicating your ideas to must have the
455 same concept of the terms you use.
456
457
458 What term should you use instead? Fossil stores a DAG of hash-chained
459 commits, so an indisputably correct term is a [Merkle tree][mt], named
460 after [its inventor][drrm]. You could also use the more generic term
461 “hash tree.”
462
463 Fossil is a technological peer to many common sorts of blockchain
464 technology. There is a lot of overlap in concepts and implementation
465 details, but when speaking of what most people understand as
466 “blockchain,” Fossil is not that.
467
468 [drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle
469 [mt]: https://en.wikipedia.org/wiki/Merkle_tree
470
M www/caps/admin-v-setup.md
+5 -5
--- www/caps/admin-v-setup.md
+++ www/caps/admin-v-setup.md
@@ -46,12 +46,12 @@
4646
 choices.
4747
4848
 You can also look at the role of Admin from the other direction, up
4949
 through the [user power hierarchy][ucap] rather than down from Setup. An
5050
 Admin user is usually a “super-developer” role, given full control over
51
-the repository’s managed content: versioned artifacts in [the block
52
-chain][bc], [unversioned content][uv], forum posts, wiki articles,
51
+the repository’s managed content: versioned artifacts in [the hash tree][bc],
52
+[unversioned content][uv], forum posts, wiki articles,
5353
 tickets, etc.
5454
5555
 We’ll explore these distinctions in the rest of this document.
5656
5757
 [bc]: ../blockchain.md
@@ -158,17 +158,17 @@
158158
 system][shun] is to clean up after a spammer, and that's
159159
 exactly the sort of administrivia we wish to delegate to Admin users.
160160
161161
 Coupled with the Rebuild button on the same page, an Admin user has
162162
 the power to delete the repository's entire
163
- [blockchain][bc]! This makes this feature a pretty good
163
+ [hash tree][bc]! This makes this feature a pretty good
164164
 razor in deciding whether to grant someone Admin capability: do you
165165
 trust that user to shun Fossil artifacts responsibly?
166166
167167
 Realize that shunning is cooperative in Fossil. As long as there are
168168
 surviving repository clones, an Admin-only user who deletes the
169
- whole blockchain has merely caused a nuisance. An Admin-only user
169
+ whole hash tree has merely caused a nuisance. An Admin-only user
170170
 cannot permanently destroy the repository unless the Setup user has
171171
 been so silly as to have no up-to-date clones.
172172
173173
 * **Moderation**: According to the power hierarchy laid out at the top
174174
 of this article, Admins are greater than Moderators, so control over
@@ -344,11 +344,11 @@
344344
 access on the host system, we almost certainly don't want to
345345
 allow them to change such settings.</p>
346346
347347
 * **SQL**: The Admin → SQL feature allows the Setup user to enter raw
348348
 SQL queries against the Fossil repository via Fossil UI. This not
349
- only allows arbitrary ability to modify the repository blockchain
349
+ only allows arbitrary ability to modify the repository hash tree
350350
 and its backing data tables, it can probably also be used to damage
351351
 the host such as via `PRAGMA temp_store = FILE`.
352352
353353
 * **Tickets**: This section allows input of aribtrary TH1 code that
354354
 runs on the server, affecting the way the Fossil ticketing system
355355
--- www/caps/admin-v-setup.md
+++ www/caps/admin-v-setup.md
@@ -46,12 +46,12 @@
46 choices.
47
48 You can also look at the role of Admin from the other direction, up
49 through the [user power hierarchy][ucap] rather than down from Setup. An
50 Admin user is usually a “super-developer” role, given full control over
51 the repository’s managed content: versioned artifacts in [the block
52 chain][bc], [unversioned content][uv], forum posts, wiki articles,
53 tickets, etc.
54
55 We’ll explore these distinctions in the rest of this document.
56
57 [bc]: ../blockchain.md
@@ -158,17 +158,17 @@
158 system][shun] is to clean up after a spammer, and that's
159 exactly the sort of administrivia we wish to delegate to Admin users.
160
161 Coupled with the Rebuild button on the same page, an Admin user has
162 the power to delete the repository's entire
163 [blockchain][bc]! This makes this feature a pretty good
164 razor in deciding whether to grant someone Admin capability: do you
165 trust that user to shun Fossil artifacts responsibly?
166
167 Realize that shunning is cooperative in Fossil. As long as there are
168 surviving repository clones, an Admin-only user who deletes the
169 whole blockchain has merely caused a nuisance. An Admin-only user
170 cannot permanently destroy the repository unless the Setup user has
171 been so silly as to have no up-to-date clones.
172
173 * **Moderation**: According to the power hierarchy laid out at the top
174 of this article, Admins are greater than Moderators, so control over
@@ -344,11 +344,11 @@
344 access on the host system, we almost certainly don't want to
345 allow them to change such settings.</p>
346
347 * **SQL**: The Admin → SQL feature allows the Setup user to enter raw
348 SQL queries against the Fossil repository via Fossil UI. This not
349 only allows arbitrary ability to modify the repository blockchain
350 and its backing data tables, it can probably also be used to damage
351 the host such as via `PRAGMA temp_store = FILE`.
352
353 * **Tickets**: This section allows input of aribtrary TH1 code that
354 runs on the server, affecting the way the Fossil ticketing system
355
--- www/caps/admin-v-setup.md
+++ www/caps/admin-v-setup.md
@@ -46,12 +46,12 @@
46 choices.
47
48 You can also look at the role of Admin from the other direction, up
49 through the [user power hierarchy][ucap] rather than down from Setup. An
50 Admin user is usually a “super-developer” role, given full control over
51 the repository’s managed content: versioned artifacts in [the hash tree][bc],
52 [unversioned content][uv], forum posts, wiki articles,
53 tickets, etc.
54
55 We’ll explore these distinctions in the rest of this document.
56
57 [bc]: ../blockchain.md
@@ -158,17 +158,17 @@
158 system][shun] is to clean up after a spammer, and that's
159 exactly the sort of administrivia we wish to delegate to Admin users.
160
161 Coupled with the Rebuild button on the same page, an Admin user has
162 the power to delete the repository's entire
163 [hash tree][bc]! This makes this feature a pretty good
164 razor in deciding whether to grant someone Admin capability: do you
165 trust that user to shun Fossil artifacts responsibly?
166
167 Realize that shunning is cooperative in Fossil. As long as there are
168 surviving repository clones, an Admin-only user who deletes the
169 whole hash tree has merely caused a nuisance. An Admin-only user
170 cannot permanently destroy the repository unless the Setup user has
171 been so silly as to have no up-to-date clones.
172
173 * **Moderation**: According to the power hierarchy laid out at the top
174 of this article, Admins are greater than Moderators, so control over
@@ -344,11 +344,11 @@
344 access on the host system, we almost certainly don't want to
345 allow them to change such settings.</p>
346
347 * **SQL**: The Admin → SQL feature allows the Setup user to enter raw
348 SQL queries against the Fossil repository via Fossil UI. This not
349 only allows arbitrary ability to modify the repository hash tree
350 and its backing data tables, it can probably also be used to damage
351 the host such as via `PRAGMA temp_store = FILE`.
352
353 * **Tickets**: This section allows input of aribtrary TH1 code that
354 runs on the server, affecting the way the Fossil ticketing system
355
M www/caps/impl.md
+1 -1
--- www/caps/impl.md
+++ www/caps/impl.md
@@ -62,11 +62,11 @@
6262
 3. You can purposely overwrite good timestamps with bad ones and push
6363
 those changes up to the remote with no interference, even though
6464
 Fossil tries to make that a Setup-only operation.
6565
6666
 All of this falls out of two of Fossil’s design choices: sync is
67
-all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil
67
+all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil
6868
 would have to violate one or both of these principles to filter such
6969
 problems out of incoming syncs.
7070
7171
 We have considered auto-[shunning][shun] “bad” content on sync, but this
7272
 is [difficult][asd] due to [the design of the sync protocol][dsp]. This
7373
--- www/caps/impl.md
+++ www/caps/impl.md
@@ -62,11 +62,11 @@
62 3. You can purposely overwrite good timestamps with bad ones and push
63 those changes up to the remote with no interference, even though
64 Fossil tries to make that a Setup-only operation.
65
66 All of this falls out of two of Fossil’s design choices: sync is
67 all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil
68 would have to violate one or both of these principles to filter such
69 problems out of incoming syncs.
70
71 We have considered auto-[shunning][shun] “bad” content on sync, but this
72 is [difficult][asd] due to [the design of the sync protocol][dsp]. This
73
--- www/caps/impl.md
+++ www/caps/impl.md
@@ -62,11 +62,11 @@
62 3. You can purposely overwrite good timestamps with bad ones and push
63 those changes up to the remote with no interference, even though
64 Fossil tries to make that a Setup-only operation.
65
66 All of this falls out of two of Fossil’s design choices: sync is
67 all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil
68 would have to violate one or both of these principles to filter such
69 problems out of incoming syncs.
70
71 We have considered auto-[shunning][shun] “bad” content on sync, but this
72 is [difficult][asd] due to [the design of the sync protocol][dsp]. This
73
M www/caps/ref.html
+1 -1
--- www/caps/ref.html
+++ www/caps/ref.html
@@ -77,11 +77,11 @@
7777
 <th>d</th>
7878
 <th>n/a</th>
7979
 <td>
8080
 Legacy capability letter from Fossil's forebear <a
8181
 href="http://cvstrac.org/">CVSTrac</a>, which has no useful
82
- meaning in Fossil due to its durable blockchain nature. This
82
+ meaning in Fossil due to the nature of its durable Merkle tree design. This
8383
 letter was assigned by default to Developer in repos created with
8484
 Fossil 2.10 or earlier, but it has no effect in current or past
8585
 versions of Fossil; we recommend that you remove it in case we
8686
 ever reuse this letter for another purpose. See <a
8787
 href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this
8888
--- www/caps/ref.html
+++ www/caps/ref.html
@@ -77,11 +77,11 @@
77 <th>d</th>
78 <th>n/a</th>
79 <td>
80 Legacy capability letter from Fossil's forebear <a
81 href="http://cvstrac.org/">CVSTrac</a>, which has no useful
82 meaning in Fossil due to its durable blockchain nature. This
83 letter was assigned by default to Developer in repos created with
84 Fossil 2.10 or earlier, but it has no effect in current or past
85 versions of Fossil; we recommend that you remove it in case we
86 ever reuse this letter for another purpose. See <a
87 href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this
88
--- www/caps/ref.html
+++ www/caps/ref.html
@@ -77,11 +77,11 @@
77 <th>d</th>
78 <th>n/a</th>
79 <td>
80 Legacy capability letter from Fossil's forebear <a
81 href="http://cvstrac.org/">CVSTrac</a>, which has no useful
82 meaning in Fossil due to the nature of its durable Merkle tree design. This
83 letter was assigned by default to Developer in repos created with
84 Fossil 2.10 or earlier, but it has no effect in current or past
85 versions of Fossil; we recommend that you remove it in case we
86 ever reuse this letter for another purpose. See <a
87 href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this
88
M www/checkin_names.wiki
+1 -1
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -288,8 +288,8 @@
288288
 # [#root | root:BRANCH]
289289
 # [#merge-in | merge-in:BRANCH]
290290
 # [#tag-ts | TAG:timestamp]
291291
 # Full artifact hash or hash prefix.
292292
 # Any other type of symbolic name that Fossil extracts from
293
- blockchain artifacts.
293
+ artifacts.
294294
295295
 <div style="height:40em" id="this-space-intentionally-left-blank"></div>
296296
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -288,8 +288,8 @@
288 # [#root | root:BRANCH]
289 # [#merge-in | merge-in:BRANCH]
290 # [#tag-ts | TAG:timestamp]
291 # Full artifact hash or hash prefix.
292 # Any other type of symbolic name that Fossil extracts from
293 blockchain artifacts.
294
295 <div style="height:40em" id="this-space-intentionally-left-blank"></div>
296
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -288,8 +288,8 @@
288 # [#root | root:BRANCH]
289 # [#merge-in | merge-in:BRANCH]
290 # [#tag-ts | TAG:timestamp]
291 # Full artifact hash or hash prefix.
292 # Any other type of symbolic name that Fossil extracts from
293 artifacts.
294
295 <div style="height:40em" id="this-space-intentionally-left-blank"></div>
296
M www/fileedit-page.md
+1 -1
--- www/fileedit-page.md
+++ www/fileedit-page.md
@@ -56,11 +56,11 @@
5656
 [xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest
5757
5858
 ## `/fileedit` **Works by Creating Commits**
5959
6060
 Thus any edits made via that page become a normal part of the
61
-repository's blockchain.
61
+repository.
6262
6363
 ## `/fileedit` is *Intended* for use with Embedded Docs
6464
6565
 ... and similar text files, and is most certainly
6666
 **not intended for editing code**.
6767
--- www/fileedit-page.md
+++ www/fileedit-page.md
@@ -56,11 +56,11 @@
56 [xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest
57
58 ## `/fileedit` **Works by Creating Commits**
59
60 Thus any edits made via that page become a normal part of the
61 repository's blockchain.
62
63 ## `/fileedit` is *Intended* for use with Embedded Docs
64
65 ... and similar text files, and is most certainly
66 **not intended for editing code**.
67
--- www/fileedit-page.md
+++ www/fileedit-page.md
@@ -56,11 +56,11 @@
56 [xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest
57
58 ## `/fileedit` **Works by Creating Commits**
59
60 Thus any edits made via that page become a normal part of the
61 repository.
62
63 ## `/fileedit` is *Intended* for use with Embedded Docs
64
65 ... and similar text files, and is most certainly
66 **not intended for editing code**.
67
M www/fossil-v-git.wiki
+3 -3
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -230,11 +230,11 @@
230230
231231
 The baseline data structures for Fossil and Git are the same, modulo
232232
 formatting details. Both systems manage a
233233
 [https://en.wikipedia.org/wiki/Directed_acyclic_graph | directed acyclic
234234
 graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree | Merkle
235
-tree] / [./blockchain.md | block chain] structured check-in objects.
235
+tree] structured check-in objects.
236236
 Check-ins are identified by a cryptographic hash of the check-in
237237
 contents, and each check-in refers to its parent via <i>its</i> hash.
238238
239239
 The difference is that Git stores its objects as individual files in the
240240
 <tt>.git</tt> folder or compressed into bespoke
@@ -741,11 +741,11 @@
741741
 repository immediately if successful, even though you haven't tested the
742742
 change yet. It's possible to argue for such a design in a tool like Git
743743
 which doesn't automatically push the change up to its parent, because
744744
 you can still test the change before pushing local changes to the parent
745745
 repo, but in the meantime you've made a durable change to your local Git
746
-repository's blockchain. You must do something drastic like <tt>git
746
+repository. You must do something drastic like <tt>git
747747
 reset --hard</tt> to revert that rebase if it causes a problem. If you
748748
 push your rebased local repo up to the parent without testing first,
749749
 you've now committed the error on a public branch, effectively a
750750
 violation of
751751
 [https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
@@ -759,11 +759,11 @@
759759
760760
 Fossil cannot sensibly work that way because of its default-enabled
761761
 autosync feature. Instead of jumping straight to the commit step, Fossil
762762
 applies the proposed merge to the local working directory only,
763763
 requiring a separate check-in step before the change is committed to the
764
-repository blockchain. This gives you a chance to test the change first,
764
+repository. This gives you a chance to test the change first,
765765
 either manually or by running your software's automatic tests. (Ideally,
766766
 both!)
767767
768768
 Another difference is that because Fossil requires an explicit commit
769769
 for a merge, it makes you give an explicit commit <i>message</i> for
770770
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -230,11 +230,11 @@
230
231 The baseline data structures for Fossil and Git are the same, modulo
232 formatting details. Both systems manage a
233 [https://en.wikipedia.org/wiki/Directed_acyclic_graph | directed acyclic
234 graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree | Merkle
235 tree] / [./blockchain.md | block chain] structured check-in objects.
236 Check-ins are identified by a cryptographic hash of the check-in
237 contents, and each check-in refers to its parent via <i>its</i> hash.
238
239 The difference is that Git stores its objects as individual files in the
240 <tt>.git</tt> folder or compressed into bespoke
@@ -741,11 +741,11 @@
741 repository immediately if successful, even though you haven't tested the
742 change yet. It's possible to argue for such a design in a tool like Git
743 which doesn't automatically push the change up to its parent, because
744 you can still test the change before pushing local changes to the parent
745 repo, but in the meantime you've made a durable change to your local Git
746 repository's blockchain. You must do something drastic like <tt>git
747 reset --hard</tt> to revert that rebase if it causes a problem. If you
748 push your rebased local repo up to the parent without testing first,
749 you've now committed the error on a public branch, effectively a
750 violation of
751 [https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
@@ -759,11 +759,11 @@
759
760 Fossil cannot sensibly work that way because of its default-enabled
761 autosync feature. Instead of jumping straight to the commit step, Fossil
762 applies the proposed merge to the local working directory only,
763 requiring a separate check-in step before the change is committed to the
764 repository blockchain. This gives you a chance to test the change first,
765 either manually or by running your software's automatic tests. (Ideally,
766 both!)
767
768 Another difference is that because Fossil requires an explicit commit
769 for a merge, it makes you give an explicit commit <i>message</i> for
770
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -230,11 +230,11 @@
230
231 The baseline data structures for Fossil and Git are the same, modulo
232 formatting details. Both systems manage a
233 [https://en.wikipedia.org/wiki/Directed_acyclic_graph | directed acyclic
234 graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree | Merkle
235 tree] structured check-in objects.
236 Check-ins are identified by a cryptographic hash of the check-in
237 contents, and each check-in refers to its parent via <i>its</i> hash.
238
239 The difference is that Git stores its objects as individual files in the
240 <tt>.git</tt> folder or compressed into bespoke
@@ -741,11 +741,11 @@
741 repository immediately if successful, even though you haven't tested the
742 change yet. It's possible to argue for such a design in a tool like Git
743 which doesn't automatically push the change up to its parent, because
744 you can still test the change before pushing local changes to the parent
745 repo, but in the meantime you've made a durable change to your local Git
746 repository. You must do something drastic like <tt>git
747 reset --hard</tt> to revert that rebase if it causes a problem. If you
748 push your rebased local repo up to the parent without testing first,
749 you've now committed the error on a public branch, effectively a
750 violation of
751 [https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
@@ -759,11 +759,11 @@
759
760 Fossil cannot sensibly work that way because of its default-enabled
761 autosync feature. Instead of jumping straight to the commit step, Fossil
762 applies the proposed merge to the local working directory only,
763 requiring a separate check-in step before the change is committed to the
764 repository. This gives you a chance to test the change first,
765 either manually or by running your software's automatic tests. (Ideally,
766 both!)
767
768 Another difference is that because Fossil requires an explicit commit
769 for a merge, it makes you give an explicit commit <i>message</i> for
770
M www/mirrorlimitations.md
+5 -5
--- www/mirrorlimitations.md
+++ www/mirrorlimitations.md
@@ -14,14 +14,14 @@
1414
 as Wiki, Tickets, Technotes, and the Forum are not supported in Git,
1515
 so those features are not included in an export.
1616
1717
 Third-party Git based tooling may add some of these features (e.g.
1818
 GitHub, GitLab) but because their data are not stored in the Git
19
-blockchain, there is no single destination for Fossil to convert its
19
+repository, there is no single destination for Fossil to convert its
2020
 equivalent data *to*. For instance, Fossil tickets do not become GitHub
2121
 issues, because that is a proprietary feature of GitHub separate from
22
-Git proper, stored outside the blockchain on the GitHub servers.
22
+Git proper, stored outside the repository on the GitHub servers.
2323
2424
 You can also see the problem in its inverse case: you do not get a copy
2525
 of your GitHub issues when cloning the Git repository. You *do* get the
2626
 Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil
2727
 repo.
@@ -29,14 +29,14 @@
2929
 ## (2) Cherrypick Merges
3030
3131
 The Git client supports cherrypick merges but does not record the
3232
 cherrypick parent(s).
3333
34
-Fossil tracks cherrypick merges in its blockchain and displays
34
+Fossil tracks cherrypick merges in its repository and displays
3535
 cherrypicks in its timeline. (As an example, the dashed lines
3636
 [here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does
37
-not have a way to represent this same information in its blockchain, the
37
+not have a way to represent this same information in its repository, the
3838
 history of Fossil cherrypicks cannot be exported to Git, only their
3939
 direct effects on the managed file data.
4040
4141
 ## (3) Named Branches
4242
@@ -73,11 +73,11 @@
7373
7474
 ## (5) Amendments To Check-ins
7575
7676
 Check-ins are immutable in both Fossil and Git.
7777
 However, Fossil has a mechanism by which tags can be added to
78
-its blockchain to provide after-the-fact corrections to prior check-ins.
78
+its repository to provide after-the-fact corrections to prior check-ins.
7979
8080
 For example, tags can be added to check-ins that correct typos in the
8181
 check-in comment. The original check-in is immutable and so the
8282
 original comment is preserved in addition to the correction. But
8383
 software that displays the check-ins knows to look for the comment-change
8484
--- www/mirrorlimitations.md
+++ www/mirrorlimitations.md
@@ -14,14 +14,14 @@
14 as Wiki, Tickets, Technotes, and the Forum are not supported in Git,
15 so those features are not included in an export.
16
17 Third-party Git based tooling may add some of these features (e.g.
18 GitHub, GitLab) but because their data are not stored in the Git
19 blockchain, there is no single destination for Fossil to convert its
20 equivalent data *to*. For instance, Fossil tickets do not become GitHub
21 issues, because that is a proprietary feature of GitHub separate from
22 Git proper, stored outside the blockchain on the GitHub servers.
23
24 You can also see the problem in its inverse case: you do not get a copy
25 of your GitHub issues when cloning the Git repository. You *do* get the
26 Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil
27 repo.
@@ -29,14 +29,14 @@
29 ## (2) Cherrypick Merges
30
31 The Git client supports cherrypick merges but does not record the
32 cherrypick parent(s).
33
34 Fossil tracks cherrypick merges in its blockchain and displays
35 cherrypicks in its timeline. (As an example, the dashed lines
36 [here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does
37 not have a way to represent this same information in its blockchain, the
38 history of Fossil cherrypicks cannot be exported to Git, only their
39 direct effects on the managed file data.
40
41 ## (3) Named Branches
42
@@ -73,11 +73,11 @@
73
74 ## (5) Amendments To Check-ins
75
76 Check-ins are immutable in both Fossil and Git.
77 However, Fossil has a mechanism by which tags can be added to
78 its blockchain to provide after-the-fact corrections to prior check-ins.
79
80 For example, tags can be added to check-ins that correct typos in the
81 check-in comment. The original check-in is immutable and so the
82 original comment is preserved in addition to the correction. But
83 software that displays the check-ins knows to look for the comment-change
84
--- www/mirrorlimitations.md
+++ www/mirrorlimitations.md
@@ -14,14 +14,14 @@
14 as Wiki, Tickets, Technotes, and the Forum are not supported in Git,
15 so those features are not included in an export.
16
17 Third-party Git based tooling may add some of these features (e.g.
18 GitHub, GitLab) but because their data are not stored in the Git
19 repository, there is no single destination for Fossil to convert its
20 equivalent data *to*. For instance, Fossil tickets do not become GitHub
21 issues, because that is a proprietary feature of GitHub separate from
22 Git proper, stored outside the repository on the GitHub servers.
23
24 You can also see the problem in its inverse case: you do not get a copy
25 of your GitHub issues when cloning the Git repository. You *do* get the
26 Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil
27 repo.
@@ -29,14 +29,14 @@
29 ## (2) Cherrypick Merges
30
31 The Git client supports cherrypick merges but does not record the
32 cherrypick parent(s).
33
34 Fossil tracks cherrypick merges in its repository and displays
35 cherrypicks in its timeline. (As an example, the dashed lines
36 [here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does
37 not have a way to represent this same information in its repository, the
38 history of Fossil cherrypicks cannot be exported to Git, only their
39 direct effects on the managed file data.
40
41 ## (3) Named Branches
42
@@ -73,11 +73,11 @@
73
74 ## (5) Amendments To Check-ins
75
76 Check-ins are immutable in both Fossil and Git.
77 However, Fossil has a mechanism by which tags can be added to
78 its repository to provide after-the-fact corrections to prior check-ins.
79
80 For example, tags can be added to check-ins that correct typos in the
81 check-in comment. The original check-in is immutable and so the
82 original comment is preserved in addition to the correction. But
83 software that displays the check-ins knows to look for the comment-change
84
M www/mkindex.tcl
+1 -1
--- www/mkindex.tcl
+++ www/mkindex.tcl
@@ -14,11 +14,11 @@
1414
 alerts.md {Email Alerts And Notifications}
1515
 antibot.wiki {Defense against Spiders and Bots}
1616
 backoffice.md {The "Backoffice" mechanism of Fossil}
1717
 backup.md {Backing Up a Remote Fossil Repository}
1818
 blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19
- blockchain.md {Fossil As Blockchain}
19
+ blockchain.md {Is Fossil A Blockchain?}
2020
 branching.wiki {Branching, Forking, Merging, and Tagging}
2121
 bugtheory.wiki {Bug Tracking In Fossil}
2222
 build.wiki {Compiling and Installing Fossil}
2323
 cap-theorem.md {Fossil and the CAP Theorem}
2424
 caps/ {Administering User Capabilities}
2525
--- www/mkindex.tcl
+++ www/mkindex.tcl
@@ -14,11 +14,11 @@
14 alerts.md {Email Alerts And Notifications}
15 antibot.wiki {Defense against Spiders and Bots}
16 backoffice.md {The "Backoffice" mechanism of Fossil}
17 backup.md {Backing Up a Remote Fossil Repository}
18 blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19 blockchain.md {Fossil As Blockchain}
20 branching.wiki {Branching, Forking, Merging, and Tagging}
21 bugtheory.wiki {Bug Tracking In Fossil}
22 build.wiki {Compiling and Installing Fossil}
23 cap-theorem.md {Fossil and the CAP Theorem}
24 caps/ {Administering User Capabilities}
25
--- www/mkindex.tcl
+++ www/mkindex.tcl
@@ -14,11 +14,11 @@
14 alerts.md {Email Alerts And Notifications}
15 antibot.wiki {Defense against Spiders and Bots}
16 backoffice.md {The "Backoffice" mechanism of Fossil}
17 backup.md {Backing Up a Remote Fossil Repository}
18 blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19 blockchain.md {Is Fossil A Blockchain?}
20 branching.wiki {Branching, Forking, Merging, and Tagging}
21 bugtheory.wiki {Bug Tracking In Fossil}
22 build.wiki {Compiling and Installing Fossil}
23 cap-theorem.md {Fossil and the CAP Theorem}
24 caps/ {Administering User Capabilities}
25
M www/permutedindex.html
+2 -2
--- www/permutedindex.html
+++ www/permutedindex.html
@@ -41,11 +41,11 @@
4141
 <li><a href="backoffice.md">Backoffice mechanism of Fossil &mdash; The</a></li>
4242
 <li><a href="fossil_prompt.wiki">Bash Prompt &mdash; Fossilized</a></li>
4343
 <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li>
4444
 <li><a href="caps/admin-v-setup.md">Between Setup and Admin Users &mdash; Differences</a></li>
4545
 <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 &mdash; Hash Policy: Choosing</a></li>
46
-<li><a href="blockchain.md">Blockchain &mdash; Fossil As</a></li>
46
+<li><a href="blockchain.md">Blockchain? &mdash; Is Fossil A</a></li>
4747
 <li><a href="antibot.wiki">Bots &mdash; Defense against Spiders and</a></li>
4848
 <li><a href="private.wiki">Branches &mdash; Creating, Syncing, and Deleting Private</a></li>
4949
 <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
5050
 <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
5151
 <li><a href="makefile.wiki">Build Process &mdash; The Fossil</a></li>
@@ -126,11 +126,10 @@
126126
 <li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size &mdash; Image</a></li>
127127
 <li><a href="../../../md_rules">Formatting Rules &mdash; Markdown</a></li>
128128
 <li><a href="../../../wiki_rules">Formatting Rules &mdash; Wiki</a></li>
129129
 <li><a href="forum.wiki">Forums &mdash; Fossil</a></li>
130130
 <li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li>
131
-<li><a href="blockchain.md"><b>Fossil As Blockchain</b></a></li>
132131
 <li><a href="changes.wiki"><b>Fossil Changelog</b></a></li>
133132
 <li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li>
134133
 <li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li>
135134
 <li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li>
136135
 <li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li>
@@ -188,10 +187,11 @@
188187
 <li><a href="build.wiki">Installing Fossil &mdash; Compiling and</a></li>
189188
 <li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li>
190189
 <li><a href="selfcheck.wiki">Integrity Self Checks &mdash; Fossil Repository</a></li>
191190
 <li><a href="webui.wiki">Interface &mdash; The Fossil Web</a></li>
192191
 <li><a href="interwiki.md"><b>Interwiki Links</b></a></li>
192
+<li><a href="blockchain.md"><b>Is Fossil A Blockchain?</b></a></li>
193193
 <li><a href="javascript.md">JavaScript in Fossil &mdash; Use of</a></li>
194194
 <li><a href="th1.md">Language &mdash; The TH1 Scripting</a></li>
195195
 <li><a href="copyright-release.html">License Agreement &mdash; Contributor</a></li>
196196
 <li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li>
197197
 <li><a href="interwiki.md">Links &mdash; Interwiki</a></li>
198198
--- www/permutedindex.html
+++ www/permutedindex.html
@@ -41,11 +41,11 @@
41 <li><a href="backoffice.md">Backoffice mechanism of Fossil &mdash; The</a></li>
42 <li><a href="fossil_prompt.wiki">Bash Prompt &mdash; Fossilized</a></li>
43 <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li>
44 <li><a href="caps/admin-v-setup.md">Between Setup and Admin Users &mdash; Differences</a></li>
45 <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 &mdash; Hash Policy: Choosing</a></li>
46 <li><a href="blockchain.md">Blockchain &mdash; Fossil As</a></li>
47 <li><a href="antibot.wiki">Bots &mdash; Defense against Spiders and</a></li>
48 <li><a href="private.wiki">Branches &mdash; Creating, Syncing, and Deleting Private</a></li>
49 <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
50 <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
51 <li><a href="makefile.wiki">Build Process &mdash; The Fossil</a></li>
@@ -126,11 +126,10 @@
126 <li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size &mdash; Image</a></li>
127 <li><a href="../../../md_rules">Formatting Rules &mdash; Markdown</a></li>
128 <li><a href="../../../wiki_rules">Formatting Rules &mdash; Wiki</a></li>
129 <li><a href="forum.wiki">Forums &mdash; Fossil</a></li>
130 <li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li>
131 <li><a href="blockchain.md"><b>Fossil As Blockchain</b></a></li>
132 <li><a href="changes.wiki"><b>Fossil Changelog</b></a></li>
133 <li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li>
134 <li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li>
135 <li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li>
136 <li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li>
@@ -188,10 +187,11 @@
188 <li><a href="build.wiki">Installing Fossil &mdash; Compiling and</a></li>
189 <li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li>
190 <li><a href="selfcheck.wiki">Integrity Self Checks &mdash; Fossil Repository</a></li>
191 <li><a href="webui.wiki">Interface &mdash; The Fossil Web</a></li>
192 <li><a href="interwiki.md"><b>Interwiki Links</b></a></li>
 
193 <li><a href="javascript.md">JavaScript in Fossil &mdash; Use of</a></li>
194 <li><a href="th1.md">Language &mdash; The TH1 Scripting</a></li>
195 <li><a href="copyright-release.html">License Agreement &mdash; Contributor</a></li>
196 <li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li>
197 <li><a href="interwiki.md">Links &mdash; Interwiki</a></li>
198
--- www/permutedindex.html
+++ www/permutedindex.html
@@ -41,11 +41,11 @@
41 <li><a href="backoffice.md">Backoffice mechanism of Fossil &mdash; The</a></li>
42 <li><a href="fossil_prompt.wiki">Bash Prompt &mdash; Fossilized</a></li>
43 <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li>
44 <li><a href="caps/admin-v-setup.md">Between Setup and Admin Users &mdash; Differences</a></li>
45 <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 &mdash; Hash Policy: Choosing</a></li>
46 <li><a href="blockchain.md">Blockchain? &mdash; Is Fossil A</a></li>
47 <li><a href="antibot.wiki">Bots &mdash; Defense against Spiders and</a></li>
48 <li><a href="private.wiki">Branches &mdash; Creating, Syncing, and Deleting Private</a></li>
49 <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
50 <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
51 <li><a href="makefile.wiki">Build Process &mdash; The Fossil</a></li>
@@ -126,11 +126,10 @@
126 <li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size &mdash; Image</a></li>
127 <li><a href="../../../md_rules">Formatting Rules &mdash; Markdown</a></li>
128 <li><a href="../../../wiki_rules">Formatting Rules &mdash; Wiki</a></li>
129 <li><a href="forum.wiki">Forums &mdash; Fossil</a></li>
130 <li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li>
 
131 <li><a href="changes.wiki"><b>Fossil Changelog</b></a></li>
132 <li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li>
133 <li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li>
134 <li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li>
135 <li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li>
@@ -188,10 +187,11 @@
187 <li><a href="build.wiki">Installing Fossil &mdash; Compiling and</a></li>
188 <li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li>
189 <li><a href="selfcheck.wiki">Integrity Self Checks &mdash; Fossil Repository</a></li>
190 <li><a href="webui.wiki">Interface &mdash; The Fossil Web</a></li>
191 <li><a href="interwiki.md"><b>Interwiki Links</b></a></li>
192 <li><a href="blockchain.md"><b>Is Fossil A Blockchain?</b></a></li>
193 <li><a href="javascript.md">JavaScript in Fossil &mdash; Use of</a></li>
194 <li><a href="th1.md">Language &mdash; The TH1 Scripting</a></li>
195 <li><a href="copyright-release.html">License Agreement &mdash; Contributor</a></li>
196 <li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li>
197 <li><a href="interwiki.md">Links &mdash; Interwiki</a></li>
198
M www/shunning.wiki
+2 -2
--- www/shunning.wiki
+++ www/shunning.wiki
@@ -32,12 +32,12 @@
3232
 some alternatives that usually suffice, which don't damage the project's
3333
 fossil record:
3434
3535
 <ul>
3636
 <li><p>When a forum post or wiki article is "deleted," what actually
37
- happens is that a new empty version is added to the Fossil
38
- [./blockchain.md | block chain]. The web interface interprets this
37
+ happens is that a new empty version is added to the Fossil repository.
38
+ The web interface interprets this
3939
 as "deleted," but the prior version remains available if you go
4040
 digging for it.</p></li>
4141
4242
 <li><p>When you close a ticket, it's marked in a way that causes it
4343
 to not show up in the normal ticket reports. You usually want to
4444
--- www/shunning.wiki
+++ www/shunning.wiki
@@ -32,12 +32,12 @@
32 some alternatives that usually suffice, which don't damage the project's
33 fossil record:
34
35 <ul>
36 <li><p>When a forum post or wiki article is "deleted," what actually
37 happens is that a new empty version is added to the Fossil
38 [./blockchain.md | block chain]. The web interface interprets this
39 as "deleted," but the prior version remains available if you go
40 digging for it.</p></li>
41
42 <li><p>When you close a ticket, it's marked in a way that causes it
43 to not show up in the normal ticket reports. You usually want to
44
--- www/shunning.wiki
+++ www/shunning.wiki
@@ -32,12 +32,12 @@
32 some alternatives that usually suffice, which don't damage the project's
33 fossil record:
34
35 <ul>
36 <li><p>When a forum post or wiki article is "deleted," what actually
37 happens is that a new empty version is added to the Fossil repository.
38 The web interface interprets this
39 as "deleted," but the prior version remains available if you go
40 digging for it.</p></li>
41
42 <li><p>When you close a ticket, it's marked in a way that causes it
43 to not show up in the normal ticket reports. You usually want to
44

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button