IPFS 和编辑权限
IPFS and Editing Permissions
我刚刚上传了一个包含 5 张图片的文件夹到 IPFS（使用 Mac 桌面 IPFS 客户端应用程序，所以这是一个非常简单的拖放操作。）
既然我是创建和发布此文件夹的人，这是否意味着我是唯一被允许对其进行进一步修改的人 - 比如从中添加或删除更多图像？或者 IPFS 上的任何人都可以这样做吗？
如果可以，是否有办法防止这种情况发生？
=======================================
更新问题：
我的具体用例与更新 ERC721 代币的元数据有关 - 在它们已经被铸造之后。
例如，想象一个游戏，其中某些对象（比如一把魔法剑）在使用一定次数后或在其所有者完成某些任务后获得特殊能力。所以我们想通过编辑它的元数据并将这个更新的元数据文件重新提交到区块链来更新这把剑的属性。
例如，如果我们的游戏有 100 把剑，并且我们最初上传到 IPFS 的文件夹包含所有 100 个 json 文件（每把剑一个），那么我很确定 IPFS 仍然允许您访问散列文件夹中的特定文件通过其特定的人类可读名称（而不仅仅是通过它们的散列）。
因此，如果我们的剑恰好是剑#76，并且我们的 JSON 文件的命名约定是这种格式： “sword000.json” ，那么剑#76 的 JSON 元数据文件将具有这样的路径作为：
http://ipfs.infura.io/QmY2xxxxxxxxxxxxxxxxxxxxxx/sword076.json
如果我们随后编辑“sword076.json”文件并将其拖放回我们的主 JSON 文件夹，显然会导致该文件夹的 Hash/CID 值发生变化.但是，只要我们能够更新我们的 Solidity 合约的“tokenURI”方法来从这个新更新的 HASH/CID 文件夹名称中查找和提供我们的“.json”文件，我们仍然可以参考其中的单个文件按其常规英文名称。这意味着我们可以开始了。
这是否是一个好的方案，我们绝对可以讨论，但我首先想回到我原来的 question/concern，我想确保我们是只有那些可以更新我们文件夹内容的人 - 并且没有其他人有权这样做。
这有意义吗？
IPFS 是不可变的，这意味着当您将目录与文件一起添加时，目录会根据目录的内容获得唯一的 CID。所以从某种意义上说，没有人可以修改它，即使你也不能，因为它是不可变的。我相信这种困惑可以通过更多关于 IPFS 工作原理的背景知识来解决。
当你向 IPFS 添加东西时，每个文件都会被散列，并被赋予一个 CID。目录也是如此，但是它们的CID更容易理解为目录内容的总和。因此，如果目录中的任何文件被更新、添加或删除，目录都会获得一个新的 CID。
了解这一点，如果其他人以完全相同的方式添加完全相同的内容，他们最终会得到完全相同的 CID！这样，如果两个人添加相同的 CID，而第三个人请求该文件（或目录），那么两个节点都可以提供数据，因为我们知道它是完全相同的。如果您简单地共享您的 CID 并且另一个节点固定它，也是如此，两个节点将具有相同的数据，因此如果有人请求它，两个节点都可以提供它。
因此您的本地副本无法被任何人编辑。从某种意义上说，如果您依赖 IPFS CID 作为您的数据地址，那么您甚至都不行！这就是 IPFS 通常被称为“不可变”的原因，因为您通过 IPFS CID 请求的任何数据将始终相同。如果您更改任何数据，您将获得一个新的 CID。
可以在此处找到更多信息：Content Addressing & Immutability
如果您阅读了所有这些内容并想“如果我想要可变数据怎么办？”，如果您正在寻找一种自动为您更新 IPNS 的工具，我建议您查看 IPNS and possibly ipfs-sync。
我刚刚上传了一个包含 5 张图片的文件夹到 IPFS（使用 Mac 桌面 IPFS 客户端应用程序，所以这是一个非常简单的拖放操作。）
既然我是创建和发布此文件夹的人，这是否意味着我是唯一被允许对其进行进一步修改的人 - 比如从中添加或删除更多图像？或者 IPFS 上的任何人都可以这样做吗？
如果可以，是否有办法防止这种情况发生？
=======================================
更新问题：
我的具体用例与更新 ERC721 代币的元数据有关 - 在它们已经被铸造之后。
例如，想象一个游戏，其中某些对象（比如一把魔法剑）在使用一定次数后或在其所有者完成某些任务后获得特殊能力。所以我们想通过编辑它的元数据并将这个更新的元数据文件重新提交到区块链来更新这把剑的属性。
例如，如果我们的游戏有 100 把剑，并且我们最初上传到 IPFS 的文件夹包含所有 100 个 json 文件（每把剑一个），那么我很确定 IPFS 仍然允许您访问散列文件夹中的特定文件通过其特定的人类可读名称（而不仅仅是通过它们的散列）。
因此，如果我们的剑恰好是剑#76，并且我们的 JSON 文件的命名约定是这种格式： “sword000.json” ，那么剑#76 的 JSON 元数据文件将具有这样的路径作为：
http://ipfs.infura.io/QmY2xxxxxxxxxxxxxxxxxxxxxx/sword076.json
如果我们随后编辑“sword076.json”文件并将其拖放回我们的主 JSON 文件夹，显然会导致该文件夹的 Hash/CID 值发生变化.但是，只要我们能够更新我们的 Solidity 合约的“tokenURI”方法来从这个新更新的 HASH/CID 文件夹名称中查找和提供我们的“.json”文件，我们仍然可以参考其中的单个文件按其常规英文名称。这意味着我们可以开始了。
这是否是一个好的方案，我们绝对可以讨论，但我首先想回到我原来的 question/concern，我想确保我们是只有那些可以更新我们文件夹内容的人 - 并且没有其他人有权这样做。
这有意义吗？
IPFS 是不可变的，这意味着当您将目录与文件一起添加时，目录会根据目录的内容获得唯一的 CID。所以从某种意义上说，没有人可以修改它，即使你也不能，因为它是不可变的。我相信这种困惑可以通过更多关于 IPFS 工作原理的背景知识来解决。
当你向 IPFS 添加东西时，每个文件都会被散列，并被赋予一个 CID。目录也是如此，但是它们的CID更容易理解为目录内容的总和。因此，如果目录中的任何文件被更新、添加或删除，目录都会获得一个新的 CID。
了解这一点，如果其他人以完全相同的方式添加完全相同的内容，他们最终会得到完全相同的 CID！这样，如果两个人添加相同的 CID，而第三个人请求该文件（或目录），那么两个节点都可以提供数据，因为我们知道它是完全相同的。如果您简单地共享您的 CID 并且另一个节点固定它，也是如此，两个节点将具有相同的数据，因此如果有人请求它，两个节点都可以提供它。
因此您的本地副本无法被任何人编辑。从某种意义上说，如果您依赖 IPFS CID 作为您的数据地址，那么您甚至都不行！这就是 IPFS 通常被称为“不可变”的原因，因为您通过 IPFS CID 请求的任何数据将始终相同。如果您更改任何数据，您将获得一个新的 CID。
可以在此处找到更多信息：Content Addressing & Immutability
如果您阅读了所有这些内容并想“如果我想要可变数据怎么办？”，如果您正在寻找一种自动为您更新 IPNS 的工具，我建议您查看 IPNS and possibly ipfs-sync。