Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

XEP-0384 add an updated attribute to the device list #1398

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

XEP-0384 add an updated attribute to the device list #1398

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 13 additions & 3 deletions xep-0384.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,14 @@
<email>xmpp@larma.de</email>
<jid>jabber@larma.de</jid>
</author>
<revision>
<version>0.9</version>
<date>2024-10-29</date>
<initials>tj</initials>
<remark>
<p>Add updated datetime to device list</p>
</remark>
</revision>
<revision>
<version>0.8.3</version>
<date>2022-01-18</date>
Expand Down Expand Up @@ -415,7 +423,7 @@
<item id='current'>
<devices xmlns=']]>&ns;<![CDATA['>
<device id='12345' />
<device id='4223' label='Gajim on Ubuntu Linux' />
<device id='4223' label='Gajim on Ubuntu Linux' updated='2024-07-10T23:08:25Z'/>
</devices>
</item>
</items>
Expand All @@ -427,7 +435,8 @@
<p>In order for other devices to be able to initiate a session with a given device, it first has to announce itself by adding its device id to the devices PEP node.</p>
<p>It is REQUIRED to set the access model of the <tt>&nsdevices;</tt> node to ‘open’ to give entities without presence subscription read access to the devices and allow them to establish an OMEMO session. Not having presence subscription is a common occurrence on the first few messages between two contacts and can also happen fairly frequently in group chats as not every participant had prior communication with every other participant.</p>
<p>The access model can be changed efficiently by using publish-options.</p>
<p>The device element MAY contain an attribute called label, which is a user defined string describing the device that published that bundle. It is RECOMMENDED to keep the length of the label under 53 Unicode code points.</p>
<p>The device element MAY contain an attribute called ‘label’, which is a user defined string describing the device that published that bundle. It is RECOMMENDED to keep the length of the label under 53 Unicode code points.</p>
<p>The device element SHOULD also contain an ‘updated’ attribute. This attribute is formatted according to the DateTime profile defined in &xep0082; and is updated each time the corresponding device bundle is refreshed.</p>
<example caption='Adding the own device id to the list'><![CDATA[
<iq from='juliet@capulet.lit' type='set' id='announce1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
Expand Down Expand Up @@ -602,7 +611,7 @@
</section2>
<section2 topic='Receiving a message' anchor='usecases-receiving'>
<p>When an OMEMO element is received, the client MUST check whether there is a &lt;keys&gt; element with a jid attribute matching its own bare jid and an inner &lt;key&gt; element with a rid attribute matching its own device id. If this is not the case the message was not encrypted for this particular device and a warning message SHOULD be displayed instead. If such an element exists, the client checks whether the element's contents are an OMEMOKeyExchange.</p>
<p>If this is the case, a new session is built from this received element. The client MUST then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST eventually delete the private key belonging to the PreKey after use (this is subject to the <link url='#rules'>Business rules</link>).</p>
<p>If this is the case, a new session is built from this received element. The client MUST then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. The client SHOULD also republish its device list, updating the corresponding device element ‘updated’ attribute with the current datetime. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST eventually delete the private key belonging to the PreKey after use (this is subject to the <link url='#rules'>Business rules</link>).</p>
<p>If the element's contents are an OMEMOAuthenticatedMessage, and the client has a session with the sender's device, it tries to decrypt the OMEMOAuthenticatedMessage using this session. If the decryption fails or there is no session with the sending device, a warning message SHOULD be displayed instead. Also refer to the section about recovering from broken sessions in the <link url='#rules'>Business Rules</link>.</p>
<p>
After either the OMEMOKeyExchange or the OMEMOAuthenticatedMessage is decrypted, the content is decrypted as described in the section about <link url='#protocol-message_decryption'>Message Decryption</link>.
Expand Down Expand Up @@ -800,6 +809,7 @@
<xs:complexType>
<xs:attribute name='id' type='xs:unsignedInt' use='required'/>
<xs:attribute name='label' type='xs:string'/>
<xs:attribute name='updated' type='xs:string'/>
</xs:complexType>
</xs:element>

Expand Down
Loading