logo

litepub.social

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

overview.shtml (5156B)

    

  1. <!--#set var="title" value='LitePub Overview'--><!--#include file="templates/header.shtml" -->
  2. <p>
  3. LitePub is a family of similar server-to-server protocols which each constitute a profile of <a href="https://www.w3.org/TR/activitypub/">ActivityPub</a>.  They have been stripped down and are intended to be lightweight with easily understood security properties.
  4. </p>
  6. <p>
  7. Information about differences between LitePub and ActivityPub can be found in the <a href="/ap-compat">LitePub for ActivityPub implementors</a> document.
  8. </p>
  10. <h2 id="overview">Overview</h2>
  11. <p>
  12. In LitePub, operations are modelled as interactions between <code>Actor</code>s.  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 <code>inbox</code>es 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. </p>
  19. <h3 id="message-delivery">Message delivery</h3>
  20. <p>
  21. Messages are addressed to either <code>actor</code>s or <code>collection</code>.  Every <code>actor</code> MUST have an
  22. <code>inbox</code> property and MAY have a <code>sharedInbox</code> property.  If an <code>actor</code> has a <code>sharedInbox</code>
  23. property, then an implementation MAY choose to deliver the message to the <code>sharedInbox</code>
  24. instead of directly to the actor's inbox.
  25. </p>
  26. <p>
  27. Handling of <code>collection</code>s SHOULD be treated as aliases for a group of known <code>actors</code>.
  28. Implementations MUST NOT attempt delivery directly to a <code>collection</code>.
  29. </p>
  30. <p>
  31. Delivered messages MUST be signed and then delivered to <code>inbox</code>es.  The receiving server
  32. MUST authenticate the message following the rules below in the <a href="#message-authentication">Message authentication</a>
  33. section.
  34. </p>
  36. <h3 id="message-authentication">Message authentication</h3>
  37. <p>
  38. LitePub messages are authenticated using a construction based on <a href="https://tools.ietf.org/html/draft-cavage-http-signatures-10">HTTP Signatures</a>.
  39. The <code>date</code> and <code>digest</code> headers MUST be signed, additional headers MAY be signed.
  40. <!-- TODO: See what pleroma requires nowadays -->
  41. </p>
  43. <h4>The <code>digest</code> header</h4>
  44. <p>
  45. LitePub messages MUST have a <code>digest</code> header of the following construction:
  46. <ul>
  47. 	<li>The hash method used</li>
  48. 	<li>An equals sign (<code>=</code>)</li>
  49. 	<li>The checksum from the hash method used in <a href="https://tools.ietf.org/html/rfc4648">base64 encoding</a>.</li>
  50. </ul>
  51. </p>
  52. <p>At a minimum, the SHA2-256 hash method MUST be used, using the identifier <code>SHA-256</code>. Implementations MAY send other digests by separating them with a space and using the same construction.</p>
  53. <p>To generate the digest, the binary message body is hashed using the selected hash method. Implementations MUST verify that the signed digest header matches the received message body.</p>
  54. <p>An example digest header:
  55. <pre><code>
  56. Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
  57. </code></pre>
  58. </p>
  59. <p>An example digest header with multiple digests:
  60. <pre><code>
  61. Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
  62.   SHA-512=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
  63. </code></pre>
  64. </p>
  66. <h3>Message transience</h3>
  67. <p class="note">This section is non-normative.</p>
  68. <p>
  69. An important property of LitePub verses ActivityPub is that messages are intended to be
  70. transient, when message handling is properly implemented in this way, significant security
  71. advantages over the original ActivityPub approach are achieved, such as message deniability.
  72. </p>
  73. <p>
  74. In respect to the LitePub specification process, this means that care has been taken to
  75. minimize the leakage of both message contents and data which can be used to forensically
  76. authenticate those messages.
  77. </p>
  78. <p>
  79. It should be considered a significant violation of this specification to handle messages
  80. in a way that could result in the leakage of message contents or signature data to third
  81. parties.  However, strict adherence to the LitePub core protocol should result in an
  82. implementation which handles messages in a secure manner.
  83. </p>
  85. <h3>Inclusion of objects by reference</h3>
  86. <p class="note">This section is non-normative.</p>
  87. <p>
  88. Another important property of LitePub verses ActivityPub is that message data integrity
  89. is controlled by the server which publishes the original message.  Accordingly, all
  90. message which reference another message MUST do so using the message's <code>id</code>.  The <code>id</code>
  91. of the message may be treated as a <em>reference</em>, as in JSON-LD.
  92. </p>
  93. <p>
  94. When a message is deleted, the URI associated with the message <code>id</code> MUST NOT respond
  95. and SHOULD respond with an HTTP 404 or equivalent error code.  This does two things:
  96. <ul>
  97. 	<li>prevents further dissemination of the message through the federated graph</li>
  98. 	<li>provides plausible deniability about the existence of a message (spoofing argument)</li>
  99. </ul>
  100. </p>
  101. <!--#include file="templates/footer.shtml" -->