commit: d511b3c7d9a9aca9d6d537366ba40ab6713f5e45
parent 0ec4083628cbff4541855bd69c4b66b3491ca2be
Author: William Pitcock <nenolod@dereferenced.org>
Date: Sat, 29 Jun 2019 18:03:19 -0500
spec: add objects section
Diffstat:
2 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/spec/index.md b/spec/index.md
@@ -7,3 +7,5 @@ last_updated: "June 26, 2019"
### Table of Contents
1. [Introduction](intro.html)
+2. [Objects](objects.html)
+
diff --git a/spec/objects.md b/spec/objects.md
@@ -0,0 +1,118 @@
+---
+title: "LitePub (Objects)"
+status: "Living Standard"
+last_updated: "June 26, 2019"
+---
+
+### Architectural Introduction
+
+*This section is non-normative.*
+
+LitePub and other applications of [ActivityStreams][as2] are built on top of an
+object-oriented architecture. Unlike previous specifications concerning this
+protocol, we present the object model in a flat way, where all objects are
+derived from the base Object type. It is our hope that this presentation is
+more easily understood by the reader as well as more reflective of reality.
+
+ [as2]: https://www.w3.org/TR/activitystreams-core
+
+In production, we have learned that maintaining an artificial partition between
+the notion of regular objects (which reflect data) and activities (which reflect
+mutations on data) significantly increases the complexity involved in walking
+a graph of activities. Accordingly, we have come to see the artificial partition
+as more harmful than helpful, especially when storing graphs in normalized form
+inside so-called "NoSQL" and traditional SQL databases.
+
+
+### Handling of Objects
+
+LitePub implementations process [ActivityStreams][as2] objects and store
+them and/or interpret them to perform mutations on other objects. To facilitate
+this, LitePub defines additional vocabulary on top of the [ActivityStreams
+core vocabulary][as2-vocab].
+
+ [as2-vocab]: https://www.w3.org/TR/activitystreams-vocabulary
+
+Information about handling the full [LitePub vocabulary][lp-vocab] is in
+available in the LitePub vocabulary section.
+
+ [lp-vocab]: vocabulary.html
+
+
+#### Processing of Referenced Objects
+
+LitePub objects reference other objects. Objects are referenced by IRI
+([RFC3987][rfc3987]). Every URI ([RFC3986][rfc3986]) is also usable as
+an IRI.
+
+Relative IRI references MUST NOT be used inside a LitePub object.
+
+ [rfc3986]: https://tools.ietf.org/html/rfc3986
+ [rfc3987]: https://tools.ietf.org/html/rfc3987
+
+Servers MUST validate the content they receive to avoid content spoofing
+attacks as well as to verify that processing the object does not induce
+any mutations which would be disallowed by the server's configured policy.
+There are two security models specified by this specification in the
+[security considerations][lp-security] section.
+
+ [lp-security]: security.html
+
+
+#### Object Requirements
+
+All LitePub objects MUST have the following fields:
+
+* `id`: the object's identifier (as an IRI)
+* `type`: the object's type
+
+
+#### Object Identifiers and Transience
+
+All LitePub objects MUST have unique global identifiers. If an object
+is received without an identifier, the receiver MAY assign the object an
+internally generated identifier.
+
+Servers MAY respond with an HTTP 410 response code when fetched by their
+global identifier to indicate their transcience.
+
+
+#### Object Deletion
+
+Servers SHOULD replace the deleted object with a `Tombstone` to prevent
+re-use of the identifier or possible refetching of remote objects.
+
+Servers MUST respond with an HTTP 404 response code when a `Tombstone`
+object is encountered.
+
+Servers MUST NOT serve the contents of the `Tombstone` object.
+
+Servers SHOULD delete any local copies of an object if refetching the
+object results in either a 404 or 410 response code being returned.
+
+> **Note**: ActivityPub implementations are allowed to respond with
+> either 404 or 410 as well as serving the underlying `Tombstone`
+> object. This behaviour is flawed because it results in metadata
+> leakage -- namely, it leaks that an object did at one time exist
+> with the given identifier.
+
+
+#### Object Delivery
+
+Servers SHOULD track which peers they have successfully delivered a
+given object to.
+
+Servers SHOULD broadcast `Delete` messages to all peers they
+successfully delivered the message to.
+
+
+#### Object Serving and Fetching
+
+Servers MAY require authorization to serve any object, including
+objects addressed to `https://www.w3.org/ns/activitystreams#Public`.
+
+Servers MUST require authorization to serve any object not
+addressed to `https://www.w3.org/ns/activitystreams#Public`.
+
+Servers SHOULD treat authorized object fetch requests as deliveries
+to the authorized peer and record them as a successful delivery.
