distributed bootstrapping with IPNS
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 20/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- json
调研方向
该 issue 没有指出任何仓库文件、测试或入口点。首先检查提议的 IPNS 引导流程、信任条目矩阵和信任文件 JSON schema，然后明确哪一部分属于范围。要视为完成，必须确定一个经同意且边界明确的实现目标，以及相应的验证标准。
由索引模型根据 Issue 内容生成。
描述
Current bootstrap approach
We have a config file that contains either addresses or DNS names with public keys.
We use DNS to resolve addresses, then we connect to the fixed list of predefined nodes with known public keys and ask them for (somewhat) random nodes of the network, to spin up the DHT of the node.
The nodes are run by a trusted entity and we do this on each startup.
The problem
There are several problems with this approach:
- It consumes many resources on the trusted entity side because all nodes do this on every reboot/restart.
- The bootstrap node definition isn't dynamic, the default config will always contain the same entries and cannot be updated over the network (without updating the software).
- The bootstrapping isn't distributed, there is only one trusted entity.
- it's a centralized structure and prone to
-
- blocking
-
- outages
-
- DDoS attacks
I think we should do something about that (as discussed in other places, like https://github.com/libp2p/go-libp2p-kad-dht/issues/574).
Concept
I propose to change this very basic approach with a trust-network. It allows the users to configure their trust for projects, orgs and individuals. Thus allowing to do decisions based on those data how reliably received informations are.
Trust-DB
The trust-db is stored in the node-database, not in the config file and the bootstrap field in the config file will be ignored.
- We define a JSON format to list nodes, with either domain names or addresses, public keys etc.
- Those JSON files can be published with an IPNS record.
- Other nodes can add these IPNS records to their storage and set a level how much they trust this entity.
- The IPNS records will be refreshed and the new JSON files will be fetched and processed - when the TTL does expire.
- By default we import a list of standard nodes, like we peers to the bootstrap list, with an IPNS public key to update it, as soon as the node is connected to the network.
This allows us to:
- define trusted entities, like companies, projects, or individuals
- trusted entities can update their list of nodes, as soon as they install new ones or remove old ones
Additionally trust levels
After implementing a basic trust level for bootstrapping, we could extend this to support a multitude of functions, using the trust level as ACLs.
Trust entries
Each trust-entry is a IPNS record which points to a trust-file, a trust level and a list of trusted functions as well as text-label and a lifetime. There are also some fields for the status in the end.
An example of a trust entry:
| ID | description |
|---|---|
| label | name of this trust-db entry |
| pubkey | IPNS record |
| trustlevel | the trust level of this entry |
| trusted-functions | array of allowed extended functionalities |
| trust-lifetime | the time the trust-level validation is valid (="infinity") |
| fetched | timestamp when this entry was fetched |
| TTL | time after which this entry is considered stale |
| cache-lifetime | time after which the cached entry isn't valid anymore |
trust functions
is a list of allowed functions, for this specific trust entry which overwrites positively or negatively the standard function matrix.
Trust levels
| ID | example |
|---|---|
| peer | nil trust |
| marginal | no toughly validation, but a bit more trust than nil |
| trusted | an organization/individual the user trusts |
| advanced | e.g. a close friend the user trusts |
| ultimate | user's own trust file |
peer
can be used to save a known peer with a remote or dns entry to the node information.
Trust level matrix
Trust level function matrix (as an example):
| Function \ Trustlevel | peer |
marginal |
trusted |
advanced |
ultimate |
|---|---|---|---|---|---|
| use for bootstrap | 🗶 | 🗶 | ✔ | ✔ | ✔ |
| connect on startup | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| hold connection and reconnect to | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| used for autonat detection | 🗶 | ✔ | ✔ | ✔ | ✔ |
| allow graphsync | 🗶 | ✔ | ✔ | ✔ | ✔ |
| allow to query all ipns | 🗶 | 🗶 | 🗶 | 🗶 | ✔ |
| trusted peer exchange w/ ratings | 🗶 | 🗶 | ✔ | ✔ | ✔ |
| offer relay | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| use as relay | 🗶 | ✔ | ✔ | ✔ | ✔ |
| allow redistribute ipns | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| remote resolve IPNS | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| remote put DHT | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| remote fetch DHT | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
| remote fetch CID | 🗶 | 🗶 | 🗶 | ✔ | ✔ |
remote fetch
would allow thin clients, like mobile phones, to connect to other nodes and without bootstrapping. Thus allowing to query the DHT and fetch CIDs using them as a proxy. This would reduce the time-to-first-byte massively while reducing the energy consumption since this requires only a single connection that doesn't transfer any data when not actively used.
The thin clients would use and announce a relay connection to receive incoming connections if they are behind a firewall/nat.
remote put DHT
would allow a thin-client to announce content it holds to the DHT, without bootstrapping the DHT.
Trust files
The trust-files are json files with the following fields:
| ID | subfield of | type | description | mandatory |
|---|---|---|---|---|
| description | root | text | field for descriptions | ✔ |
| contact | root | array | URIs for contacting | ✔ |
| entities | root | array | list of persons/projects/etc. | ✔ (="default") |
| nodes | entities | array | entries for nodes | ✔ |
| node | nodes | array | identifiers (label) for node | ✔ (="node") |
| pubkey | node | pubkey of the node | ✔ | |
| contact | node | array | URIs for contacting | 🗶 |
| remotes | node | array | ip/port/protocol etc string | 🗶 |
| remotes-strict | node | boolean | should other remotes be omitted for this pubkey? | 🗶 (=true if not present) |
IPNS record limitations
for the IPNS records there some limitation necessary to avoid malicious entries
- minimal TTL 24h
- maximal cache time 2y
- 主要语言
- 没有语言数据
- 星标
- 38
- 派生
- 2
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
libp2p/notes 的其他 Issue
-
难度 5/5 一周以上 新手友好度 20/100
-
DHT
难度 5/5 一周以上 新手友好度 25/100
-
enhancement
难度 5/5 一周以上 新手友好度 25/100
-
难度 5/5 一周以上 新手友好度 25/100
-
难度 5/5 一周以上 新手友好度 20/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
review: medium
难度 2/5 1-3 小时 新手友好度 82/100
langgenius/dify#43296 · 1 个 reaction ·
维护者通常 1 天内回复
-
component/data-layer
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
area/redis
难度 2/5 1-3 小时 新手友好度 78/100
quarkusio/quarkus#57063 · 1 条评论 ·
维护者通常 1 天内回复