&webxdc; is a specification for sharing interactive embeddable widgets built with web-like technologies (HTML, JavaScript) via a chat platform, and sharing state between participants in the chat without allowing external network connections. In order to use these, the host protocol must define a way to transmit the widgets and the associated state updates.
+&webxdc; is a specification for sharing interactive embeddable widgets built with web-like technologies (HTML, JavaScript) via a chat platform, and sharing state between participants in the chat without allowing external network connections for the sandboxed web content. In order to provide support for &webxdc; widgets, the host protocol (XMPP in our case) must define a way to transmit these widgets and the associated state updates.
+This specification uses some terminology defined below:
+A widget may be attached to a message using any file-transfer mechanism supported by the client, such as &xep0066; or &xep0385;. The message MUST contain a <thread/> element with a new, unique id.
+A widget may be attached to a message using any file-transfer mechanism supported by the client, such as &xep0066; or &xep0385;. The message MUST contain a <thread/> element with a new, unique id. Note: including multiple file-transfer mechanisms in the same message may be beneficial for broader compatibility.
When a widget needs to communicate an update to other participants, this update may contain the following information:
+When a widget needs to communicate an update to peers in a chat, this update may contain one or more of the following items as defined in &webxdcSendUpdate;.
| Item | @@ -98,7 +126,7 @@Arbitrary JSON serializable value |
|---|
These items, except for the info item, are delivered in a message which MUST have the same <thread> as the message which originally delivered the widget itself, as children of an element <x xmlns="urn:xmpp:webxdc:0"> as defined below.
+These items are delivered in a message which MUST have the same <thread> as the message which originally delivered the widget itself. The stanza SHOULD contain a x child having the urn:xmpp:webxdc:0 namespace, with these items (except for info) as children, as defined below.
The info item is human-readable and is not needed by the widget itself, thus it is appropriate to transmit it anywhere that it might be visible to all participants, such as in a message body. If this is the only item present, an empty <x> element SHOULD still be included in the message to signal this update came from the widget.
WebXDC widgets get various data injected into them by the host application. One of these worth mentioning is the selfAddr property. When the chat is a 1:1 chat this property SHOULD be set to the XMPP URI for the local party's bare Jabber ID. When the chat supports &xep0421; this property SHOULD be set to the local party's occupant id.
+&webxdcaddrname; widgets get various data injected into them by the host application. One of these worth mentioning is the selfAddr property.
+The selfName property defined by &webxdcaddrname; is human readable and may be set to anything useful per that specification. It MAY be set to the local &xep0045; nickname or &xep0172; where relevant.
None
This XEP does not have any specific security considerations, however it is assumed that it will be paired with an implementation of &webxdc; which requires very careful sandboxing.
+It is assumed that an implementation of this XEP will be paired with an implementation of &webxdc;. Please see &webxdc; for sandboxing and security considerations for your WebXDC implementation.
+This XEP does not introduce any specific security considerations besides those present in any &webxdc; implementation.
It should be clear to users that their actions inside an embedded widget may be transmitted to other participants.