From 0ff5f7162629d6077b9c79f44be7c17d641ab3a0 Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@riseup.net>
Date: Sat, 1 Jun 2019 20:39:57 +0000
Subject: [PATCH] FEDERATION.md: Write `events` property proposal

---
 FEDERATION.md | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/FEDERATION.md b/FEDERATION.md
index cfd8541..675c9a4 100644
--- a/FEDERATION.md
+++ b/FEDERATION.md
@@ -549,6 +549,39 @@ independent of any domain-specific vocabulary or extension.
 
 The current working name for this property is `managedBy`.
 
+#### (7) Events collection
+
+Defines a standard property to provide a collection of activities related to a
+given object.
+
+Suppose Aviva is writing a story, and publishing its chapters as ActivityPub
+activities. Aviva is an actor, with an inbox and with an outbox, but the
+chapters aren't actors. She publishes them using Create activities, in which
+the objects are of type Chapter or something like that. So, when Aviva
+publishes a chapter, it appears in her outbox.
+
+A while later, Luke joins her story writing project, and he writes some
+chapters too. When he writes a chapter, he publishes it and delivers to Aviva's
+inbox.
+
+From Aviva's point of view, her story's activities exist in 2 places:
+
+- Some of them exist in her outbox (the ones she publishes)
+- And some in her inbox (and ones Luke publishes, or any future contributor)
+
+If we wanted to get a list of all the activities and changes to the story, how
+would we do that? If the story were an actor, we could deliver everything to
+its inbox, and then its inbox would reflect all the events and changes. But
+since the story isn't an actor, there's no obvious place for this. We'd have to
+somehow get a filtered view of Aviva's outbox and a filtered view of Aviva's
+inbox for this. And the latter is especially problematic, because inboxes are
+generally private.
+
+This proposal suggests a property named `events`, which maps to an
+`OrderedCollection` of the activities related to the object. That way, even
+objects that aren't stand-alone and aren't actors can provide a stream of
+updates.
+
 ### (C) ForgeFed
 
 #### (1) Actors
@@ -721,6 +754,10 @@ TODO:
           { "@id":   "ext:dependedBy"
           , "@type": "@id"
           }
+      , "events":
+          { "@id":   "ext:events"
+          , "@type": "@id"
+          }
       }
     ]
 , "id":           "https://dev.federated.coop/luke/text-adventure/issues/113"
@@ -748,9 +785,14 @@ TODO:
     , "https://dev.community/jerry/text-game-engine/issues/1219"
     ]
 , "dependedBy": "https://dev.federated.coop/luke/text-adventure/issues/87"
+, "events":
+    [ ...
+    ]
 }
 ```
 
+TODO list actual examples under the "events" property (proposal B.7)
+
 TODO replies and depends (ForgeFed #12)
 
 TODO content/source and media types (ForgeFed #11)