Advanced #238
Advanced #238
Conversation
✅ Deploy Preview for bee-js-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| However, there are several key differences: | ||
|
|
||
| - Unlike PSS, **GSOC only needs to mine the target chunk once**—multiple messages reuse it, making it **faster, cheaper**, and **more efficient** for recurring updates. | ||
| - Unlike PSS, **No encryption** is used by default, making it unsuitable for handling sensitive data. |
There was a problem hiding this comment.
Maybe add this, but better phrased:
- Subsequent GSOC (SOC) updates are not meant to be retrieved. Double-signing an SOC is undefined behaviour.
There was a problem hiding this comment.
Hmm, I am not quite sure how this should be phrased? I guess it is something like that the GSOC chunk is never really meant to be retrieved at all? It just serves as a channel for the service node to listen for messages over? In the docs I refer to them as GSOC "updates", but nothing is really being saved and updated is it? GSOC chunks just serve as a channel over which to receive ephemeral messages. Does that make sense?
docs/documentation/pinning.md
Outdated
|
|
||
| ## 🚧 Under Construction 🚧 | ||
| :::caution 🚧 This page is under construction | ||
| Pinning allows you to guarantee that your uploaded content will always be available by storing it **locally on your own Bee node**. However, pinning **guarantee availability across the Swarm network**. Therefore you must use pinning along with the **stewardship utilities** included in `bee-js` to monitor the availability of your pinned content and reupload it if needed. |
There was a problem hiding this comment.
Pinning allows you to guarantee that your uploaded content will always be available by storing it locally on your own Bee node.
Not only your uploaded content, any content, not required to be uploaded by you.
However, pinning guarantee availability across the Swarm network.
Missing "DOES NOT"
docs/documentation/pinning.md
Outdated
| ## Deleting a Tag After Use | ||
|
|
||
| Once you’re done tracking an upload, you can delete the tag to keep your node clean: | ||
|
|
||
| ```js | ||
| await bee.deleteTag(tag.uid) | ||
| console.log("Deleted tag:", tag.uid) | ||
| ``` |
There was a problem hiding this comment.
Is DELETE tag supposed to be here?
docs/documentation/soc-and-feeds.md
Outdated
| import TabItem from '@theme/TabItem' | ||
|
|
||
| ::: | ||
| Swarm provides the ability to store content in content-addressed [chunks](https://docs.ethswarm.org/docs/concepts/DISC/#content-addressed-chunks-and-single-owner-chunks) (CAC) whose addresses are derived from the chunk data, or Single Owner Chunks (SOC) whose addresses are derived from the uploader's own public key and chosen identifier. With single owner chunks, a user can assign arbitrary data to an address and attest chunk integrity with their digital signature. |
There was a problem hiding this comment.
Single Owner Chunks (SOC) whose addresses are derived from the uploader's own public key and chosen identifier
To be more precise, it is derived from uploader address and chosen identifier
docs/documentation/soc-and-feeds.md
Outdated
|
|
||
| :::warning SOCs are immutable! | ||
| You might be tempted to modify a SOC's content to "update" the chunk. Reuploading of SOC is forbidden in Swarm as it might create uncertain behavior. Bee node will reject the API call if it finds already existing SOC for the given address. Either use a different `identifier`, or you might be looking for Feeds as your use case. | ||
| You might be tempted to modify a SOC's content to "update" the chunk. Reuploading of an SOC is forbidden in Swarm as it might create uncertain behavior. A Bee node will reject the API call if it finds an already existing SOC for the given address. Either use a different `identifier`, or you might be looking for feeds if you need to perform multiple updates to the same content. |
There was a problem hiding this comment.
Minor notes:
Reuploading an SOC is not forbidden, maybe "not recommended" instead.
Use "undefined" instead of "uncertain", as "undefined behaviour" is a well-recognized term in programming.
There was a problem hiding this comment.
A Bee node will reject the API call if it finds an already existing SOC for the given address.
It does?
There was a problem hiding this comment.
A Bee node will reject the API call if it finds an already existing SOC for the given address.
Actually I don't know about this part, this part was copied from the version of the warning from the original SOC section so I assumed it was correct?
There was a problem hiding this comment.
If this was the case, GSOC wouldn't work at all
| } | ||
| ``` | ||
|
|
||
| ### 2. Upload a File with the Tag |
There was a problem hiding this comment.
FYI: Only deferred uploads work with tags
There was a problem hiding this comment.
Ah yes, I should mention that. Actually isn't it more like they are only needed with deferred uploads? With a direct upload, it will not return a hash until the content has been successfully uploaded and synced, so there is no need to track it, right?
|
|
||
| ### 3. Track Tag Progress | ||
|
|
||
| Use `bee.retrieveTag(tagUid)` to check how many chunks have been split and how many are synced. Poll repeatedly until `synced === split` to know when the upload has fully propagated. |
There was a problem hiding this comment.
Correctly: synced + seen === split
"Seen" are chunks which were synced previously and therefor won't be this time.
There was a problem hiding this comment.
Ahh, so I suppose that means seen is only relevant for a re-upload?
There was a problem hiding this comment.
Or if there are common chunks which have appeared in previous files (such as zero byte paddings)
2 participants
No description provided.