diff --git a/FEDERATION.md b/FEDERATION.md
index 675c9a4..e5e72bf 100644
--- a/FEDERATION.md
+++ b/FEDERATION.md
@@ -582,6 +582,34 @@ This proposal suggests a property named `events`, which maps to an
 objects that aren't stand-alone and aren't actors can provide a stream of
 updates.
 
+#### (8) List only direct related objects, not a flattened tree
+
+There are various properties that typically form a tree or graph structure when
+recursively traversed. And often a client may wish to fetch the entire
+hierarchy. For example, there's the AS2 `replies` property. The AS2 spec says
+it should list objects that are responses. But should/can that include indirect
+replies, i.e. objects that are replies to replies, or should only direct
+replies be listed, i.e. `replies` is the inverse property of `inReplyTo`?
+
+In ForgeFed there's similarly a `dependsOn` property for listing a ticket's
+dependent tickets, and the question arises there too: Provide a flat list
+containing the whole transitive closure of dependent tickets, i.e. dependencies
+of dependencies etc., or list the direct dependencies?
+
+I suppose to some people the answer to this question is obvious, but to me it
+wasn't, so I'd like to explicitly propose an answer and follow it.
+
+`replies`, and `dependsOn`, and similar properties, map to a collection whose
+items are the *direct related objects*, not indirect transitively-related
+ancestors of descendants. So, `replies` is the inverse property of `inReplyTo`,
+and if object A lists object B under `replies`, then the `inReplyTo` field of
+object `B` should be pointing back to `A`.
+
+It's still possible for object `B` to have its own `replies`, of course,
+forming a tree/graph of discussion (and `dependsOn` forming a graph of ticket
+dependencies). Whether or not those nested objects forming a tree/graph are
+provided, is a separate question. See proposal B.4.
+
 ### (C) ForgeFed
 
 #### (1) Actors