From 7eadbff9cfd4899e59627e823ae9fe0df1aef06f Mon Sep 17 00:00:00 2001 From: Bryan Newbold Date: Sun, 6 May 2018 20:01:46 -0700 Subject: clarify that contentFeed is immutable --- proposals/0000-hyperdb.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/proposals/0000-hyperdb.md b/proposals/0000-hyperdb.md index e0f9f2c..634ef15 100644 --- a/proposals/0000-hyperdb.md +++ b/proposals/0000-hyperdb.md @@ -175,12 +175,13 @@ types are: cases. - `inflate`: a "pointer" (reference to a feed index number) to the most recent entry in the feed that has the optional `feeds` and `contentFeed` fields set. - Not defined if `feeds` and `contentFeed` are defined. + Not defined if `feeds` and `contentFeed` are defined in the same message. - `feeds`: reserved for use with `multi-writer`. The safe single-writer value is to use the current feed's hypercore public key. - `contentFeed`: for applications which require a parallel "content" hypercore feed for larger data, this field can be used to store the 32-byte public key - for that feed. + for that feed. This field should have a single value for the entire history + of the feed (aka, it is not mutable). For the case of a single-writer feed, not using multi-writer features, it is sufficient to write a single Entry message as the first entry in the hypercore @@ -719,9 +720,6 @@ Further logistical details are left to the forthcoming Multi-Writer DEP. # Unresolved questions [unresolved]: #unresolved-questions -Should we declare that `contendFeed` pointers *not* change over the history of -a feed? See also - Need to think through deletion process with respect to listing a path prefix; will previously deleted nodes be occluded, or potentially show up in list results? Should be reviewed (by a non-author of this document) before accepted -- cgit v1.2.3