create internal VerifierNode/RepairerNode classes #847

New Issue

warner · 2009-11-30T23:48:48Z

warner commented

2009-11-30 23:48:48 +00:00

I'd like to have a set of VerifierNode and/or RepairerNode classes, created by the nodemaker, which implement IVerifiable and IRepairable (but not IFilesystemNode). This would be the first step towards fixing #482, by giving us an object that represents what we can do with a given verifycap/repaircap.

I'm thinking that these objects might be created with or without the integrity information. If without, it would just wrap a storage-index. It'd be nice to be able to find out what the SI represents, determine its UEB value (by consensus, not by cryptographically-ensured integrity values), and then verify/repair the file on the assumption that those shares were correct.

I'd like to have a set of `VerifierNode` and/or `RepairerNode` classes, created by the nodemaker, which implement `IVerifiable` and `IRepairable` (but not `IFilesystemNode`). This would be the first step towards fixing #482, by giving us an object that represents what we can do with a given verifycap/repaircap. I'm thinking that these objects might be created with or without the integrity information. If without, it would just wrap a storage-index. It'd be nice to be able to find out what the SI represents, determine its UEB value (by consensus, not by cryptographically-ensured integrity values), and then verify/repair the file on the assumption that those shares were correct.

warner added the

labels 2009-11-30 23:48:48 +00:00

warner added this to the eventually milestone 2009-11-30 23:48:48 +00:00

davidsarah commented

2009-12-06 00:15:43 +00:00

Replying to warner:

It'd be nice to be able to find out what the SI represents, determine its UEB value (by consensus, not by cryptographically-ensured integrity values), and then verify/repair the file on the assumption that those shares were correct.

When would you have a storage index but not a verify cap? If we had traversal/deep-verify caps, would that obviate the need for this feature? It seems risky to be encouraging attempts to repair a file without having sufficient information to be sure that the repair is correct.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/5909): > It'd be nice to be able to find out what the SI represents, determine its UEB value (by consensus, not by cryptographically-ensured integrity values), and then verify/repair the file on the assumption that those shares were correct. When would you have a storage index but not a verify cap? If we had traversal/deep-verify caps, would that obviate the need for this feature? It seems risky to be encouraging attempts to repair a file without having sufficient information to be sure that the repair is correct.