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