aboutsummaryrefslogtreecommitdiffstats
path: root/docs/MESHBAY_DESIGN.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/MESHBAY_DESIGN.md')
-rw-r--r--docs/MESHBAY_DESIGN.md14
1 files changed, 14 insertions, 0 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 86b8e8f..6053bd8 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -2348,6 +2348,20 @@ Two rules for a new application here:
group is a top-level folder, and merging would remove a file from one of them. A
test refuses a build that changes this.
+**A group can be left out of Search** — `search_listed`, a per-group setting on the
+node, signed by the operator and carried in the sealed ack. Search reads it after the
+handshake and stops there: no index is asked for, cached or merged, in any of the four
+views. The case it exists for is a family album that should not turn up in the middle
+of a film library.
+
+> **It is a listing preference and it protects nothing, against anyone.** The node
+> cannot tell Search's request from the group page's and serves the same index to
+> both; every member lists the whole group by opening it; a client that ignores the
+> flag lists the group in Search too. It must never be described as "private" or
+> "confidential". What it costs is one handshake per unlisted group, because only the
+> node knows the setting — a hub-side flag would save that and put group state on the
+> hub (§1.3).
+
One consequence is deliberate and is not a bug: albums are keyed by directory, so
two groups whose roots have *different* basenames put the same photo into two
differently-named albums, and the merge — scoped to a unit — leaves it in both. They