Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add TTL to Provider Record #42

Open
Tracked by #54
guillaumemichel opened this issue Jun 27, 2023 · 0 comments
Open
Tracked by #54

Add TTL to Provider Record #42

guillaumemichel opened this issue Jun 27, 2023 · 0 comments

Comments

@guillaumemichel
Copy link
Contributor

As a result of nodes fetching some content, advertising to the IPFS DHT and quickly churning, some CIDs have a lot of unreachable providers which may be a problem. In order to address this issue, nodes could give a TTL to the provider records they are advertising, given the knowledge of their average uptime. The DHT Servers would store the provider records only for TTL, which should reduce the number of unreachable providers in the IPFS DHT.

In order to implement this change, let's make use of the ttl field in the Provider Record protobuf https://github.com/plprobelab/go-kademlia/blob/dc867cbd3316a89cabaa5be19900cdbf5d2f0805/network/message/ipfsv1/message.proto#L30

Note that this field isn't supported in go-libp2p-kad-dht (so nodes will discard the ttl field), but it can already be parsed by rust-libp2p.

We also need a mechanism on the client/provider that will determine the TTL value, but this value can be provided by the caller (kubo/boxo).

On the Server side, we need to make sure that the TTL field is parsed, and that the Provider Store (once implemented) will only keep the Provider Record for its given TTL (or at most a fixed number e.g 48 hours).

References

@iand iand transferred this issue from probe-lab/go-kademlia Oct 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Unplanned
Development

No branches or pull requests

1 participant