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

Jump to navigation Jump to search
no edit summary
(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)
168

edits

Navigation menu