fun: Update XEP

This commit is contained in:
PapaTutuWawa 2022-08-25 13:53:43 +02:00
parent bbe91ca225
commit b219c4bb7a

View File

@ -17,15 +17,14 @@ that will be replaced once the file has been uploaded.
<file xmlns="urn:xmpp:file:metadata:0"> <file xmlns="urn:xmpp:file:metadata:0">
<name>vacation.jpg</name> <name>vacation.jpg</name>
<media-type>image/jpeg</media-type> <media-type>image/jpeg</media-type>
</file> <thumbnail type="blurhash" xmlns="proto:urn:xmpp:eft:0">
<thumbnail type="blurhash" xmlns="proto:urn:xmpp:file-thumbnails:0">
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash> <blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
</thumbnail> </thumbnail>
<thumbnail type="base64-bob" xmlns="proto:urn:xmpp:file-thumbnails:0"> <thumbnail type="base64-bob" xmlns="proto:urn:xmpp:eft:0">
<base64-bob uri="cid:sha1+...@bob.xmpp.org" media-type="image/png" width="128" height="96" /> <base64-bob uri="cid:sha1+...@bob.xmpp.org" media-type="image/png" width="128" height="96" />
</thumbnail> </thumbnail>
</file>
</file-upload> </file-upload>
<origin-id xmlns="urn:xmpp:sid:0" id="ccccc" />
<no-permanent-store xmlns="urn:xmpp:hints" /> <no-permanent-store xmlns="urn:xmpp:hints" />
</message> </message>
``` ```
@ -37,9 +36,6 @@ The metadata should include only the bare minimum, i.e. the mime type and filena
Additionally, zero or more thumbnails can be sent with the notification in order to allow clients Additionally, zero or more thumbnails can be sent with the notification in order to allow clients
to already show a preview. The `<file-thumbnail />` element is specified by [File Thumbnails](https://github.com/PapaTutuWawa/custom-xeps/blob/master/xep-xxxx-file-thumbnails.md). to already show a preview. The `<file-thumbnail />` element is specified by [File Thumbnails](https://github.com/PapaTutuWawa/custom-xeps/blob/master/xep-xxxx-file-thumbnails.md).
Note that [Unique and Stable Origin IDs](https://xmpp.org/extensions/xep-0359.html) must be used when the message is sent to a
groupchat.
Since this message carries no meaning to anyone retrieving it after the file upload has been Since this message carries no meaning to anyone retrieving it after the file upload has been
completed, a `<no-permanent-store />` element should be added (See [Message Processing Hints](https://xmpp.org/extensions/xep-0334.html)). completed, a `<no-permanent-store />` element should be added (See [Message Processing Hints](https://xmpp.org/extensions/xep-0334.html)).
@ -54,17 +50,14 @@ in the message to inform clients which messages should be replaced.
<x xmlns="jabber:x:oob"> <x xmlns="jabber:x:oob">
<url>...</url> <url>...</url>
</x> </x>
<replaces xmlns="proto:urn:xmpp:fun:0" id="ccccc" /> <replaces xmlns="proto:urn:xmpp:fun:0" id="aaaaa" />
<origin-id xmlns="urn:xmpp:sid:0" id="ddddd" />
</message> </message>
``` ```
The `id` attribute of the `<replaces />` element refers to either the stanza ID or the The `id` attribute of the `<replaces />` element refers to either the stanza ID of the
origin ID of the message that contained the original `<file-upload />`. message that contained the original `<file-upload />`.
If sent to a groupchat, the origin ID must be used. Note that the actual method of communicating a file is of no relevance here, as long as the
Note the the actual method of communicating a file is of no relevance here, as long as the
method allows a client to show it inline. Examples for such methods are method allows a client to show it inline. Examples for such methods are
[Out of Band Data](https://xmpp.org/extensions/xep-0066.html) [Out of Band Data](https://xmpp.org/extensions/xep-0066.html)
and [Stateless Inline Media Sharing](https://xmpp.org/extensions/xep-0385.html). and [Stateless Inline Media Sharing](https://xmpp.org/extensions/xep-0385.html).
@ -80,26 +73,24 @@ If the uploading entity has cancelled the upload, then it should indicate so to
```xml ```xml
<message from="some.user@some.server/abc123" to="someone.else@other.server" id="bbbbb"> <message from="some.user@some.server/abc123" to="someone.else@other.server" id="bbbbb">
<cancelled xmlns="proto:urn:xmpp:fun:0" /> <cancelled xmlns="proto:urn:xmpp:fun:0" id="aaaaa" />
<replaces xmlns="proto:urn:xmpp:fun:0" id="ccccc" />
<origin-id xmlns="urn:xmpp:sid:0" id="ddddd" />
</message> </message>
``` ```
In this example, the uploading entity just sends a message containing a `<cancelled />` tag to indicate the In this example, the uploading entity just sends a message containing a `<cancelled />` tag to indicate the
cancellation, allowing receiving clients to perhaps stop showing loading spinners and the like. The cancellation, allowing receiving clients to perhaps stop showing loading spinners and the
`<replaces />` is used to indicate what original message this cancellation applies to. like. Its `id` attribute refers to the message containing the original `<file-upload />`
element.
## Security Considerations ## Security Considerations
A client receiveing a message with an `<replaces />` element must verify if the message it - A client receiving a File Upload Notification must ensure that only messages containing a `<file-upload />` are replaced. This is to ensure arbitrary messages being replaced by file uploads.
is supposed to replace was actually sent by the sender of the `<replaces />` element to - A client receiving a File Upload Notification MUST ensure that replacements and cancellations are only accepted from the JID that sent the original message containing the `<file-upload />` element. This means that as long as the two JIDs are equal when bare, then the replacement or cancellation is valid.
prevent arbitrary messages to be replaced.
## Info ## Info
| Key | Value | | Key | Value |
| --- | --- | | --- | --- |
| Author | PapaTutuWawa | | Author | PapaTutuWawa |
| Version | 0.0.4 | | Version | 0.0.5 |
| Short name | fun | | Short name | fun |