Difference between revisions of "XEP-Remarks/XEP-0373: OpenPGP for XMPP"

From XMPP WIKI
Jump to: navigation, search
(Created page with "= Key publication, notification and retrieval = The XEP has undergone already one change regarding key publication, notification and retrieval. The initial used approach was...")
 
Line 5: Line 5:
 
While it turned out to work quite well, it is not elegant with regard to the mechanisms the involved protocols provide. From a pure "what the specification describes" POV an ideal solution would possibly be to
 
While it turned out to work quite well, it is not elegant with regard to the mechanisms the involved protocols provide. From a pure "what the specification describes" POV an ideal solution would possibly be to
  
* Use XEP-0060 "notification only" nodes, which would only push the node id to the subscribed entity (but was only recently implemented in prosody and the feature is not discoverable, most likely because it appears to be mandatory by XEP-0060).
+
* Use a single node per key type (public- / secret-key)
 +
* Use XEP-0060 "notification only" nodes, which would only push the node id to the subscribed entity (but was only recently implemented in prosody and the feature is not discoverable, most likely because it appears to be mandatory by XEP-0060).
 +
* Use a timestamp, possibly in XEP-0082 DateTime profile format, as item IDs
 +
* Use a fixed string for the PubSub/PEP node names (like it is already done right now for the metadata nodes)

Revision as of 09:35, 30 August 2018

Key publication, notification and retrieval

The XEP has undergone already one change regarding key publication, notification and retrieval. The initial used approach was found to be quite traffic demanding, because the full key data was pushed to interested entities every time they appeared online. Thus it was decided to split the key into metadata and data PubSub/PEP nodes.

While it turned out to work quite well, it is not elegant with regard to the mechanisms the involved protocols provide. From a pure "what the specification describes" POV an ideal solution would possibly be to

  • Use a single node per key type (public- / secret-key)
  • Use XEP-0060 "notification only" nodes, which would only push the node id to the subscribed entity (but was only recently implemented in prosody and the feature is not discoverable, most likely because it appears to be mandatory by XEP-0060).
  • Use a timestamp, possibly in XEP-0082 DateTime profile format, as item IDs
  • Use a fixed string for the PubSub/PEP node names (like it is already done right now for the metadata nodes)