logo

litepub.social

Website of https://litepub.social/

overview.md (4462B)

    

  1. ---

  2. title: "LitePub top-level overview"

  3. ---

  4. 

  5. LitePub is a family of similar server-to-server protocols which each constitute a profile

  6. of [ActivityPub][ap].  They have been stripped down and are intended to be lightweight

  7. with easily understood security properties.

  8. 

  9.    [ap]: https://www.w3.org/TR/activitypub/

  10. 

  11. Information about differences between LitePub and ActivityPub can be found in the

  12. [LitePub for ActivityPub implementors][ap-compat] document.

  13. 

  14.    [ap-compat]: ap-compat.html

  15. 

  16. 

  17. ## Overview

  18. 

  19. In LitePub, operations are modelled as interactions between `actors`.  An actor could be,

  20. amongst other things, an user account, a bot, or a service.  LitePub implementations

  21. process messages which are delivered to `inboxes` and apply side effects based on the

  22. interpretation of those messages.  The exact behavior an implementation may take when

  23. presented with a message is implementation-defined.

  24. 

  25. 

  26. ### Message delivery

  27. 

  28. Messages are addressed to either `actors` or `collections`.  Every `actor` MUST have an

  29. `inbox` property and MAY have a `sharedInbox` property.  If an `actor` has a `sharedInbox`

  30. property, then an implementation MAY choose to deliver the message to the `sharedInbox`

  31. instead of directly to the actor's inbox.

  32. 

  33. Handling of `collections` SHOULD be treated as aliases for a group of known `actors`.

  34. Implementations MUST NOT attempt delivery directly to a `collection`.

  35. 

  36. Delivered messages MUST be signed and then delivered to `inboxes`.  The receiving server

  37. MUST authenticate the message following the rules below in the [Message authentication][auth]

  38. section.

  39. 

  40.    [auth]: #message-authentication

  41. 

  42. 

  43. ### Message authentication

  44. 

  45. LitePub messages are authenticated using a construction based on [HTTP Signatures][httpsigs].

  46. The `date` and `digest` headers MUST be signed, additional headers MAY be signed.

  47. 

  48.    [httpsigs]: https://tools.ietf.org/html/draft-cavage-http-signatures-10

  49. 

  50. 

  51. #### The `digest` header

  52. 

  53. LitePub messages MUST have a `digest` header of the following construction:

  54. 

  55.   * The hash method used

  56.   * An equals sign (`=`)

  57.   * The checksum from the hash method used in [base64 encoding][base64].

  58. 

  59. At a minimum, the SHA2-256 hash method MUST be used, using the identifier `SHA-256`.

  60. Implementations MAY send other digests by separating them with a space and using the

  61. same construction.

  62. 

  63. To generate the digest, the binary message body is hashed using the selected hash method.

  64. Implementations MUST verify that the signed digest header matches the received message

  65. body.

  66. 

  67. An example digest header:

  68. 

  69. ```

  70. Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

  71. ```

  72. 

  73. An example digest header with multiple digests:

  74. 

  75. ```

  76. Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

  77.   SHA-512=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

  78. ```

  79. 

  80.    [base64]: https://tools.ietf.org/html/rfc4648

  81. 

  82. 

  83. ### Message transience

  84. 

  85. *This section is non-normative.*

  86. 

  87. An important property of LitePub verses ActivityPub is that messages are intended to be

  88. transient, when message handling is properly implemented in this way, significant security

  89. advantages over the original ActivityPub approach are achieved, such as message deniability.

  90. 

  91. In respect to the LitePub specification process, this means that care has been taken to

  92. minimize the leakage of both message contents and data which can be used to forensically

  93. authenticate those messages.

  94. 

  95. It should be considered a significant violation of this specification to handle messages

  96. in a way that could result in the leakage of message contents or signature data to third

  97. parties.  However, strict adherence to the LitePub core protocol should result in an

  98. implementation which handles messages in a secure manner.

  99. 

  100. 

  101. ### Inclusion of objects by reference

  102. 

  103. *This section is non-normative.*

  104. 

  105. Another important property of LitePub verses ActivityPub is that message data integrity

  106. is controlled by the server which publishes the original message.  Accordingly, all

  107. message which reference another message MUST do so using the message's `id`.  The `id`

  108. of the message may be treated as a *reference*, as in JSON-LD.

  109. 

  110. When a message is deleted, the URI associated with the message `id` MUST NOT respond

  111. and SHOULD respond with an HTTP 404 or equivalent error code.  This does two things:

  112. 

  113.  * prevents further dissemination of the message through the federated graph

  114.  * provides plausible deniability about the existence of a message (spoofing argument)