168
edits
Difference between revisions of "XEP-Remarks/XEP-0373: OpenPGP for XMPP"
Jump to navigation
Jump to search
XEP-Remarks/XEP-0373: OpenPGP for XMPP (view source)
Revision as of 09:42, 30 August 2018
, 09:42, 30 August 2018→Key publication, notification and retrieval
| Line 3: | Line 3: | ||
The XEP has undergone already one change regarding key publication, notification and retrieval of key material. 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. | The XEP has undergone already one change regarding key publication, notification and retrieval of key material. 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" | 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" pont-of-view, an ideal solution would possibly be to | ||
* Use a single node per key type (public- / secret-key) | * 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 XEP-0060 "notification only" nodes (configuration value: pubsub#deliver_payloads), 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 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) | * Use a fixed string for the PubSub/PEP node names (like it is already done right now for the metadata nodes) | ||
Although there appears to be no direct way to query the PubSub/PEP service if it supports pubsub#deliver_payloads, it may be possible for entities to probe the availability of this feature by attempting to create a "dummy" node where pubsub#deliver_payloads is set to true. IIRC recent changes to XEP-0060 require services to return an error on unknown configuration values. But this is fragile until this requirement is deployed widely. So ultimately, the entity possibly also wants to verify if setting has been respected and became effective. | |||