You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/documentation/act.md
+360-6Lines changed: 360 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -5,14 +5,368 @@ slug: /act
5
5
sidebar_label: ACT
6
6
---
7
7
8
-
## 🚧 Under Construction 🚧
9
-
:::caution 🚧 This page is under construction
8
+
ACT, or Access Control Trie, is a decentralized permission system built into the Swarm network that allows you to restrict access to uploaded content.
10
9
11
-
This section is still being worked on. Check back soon for updates!
10
+
When you upload data to Swarm using ACT, only the original uploader and users with public keys listed in an associated grantee list are able to retrieve and decrypt that data. The grantee list is published separately and cryptographically referenced during upload and download operations.
12
11
12
+
ACT is ideal for use cases such as the serialized release of content like a podcast or newsletter where the publisher wishes to limit access to subscribers only.
13
+
14
+
:::warning
15
+
Once a file is uploaded with ACT, any node whose public key is on the ACT grantees list referenced during the upload ***will have permanent access to that file*** as long as the file reference and history reference returned from the upload has been shared with them.
16
+
17
+
Updating the grantees list to remove a public key ***will not revoke access*** to the content retroactively.
18
+
19
+
Likewise, re-uploading the content using the new grantees list will also ***not retroactively revoke access*** to the content.
20
+
:::
21
+
22
+
## Requirements
23
+
The use of ACT requires the following:
24
+
25
+
* A Bee light node running on with synced postage batch data. (Running at `http://localhost:1633` by default)
26
+
* A valid postage batch ID. [Buy one](/docs/storage/#purchasing-storage) if needed.
27
+
* Public keys of the nodes you want to grant access to.
28
+
* The **public key of the publishing node**. This can be obtained using the [`bee.getNodeAddresses()` method](/docs/status/#3-get-node-addresses).
29
+
30
+
## Create Grantees List
31
+
32
+
First we create a grantees list with the public keys of anyone we want to grant access to.
33
+
34
+
#### Example Script:
35
+
36
+
The example script below performs the following key operations:
37
+
38
+
1. Initializes a Bee client.
39
+
2. Defines a list of grantee public keys.
40
+
3. Specifies a valid postage batch ID.
41
+
4. Calls `bee.createGrantees()` to create a new grantee list.
History Reference: 18d6f58a1d3c8253a5fc47023d49e9011236ead43724e595e898e1b422b77b19
82
+
```
83
+
84
+
The first 64 byte (128 hex digit) reference `Grantee List Reference` (`ref`) is used on its own for reviewing the list contents and updating the list.
85
+
86
+
The second reference 32 byte (64 hex digit) `History Reference` (`historyref`) is used for uploading with ACT and is also used along with the first `ref` for creating a new updated grantee list based on the original list referred to by the `ref`.
87
+
88
+
## Update Grantees List
89
+
90
+
:::info
91
+
Although we refer to this operation as an "update", due to Swarm's immutable nature, the original list is not modified by this operation. Rather a new list is created with the specified grantee keys added or removed from the original list. This operation ***DOES NOT*** retroactively add or remove access to content uploaded with the original ACT list.
13
92
:::
14
93
94
+
To update a grantees list, call the `bee.patchGrantees()` method with the following arguments:
95
+
96
+
* A valid postage batch ID
97
+
* The original list’s `ref` and `historyref`
98
+
* An object specifying public keys to `add` or `revoke`
Updated History Reference: d904f0790acb7edfda6a078176d64ec026b40298bfdbceb82956533e31489fcd
168
+
```
169
+
170
+
## Get Grantees List
171
+
172
+
In order to view the members of our grantees list we need to use the 64 byte `ref` returned when we create or update a list. We will view both our original list and the updated list based on the original list using the respective `ref` from each list:
173
+
174
+
:::info
175
+
The grantee list is encrypted, and only the owner can view the grantee list, make sure to use the owner node when using the `bee.getGrantees()` method.
176
+
:::
177
+
178
+
#### Example Script:
179
+
180
+
The example script below performs the following operations:
181
+
182
+
1. Initializes a Bee client.
183
+
2. Defines two existing grantee list 64 byte `ref` copied from the results of our previous example scripts.
184
+
3. Calls `bee.getGrantees()` for each `ref` to retrieve the corresponding grantee list.
185
+
4. Logs the status, status text, and list of grantee public keys in compressed hex format.
The first list of grantees contains the first public key we gave access to when we created the list, while the second one contains both the first and the second one we added when we created our second list based on the first one.
242
+
243
+
## Upload With ACT
244
+
245
+
We can upload our content with either of the two lists we created depending on which set of users we wish to give access too. In the example below, we use both lists.
246
+
247
+
#### Example Script:
248
+
249
+
The example script below performs the following operations:
250
+
251
+
1. Initializes a Bee client.
252
+
2. Defines a postage batch ID and two ACT grantee list 32 byte `historyref` hashes returned from the operations in the previous examples.
253
+
3. Defines a string to upload as a sample file.
254
+
4. Calls `bee.uploadFile()` twice with ACT enabled, specifying a `historyRef` each time to enforce access control.
255
+
5. Logs the resulting Swarm reference and history reference after each upload.
The reference hash is the same for each upload since the content is the same. The reference hash along with a `historyref` and the uploader's public key are required in order to access the content uploaded with ACT.
311
+
312
+
You can choose which `historyref` to share depending on which set of public keys you wish to authorize to download the content.
313
+
314
+
## Download With ACT
315
+
316
+
In order to download using ACT, we must pass in the public key from the grantee list creator along with the file reference and history reference returned from the file upload operation:
317
+
318
+
#### Example Script:
319
+
320
+
The example script below performs the following operations:
321
+
322
+
1. Initializes a Bee client.
323
+
2. Defines a publisher public key and associated file reference + history references for ACT-protected content using the references returned from the upload operation.
324
+
3. Calls `bee.downloadFile()` with ACT options (`actPublisher` and `actHistoryAddress`) to access protected data.
console.error(`Error downloading from reference ${fileRef}:`, error)
354
+
}
355
+
}
356
+
357
+
downloadWithACT(
358
+
fileRef_01,
359
+
historyRef_01,
360
+
publisherPublicKey
361
+
)
362
+
```
363
+
364
+
Example terminal output:
365
+
366
+
```bash
367
+
Content: This is a sample string that will be uploaded securely using ACT.
368
+
```
369
+
370
+
In the example above, we used the history reference from the file uploaded using the grantees list with only one public key included (`027d0c4759f689ea3dd3eb79222870671c492cb99f3fade275bcbf0ea39cd0ef6e`), and so it will only be able to be retrieved and decrypted by the node with that public key.
15
371
16
-
* Show example of creating grantee list
17
-
* Show example of secure upload
18
-
* Show example of secure download
372
+
If any other node attempts to download this content then a 404 error will be returned.
0 commit comments