add webxdc selfAddr/notify/href/ratelimit APIs (M2/M3)

[r10s]

the following task are open to complete M2/M3 proposal desktop-sided:

• change window.webxdc.selfAddr to "self_addr" property returned by dc_msg_get_webxdc_info()

• add and set window.webxdc.sendUpdateInterval to "send_update_interval" property returned by dc_msg_get_webxdc_info()

• add and set window.webxdc.sendUpdateMaxSize to "send_update_max_size" property returned by dc_msg_get_webxdc_info()

• when tapping an webxdc-info-message (dc_msg_get_info_type() returns DC_INFO_WEBXDC_INFO_MESSAGE), open the webxdc-app directly, do not move up (instead, the app menu should provide "Show in Chat, cmp add "show in chat" to webxdc menu deltachat-android#3447, but that can also be done later)

• when opening the webxdc-app from a webxdc-info-message, check dc_msg_get_webxdc_href(). if set, open the app with sth://base/HREF instead of sth://base/index.html
  if the app is already open, make sure, the location is changed (probably the same way), in any case, JavaScript's location properties should be set appropriate and hashchange should be fired as needed

• listen to event DC_EVENT_INCOMING_WEBXDC_NOTIFY. on receiving, add a notification with text set to "APPNAME: TEXT"; TEXT comes from the event. note, that the msg_id from the event may refer to a webxdc-instance or a webxdc-info-message (in the latter case, use get_parent() to get the instance)

jsonrpc types should be similar; if sth. is missing there, this is another task.

for reference, new spec is available already at https://github.com/webxdc/website/tree/next-main/src-docs/spec (

finally, make sure, the webxdc app does not exit when descr is left out, see #4359

corresponding Android / iOS PR: deltachat/deltachat-android#3438 , deltachat/deltachat-android#3449, deltachat/deltachat-ios#2412

[Simon-Laux]

note for person implementing this: for updating/changing webxdc href/url the location change needs to be done in the iframe.

[WofWca]

when tapping an webxdc-info-message, open the webxdc-app directly

IDK about the security of this. Do we want to open apps without the user expecting it?

[r10s]

thanks for the thought!

however, it has an app icon etc, no network etc. it is fine to start directly. if that is unexpected for existing users, ppl will learn it. also, the old indirection has barely prevented ppl from opening the app, when they already tapped curiously the info-message :)

[nicodh]

that the msg_id from the event may refer to a webxdc-instance or a webxdc-info-message (in the latter case, use get_parent() to get the instance)

It seems that in case of an added webxdc message (not webxdc info message) no DC_EVENT_INCOMING_WEBXDC_NOTIFY is fired but just a DC_EVENT_INCOMING_MSG
Is that on purpose or a bug?

[r10s]

that is on purpose, DC_EVENT_INCOMING_WEBXDC_NOTIFY is really only triggere by the webxdx-js-code, not by a delta-user adding an app

[nicodh]

So in which case the msg_id would refer to a webxdc-instance?

[nicodh]

Another question: should the notification show the icon of the webxdc app or the user profile (if any) or the default icon? As you see in #4400 I assumed the first

[nicodh]

In general it feels a bit wrong: the summary text comes from the event data, then we have to fetch getMessageNotificationInfo() method to get the chat name, the webxdcinfo message itself to get the parent message ID and then the parent message to get the app name. A getMessageNotificationInfo could already provide the appropriate texts for a WebxdcInfoMessage.
But getMessageNotificationInfo is a convenience method that exists only in jsonrpc right?

[nicodh]

So in which case the msg_id would refer to a webxdc-instance?

Found it in the docs:
Sometimes no webxdc-info-message is added to the chat and yet a notification is sent; in this case the msg_id of the webxdc instance is returned.

[Simon-Laux]

But getMessageNotificationInfo is a convenience method that exists only in jsonrpc right?

yes it is just a convenience method, so feel free to add what you want to it in core/jsonrpc