Minor wording fixes in docs (#10822)
Andrew Gillis committed
May 30, 2025 at 15:14 UTC
bb91273015694bae1840ff87bf003f3d3608238b
6 files changed
+20
-20
docs/add-code-flow.md
+2
-2
@@ -55,7 +55,7 @@ Within the function, a new `Adder` is created with the configured `Blockstore` a
55
56
1. **[`adder.add(io.Reader)`](https://github.com/ipfs/go-ipfs/blob/v0.4.18/core/coreunix/add.go#L115)** - *Create and return the **root** __DAG__ node*
57
58
- This method converts the input data (`io.Reader`) to a __DAG__ tree, by splitting the data into _chunks_ using the `Chunker` and organizing them in to a __DAG__ (with a *trickle* or *balanced* layout. See [balanced](https://github.com/ipfs/go-unixfs/blob/6b769632e7eb8fe8f302e3f96bf5569232e7a3ee/importer/balanced/builder.go) for more info).
58
+ This method converts the input data (`io.Reader`) to a __DAG__ tree, by splitting the data into _chunks_ using the `Chunker` and organizing them into a __DAG__ (with a *trickle* or *balanced* layout. See [balanced](https://github.com/ipfs/go-unixfs/blob/6b769632e7eb8fe8f302e3f96bf5569232e7a3ee/importer/balanced/builder.go) for more info).
59
60
The method returns the **root** `ipld.Node` of the __DAG__.
61
@@ -70,7 +70,7 @@ Within the function, a new `Adder` is created with the configured `Blockstore` a
70
71
- **[MFS] [`PutNode(mfs.Root, path, ipld.Node)`](https://github.com/ipfs/go-mfs/blob/v0.1.18/ops.go#L86)** - *Insert node at path into given `MFS`*
72
73
- The `path` param is used to determine the `MFS Directory`, which is first looked up in the `MFS` using `lookupDir()` function. This is followed by adding the **root** __DAG__ node (`ipld.Node`) in to this `Directory` using `directory.AddChild()` method.
73
+ The `path` param is used to determine the `MFS Directory`, which is first looked up in the `MFS` using `lookupDir()` function. This is followed by adding the **root** __DAG__ node (`ipld.Node`) into this `Directory` using `directory.AddChild()` method.
74
75
- **[MFS] Add Child To `UnixFS`**
76
- **[`directory.AddChild(filename, ipld.Node)`](https://github.com/ipfs/go-mfs/blob/v0.1.18/dir.go#L350)** - *Add **root** __DAG__ node under this directory*
docs/config.md
+3
-3
@@ -846,7 +846,7 @@ Options for [ZeroConf](https://github.com/libp2p/zeroconf#readme) Multicast DNS-
846
847
#### `Discovery.MDNS.Enabled`
848
849
-A boolean value for whether or not Multicast DNS-SD should be active.
849
+A boolean value to activate or deactivate Multicast DNS-SD.
850
851
Default: `true`
852
@@ -934,7 +934,7 @@ Type: `object[string -> array[string]]`
934
935
### `Gateway.RootRedirect`
936
937
-A url to redirect requests for `/` to.
937
+A URL to redirect requests for `/` to.
938
939
Default: `""`
940
@@ -1410,7 +1410,7 @@ Type: `string` (filesystem path)
1410
1411
### `Mounts.FuseAllowOther`
1412
1413
-Sets the 'FUSE allow other'-option on the mount point.
1413
+Sets the 'FUSE allow-other' option on the mount point.
1414
1415
## `Pinning`
1416
docs/datastores.md
+6
-6
@@ -12,13 +12,13 @@ field in the ipfs configuration file.
12
13
## flatfs
14
15
-Stores each key value pair as a file on the filesystem.
15
+Stores each key-value pair as a file on the filesystem.
16
17
The shardFunc is prefixed with `/repo/flatfs/shard/v1` then followed by a descriptor of the sharding strategy. Some example values are:
18
- `/repo/flatfs/shard/v1/next-to-last/2`
19
- Shards on the two next to last characters of the key
20
- `/repo/flatfs/shard/v1/prefix/2`
21
- - Shards based on the two character prefix of the key
21
+ - Shards based on the two-character prefix of the key
22
23
```json
24
{
@@ -34,7 +34,7 @@ The shardFunc is prefixed with `/repo/flatfs/shard/v1` then followed by a descri
34
NOTE: flatfs must only be used as a block store (mounted at `/blocks`) as it only partially implements the datastore interface. You can mount flatfs for /blocks only using the mount datastore (described below).
35
36
## levelds
37
-Uses a leveldb database to store key value pairs.
37
+Uses a leveldb database to store key-value pairs.
38
39
```json
40
{
@@ -46,7 +46,7 @@ Uses a leveldb database to store key value pairs.
46
47
## pebbleds
48
49
-Uses [pebble](https://github.com/cockroachdb/pebble) as a key value store.
49
+Uses [pebble](https://github.com/cockroachdb/pebble) as a key-value store.
50
51
```json
52
{
@@ -90,7 +90,7 @@ When installing a new version of kubo when `"formatMajorVersion"` is configured,
90
91
## badgerds
92
93
-Uses [badger](https://github.com/dgraph-io/badger) as a key value store.
93
+Uses [badger](https://github.com/dgraph-io/badger) as a key-value store.
94
95
> [!CAUTION]
96
> This is based on very old badger 1.x, which has known bugs and is no longer supported by the upstream team.
@@ -99,7 +99,7 @@ Uses [badger](https://github.com/dgraph-io/badger) as a key value store.
99
100
101
* `syncWrites`: Flush every write to disk before continuing. Setting this to false is safe as kubo will automatically flush writes to disk before and after performing critical operations like pinning. However, you can set this to true to be extra-safe (at the cost of a 2-3x slowdown when adding files).
102
-* `truncate`: Truncate the DB if a partially written sector is found (defaults to true). There is no good reason to set this to false unless you want to manually recover partially written (and unpinned) blocks if kubo crashes half-way through adding a file.
102
+* `truncate`: Truncate the DB if a partially written sector is found (defaults to true). There is no good reason to set this to false unless you want to manually recover partially written (and unpinned) blocks if kubo crashes half-way through a write operation.
103
104
```json
105
{
docs/experimental-features.md
+1
-1
@@ -398,7 +398,7 @@ We also support the use of protocol names of the form /x/$NAME/http where $NAME
398
### Road to being a real feature
399
400
- [ ] Needs p2p streams to graduate from experiments
401
-- [ ] Needs more people to use and report on how well it works / fits use cases
401
+- [ ] Needs more people to use and report on how well it works and fits use cases
402
- [ ] More documentation
403
- [ ] Need better integration with the subdomain gateway feature.
404
docs/implement-api-bindings.md
+4
-4
@@ -39,12 +39,12 @@ function calls. For example:
39
#### CLI API Transport
40
41
In the commandline, IPFS uses a traditional flag and arg-based mapping, where:
42
-- the first arguments selects the command, as in git - e.g. `ipfs dag get`
42
+- the first arguments select the command, as in git - e.g. `ipfs dag get`
43
- the flags specify options - e.g. `--enc=protobuf -q`
44
- the rest are positional arguments - e.g. `ipfs key rename <name> <newName>`
45
- files are specified by filename, or through stdin
46
47
-(NOTE: When kubo runs the daemon, the CLI API is actually converted to HTTP
47
+(NOTE: When kubo runs the daemon, the CLI API is converted to HTTP
48
calls. otherwise, they execute in the same process)
49
50
#### HTTP API Transport
@@ -87,7 +87,7 @@ Despite all the generalization spoken about above, the IPFS API is actually very
87
simple. You can inspect all the requests made with `nc` and the `--api` option
88
(as of [this PR](https://github.com/ipfs/kubo/pull/1598), or `0.3.8`):
89
90
-```
90
+```sh
91
> nc -l 5002 &
92
> ipfs --api /ip4/127.0.0.1/tcp/5002 swarm addrs local --enc=json
93
POST /api/v0/version?enc=json&stream-channels=true HTTP/1.1
@@ -104,7 +104,7 @@ The only hard part is getting the file streaming right. It is (now) fairly easy
104
to stream files to kubo using multipart. Basically, we end up with HTTP
105
requests like this:
106
107
-```
107
+```sh
108
> nc -l 5002 &
109
> ipfs --api /ip4/127.0.0.1/tcp/5002 add -r ~/demo/basic/test
110
POST /api/v0/add?encoding=json&progress=true&r=true&stream-channels=true HTTP/1.1
docs/releases.md
+4
-4
@@ -20,9 +20,9 @@
20
21
## Release Philosophy
22
23
-`kubo` aims to have release every six weeks, two releases per quarter. During these 6 week releases, we go through 4 different stages that gives us the opportunity to test the new version against our test environments (unit, interop, integration), QA in our current production environment, IPFS apps (e.g. Desktop and WebUI) and with our community and _early testers_<sup>[1]</sup> that have IPFS running in production.
23
+`kubo` aims to have a release every six weeks, two releases per quarter. During these 6 week releases, we go through 4 different stages that allow us to test the new version against our test environments (unit, interop, integration), QA in our current production environment, IPFS apps (e.g. Desktop and WebUI) and with our community and _early testers_<sup>[1]</sup> that have IPFS running in production.
24
25
-We might expand the six week release schedule in case of:
25
+We might expand the six-week release schedule in case of:
26
27
- No new updates to be added
28
- In case of a large community event that takes the core team availability away (e.g. IPFS Conf, Dev Meetings, IPFS Camp, etc.)
@@ -59,7 +59,7 @@ Test the release in as many non-production environments as possible. This is rel
59
60
### Stage 3 - Community Prod Testing
61
62
-At this stage, we consider the release to be "production ready" and will ask the community and our early testers to (partially) deploy the release to their production infrastructure.
62
+At this stage, we consider the release to be "production-ready" and will ask the community and our early testers to (partially) deploy the release to their production infrastructure.
63
64
**Goals:**
65
@@ -69,7 +69,7 @@ At this stage, we consider the release to be "production ready" and will ask the
69
70
### Stage 4 - Release
71
72
-At this stage, the release is "battle hardened" and ready for wide deployment.
72
+At this stage, the release is "battle-hardened" and ready for wide deployment.
73
74
## Release Cycle
75