logo

litepub.social

Website of https://litepub.social/ git clone https://anongit.hacktivis.me/git/litepub.social.git/

objects.md (5232B)

    

  1. ---
  2. title: "LitePub (Objects)"
  3. status: "Living Standard"
  4. last_updated: "June 26, 2019"
  5. ---
  7. ### Architectural Introduction
  9. *This section is non-normative.*
  11. LitePub and other applications of [ActivityStreams][as2] are built on top of an
  12. object-oriented architecture.  Unlike previous specifications concerning this
  13. protocol, we present the object model in a flat way, where all objects are
  14. derived from the base Object type.  It is our hope that this presentation is
  15. more easily understood by the reader as well as more reflective of reality.
  17.    [as2]: https://www.w3.org/TR/activitystreams-core
  19. In production, we have learned that maintaining an artificial partition between
  20. the notion of regular objects (which reflect data) and activities (which reflect
  21. mutations on data) significantly increases the complexity involved in walking
  22. a graph of activities.  Accordingly, we have come to see the artificial partition
  23. as more harmful than helpful, especially when storing graphs in normalized form
  24. inside so-called "NoSQL" and traditional SQL databases.
  27. ### Handling of Objects
  29. LitePub implementations process [ActivityStreams][as2] objects and store
  30. them and/or interpret them to perform mutations on other objects.  To facilitate
  31. this, LitePub defines additional vocabulary on top of the [ActivityStreams
  32. core vocabulary][as2-vocab].
  34.    [as2-vocab]: https://www.w3.org/TR/activitystreams-vocabulary
  36. Information about handling the full [LitePub vocabulary][lp-vocab] is in
  37. available in the LitePub vocabulary section.
  39.    [lp-vocab]: vocabulary.html
  42. #### Processing of Referenced Objects
  44. LitePub objects reference other objects.  Objects are referenced by IRI
  45. ([RFC3987][rfc3987]).  Every URI ([RFC3986][rfc3986]) is also usable as
  46. an IRI.
  48. Relative IRI references MUST NOT be used inside a LitePub object.
  50.    [rfc3986]: https://tools.ietf.org/html/rfc3986
  51.    [rfc3987]: https://tools.ietf.org/html/rfc3987
  53. Servers MUST validate the content they receive to avoid content spoofing
  54. attacks as well as to verify that processing the object does not induce
  55. any mutations which would be disallowed by the server's configured policy.
  56. There are two security models specified by this specification in the
  57. [security considerations][lp-security] section.
  59.    [lp-security]: security.html
  62. #### Object Requirements
  64. All LitePub objects MUST have the following fields:
  66. * `id`: the object's identifier (as an IRI)
  67. * `type`: the object's type
  70. #### Object Identifiers and Transience
  72. All LitePub objects MUST have unique global identifiers.  If an object
  73. is received without an identifier, the receiver MAY assign the object an
  74. internally generated identifier.
  76. Servers MAY respond with an HTTP 410 response code when fetched by their
  77. global identifier to indicate their transcience.
  80. #### Object Deletion
  82. Servers SHOULD replace the deleted object with a `Tombstone` to prevent
  83. re-use of the identifier or possible refetching of remote objects.
  85. Servers MUST respond with an HTTP 404 response code when a `Tombstone`
  86. object is encountered.
  88. Servers MUST NOT serve the contents of the `Tombstone` object.
  90. Servers SHOULD delete any local copies of an object if refetching the
  91. object results in either a 404 or 410 response code being returned.
  93. > **Note**: ActivityPub implementations are allowed to respond with
  94. > either 404 or 410 as well as serving the underlying `Tombstone`
  95. > object.  This behaviour is flawed because it results in metadata
  96. > leakage -- namely, it leaks that an object did at one time exist
  97. > with the given identifier.
  100. #### Object Delivery
  102. Servers SHOULD track which peers they have successfully delivered a
  103. given object to.
  105. Servers SHOULD broadcast `Delete` messages to all peers they
  106. successfully delivered the message to.
  109. #### Object Serving and Fetching
  111. Servers MAY require authorization to serve any object, including
  112. objects addressed to `https://www.w3.org/ns/activitystreams#Public`.
  114. Servers MUST require authorization to serve any object not
  115. addressed to `https://www.w3.org/ns/activitystreams#Public`.
  117. Servers SHOULD treat authorized object fetch requests as deliveries
  118. to the authorized peer and record them as a successful delivery.
  121. #### Description of Object Processing Algorithm
  123. *This section is non-normative.*
  125. A possible algorithm for processing objects according to the above
  126. defined rules would be:
  128. 1. Verify the object's `id` is unique and not yet stored in the
  129.    object graph.
  131. 2. Verify that the object's `type` is processable by the
  132.    LitePub implementation.
  134. 3. Iterate over all properties in the object looking for potential
  135.    children (any property typed as an `id` or any included child
  136.    objects).
  138. 4. For each child object, replace the object with an authoritative
  139.    local copy of the object.  Fetch new authoritative copies of any
  140.    missing objects.
  142. 5. For all children, return to step 2 with the child object as the
  143.    processing context.
  145. 6. If authoritative versions of any children are missing, reject
  146.    the root object if transitive child objects are not allowed for
  147.    the root object's `type`.
  149. 7. Apply any required side effects or mutations prescribed by the
  150.    root object's `type`.
  152. 8. Store the root object in the object graph using it's `id`.