IPIP-309: IPNS Lagrange Replication #349
Conversation
There was a problem hiding this comment.
The idea worth exploring, some initial comments below and inlined.
- formalizing how peers other than original publisher can keep records alive sounds good, but this IPIP should clearly state in "Compatibility" section when IPNS reproviding starts and when it stops
- idea: mirror how regular provider records work: if CID gets garbage-collected, my node stops providing it. same could be applied to reproviding IPNS record (e.g. if root CID from the record is not pinned, providing stops when CID that IPNS record poitns at is garbage-collected).
- introduced threshold and interval knobs need some default values – ok to say "follow value from dht spec", but it needs to be explicitly stated
- removing expiration feels controversial and orthogonal to the rest of IPIP
- perhaps lifting expiration should be a separate IPIP (with detailed replay attack analysis)?
|
|
||
| **Lagrange Replication** is a system for maintaining a dynamic set of IPNS record holders, who will collectively keep the number of IPNS records above the highest threshold set amongst the nodes, so that the IPNS record owner does not need to remain online to periodically republish the IPNS record to the network. IPFS nodes will gain two new configuration options: | ||
|
|
||
| - The **Lagrange Threshold**: How many IPNS record holders need to exist before new record holders are searched for. |
There was a problem hiding this comment.
Specification should suggest default and max values for implementers.
For example, DHT spec has replication parameter k defined as 20.
Since IPNS records are stored on DHT too, is there any reason to go with different value?
| **Lagrange Replication** is a system for maintaining a dynamic set of IPNS record holders, who will collectively keep the number of IPNS records above the highest threshold set amongst the nodes, so that the IPNS record owner does not need to remain online to periodically republish the IPNS record to the network. IPFS nodes will gain two new configuration options: | ||
|
|
||
| - The **Lagrange Threshold**: How many IPNS record holders need to exist before new record holders are searched for. | ||
| - The **Lagrange Timing**: How often to check for the current number of IPNS record holders. |
There was a problem hiding this comment.
Similarly, specification should suggest a default interval for implementers.
fwiw the DHT spec has announcement interval of 24h.
|
|
||
| IPNS-PubSub would be the most ideal for lagrange replication, record holders would form a mesh which makes checking the number of record holders easier, however, the DHT will work fine as well. | ||
|
|
||
| IPNS records won't have anything set for the expiration field, this may interfere with implementations which expect this field to be populated. |
There was a problem hiding this comment.
Problem: no expiration (or a very high expiration) removes the protection against replay attacks.
How necessary is changing the default behavior of Validity field in the context of this IPIP?
I think replication would still work without touching it.
There was a problem hiding this comment.
The problem is that the main purpose of Lagrange replication is to remove the need for IPNS record expiration, without it I don't really know what it provides besides what IPNS-PubSub already does (unless you see benefits I haven't thought of).
Although as mentioned in your other comments, yeah, we need a replay attack analysis of this idea since it also needs to be an effective replacement for record expiration.
Co-authored-by: Marcin Rataj <[email protected]>
|
Closing for now, I don't really have the capability to move this pull further, replay attack analysis and an implementation are beyond what I can do, I'll leave #268 open as the idea |
Reopened from #309 in it's own branch