Website of https://litepub.social/

overview.md (4462B)

  1. ---
  2. title: "LitePub top-level overview"
  3. ---
  4. LitePub is a family of similar server-to-server protocols which each constitute a profile
  5. of [ActivityPub][ap]. They have been stripped down and are intended to be lightweight
  6. with easily understood security properties.
  7. [ap]: https://www.w3.org/TR/activitypub/
  8. Information about differences between LitePub and ActivityPub can be found in the
  9. [LitePub for ActivityPub implementors][ap-compat] document.
  10. [ap-compat]: ap-compat.html
  11. ## Overview
  12. In LitePub, operations are modelled as interactions between `actors`. An actor could be,
  13. amongst other things, an user account, a bot, or a service. LitePub implementations
  14. process messages which are delivered to `inboxes` and apply side effects based on the
  15. interpretation of those messages. The exact behavior an implementation may take when
  16. presented with a message is implementation-defined.
  17. ### Message delivery
  18. Messages are addressed to either `actors` or `collections`. Every `actor` MUST have an
  19. `inbox` property and MAY have a `sharedInbox` property. If an `actor` has a `sharedInbox`
  20. property, then an implementation MAY choose to deliver the message to the `sharedInbox`
  21. instead of directly to the actor's inbox.
  22. Handling of `collections` SHOULD be treated as aliases for a group of known `actors`.
  23. Implementations MUST NOT attempt delivery directly to a `collection`.
  24. Delivered messages MUST be signed and then delivered to `inboxes`. The receiving server
  25. MUST authenticate the message following the rules below in the [Message authentication][auth]
  26. section.
  27. [auth]: #message-authentication
  28. ### Message authentication
  29. LitePub messages are authenticated using a construction based on [HTTP Signatures][httpsigs].
  30. The `date` and `digest` headers MUST be signed, additional headers MAY be signed.
  31. [httpsigs]: https://tools.ietf.org/html/draft-cavage-http-signatures-10
  32. #### The `digest` header
  33. LitePub messages MUST have a `digest` header of the following construction:
  34. * The hash method used
  35. * An equals sign (`=`)
  36. * The checksum from the hash method used in [base64 encoding][base64].
  37. At a minimum, the SHA2-256 hash method MUST be used, using the identifier `SHA-256`.
  38. Implementations MAY send other digests by separating them with a space and using the
  39. same construction.
  40. To generate the digest, the binary message body is hashed using the selected hash method.
  41. Implementations MUST verify that the signed digest header matches the received message
  42. body.
  43. An example digest header:
  44. ```
  45. Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
  46. ```
  47. An example digest header with multiple digests:
  48. ```
  49. Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
  50. SHA-512=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
  51. ```
  52. [base64]: https://tools.ietf.org/html/rfc4648
  53. ### Message transience
  54. *This section is non-normative.*
  55. An important property of LitePub verses ActivityPub is that messages are intended to be
  56. transient, when message handling is properly implemented in this way, significant security
  57. advantages over the original ActivityPub approach are achieved, such as message deniability.
  58. In respect to the LitePub specification process, this means that care has been taken to
  59. minimize the leakage of both message contents and data which can be used to forensically
  60. authenticate those messages.
  61. It should be considered a significant violation of this specification to handle messages
  62. in a way that could result in the leakage of message contents or signature data to third
  63. parties. However, strict adherence to the LitePub core protocol should result in an
  64. implementation which handles messages in a secure manner.
  65. ### Inclusion of objects by reference
  66. *This section is non-normative.*
  67. Another important property of LitePub verses ActivityPub is that message data integrity
  68. is controlled by the server which publishes the original message. Accordingly, all
  69. message which reference another message MUST do so using the message's `id`. The `id`
  70. of the message may be treated as a *reference*, as in JSON-LD.
  71. When a message is deleted, the URI associated with the message `id` MUST NOT respond
  72. and SHOULD respond with an HTTP 404 or equivalent error code. This does two things:
  73. * prevents further dissemination of the message through the federated graph
  74. * provides plausible deniability about the existence of a message (spoofing argument)