Is it possible to show apps inline (i.e. as part of the main chat) rather than opening a new window? E.g. the confetti app, would be nice for recipients just to see that as part of chat message than have to click and open in a new window. Same for document editing with the Editor app. Show at least a snippet of doc inline then chat members can click through to see the full doc and/or edit.
4 Likes
Interesting idea!
The most feasible way to achieve this in my vision are <iframe>s.
But then it’s harder isolate such apps from the internet, at least in Electron.
Orrrr actually, I think the <webview> tag is basically equivalent to an OS window inside of HTML? It can have its own session separate from the main app’s session, i.e. to have the same level of isolation as our current “separate window” approach.
(For reference, here is the Delta Chat Desktop code where we create the WebXDC window).
On Android / iOS I am not sure if something like this exists.
1 Like
sure would probably be possibly, but then you would execute random code without letting the user consent first by pressing start.
So could be a security issue (webview exploits would become near zero click attacks) and a privacy issue (web app could send back or log when you have viewed the chat).
So we would really need to think hard if we want that and what the usecases are.
Maybe there are alternative options to archive the usecases that don’t have these downsides.
Or it could be available only for signed apps that were security reviewed by the deltachat team.
Either way I’d say for now this is too much effort and thus out of scope. Though I’d be still interested in collecting ideas for what such inline webapps could be used for.
1 Like
Could be an option to set the thumbnail of the message, like there is an option to set the title and summary text.
Maybe not quite in the subject, but also related to applications
There is a Real-Time Apps setting that says that when using apps online, the IP address will be visible. I can see the direction of the attack, for example, force the user to use the application by sending him a document, or a game and see his IP (maybe I don’t understand something)
I think I should add to this setting the selection of contacts with whom I want to be online in applications, is it possible to do this?
1 Like
thumbnails would be a good start/compromise. I note some apps, like Image Album, already do this.
1 Like
I didn’t realise clicking “Start” on a webxdc app was consent for a potential security issue. Should there be a warning before doing so?
1 Like
static html+css would be less problematic but running JavaScript automatically in a chat?
html+css widgets would be interesting, similar to iOS widgets which can’t run any code but can have buttons which link into the app (we could do that the same way update.href feature that is already part of webxdc spec works) and are reloaded each status update.
such widgets could for example show the current status of a poll right in the chat and when you click vote you open the actual webxdc which can run js.
the process for generating a widget html from status updates should be sandboxed separately from the main webxdc though for obvious reasons like that it can track when you are online.
if running js sandboxed is a problem on some platforms we can maybe add this as a feature only for apps that are from the store as those are vetted.
2 Likes
there would also need to be guards that it can only use so much cpu cycles, otherwise you could send a message that slows down your chatlist.
There are alternative javascript runtimes (or wasm runtimes), which may offer a limit on instructions that can be executed. Another idea for such a background process could be to do planned notifications [1] or similar read-only tasks. Or you could potentially even also use this to display and update custom home screen widgets…
But all of this would add quite some complexity and we want to keep webxdc small and easy to implement. Maybe a thumbnail sent with the last update is already enough, sure may not be the latest data [2] and would be more network traffic [3], but I thing we should try that first, since it is a much smaller change/addition.
Besides, apple may not like running user code outside of their browser.
like waking up and checking if the planned notification is still valid, before sending it ↩︎
if the person sending the last update missed an update (due to delay) then it would be missing from the thumbnail → thumbnail would be the view of the user that sent it, not the view of the user that receives the thumbnail. But it may be fine as with multi-transport, dropped/delayed will become even more rare. ↩︎
though that could maybe be brought down if we specify SVG as format. ↩︎
1 Like
A use case for allowing to show webxdc of static HTML + CSS in the chat with JS disabled is to provide an alternative for space-efficient and accessible stickers, animations and lightweight interactive CSS-only galleries and combinatoric logic. You can already achieve this with SVG+SMIL, but competence for creating such from scratch is high and it can’t be usually reused elsewhere.
Whereas, existing png & jpg thumbnails of a game or the current snippet from the doc or calendar app could be represented by its own existing HTML&CSS without extra design effort if the app is implemented according to progressive enhancement (i.e., shows content without JS). I agree that a thumbnail (HTML+CSS) sent with the last update would be sufficient to achieve this - no need to generate it every time the chat is opened.
Adding clickable href to this as mentioned above would also be a natural extension. It could be used both for general interaction shortcuts as mentioned for voting. It could also make the flow of generally starting an app more seamless: pressing the button on the docked app could render the same app at the same space without much apparent jumps, while possibly replacing the locked-down iframe with a JS-enabled one under the hood. Such apps could still be made fullscreen or popped out to their own window on desktop by the user.
Additionally, if we allowed JS in apps signed by DC, the user or their trusted friends, technologies from the demoscene would enable displaying of compact animations & music as stickers within mere kilobytes instead of forwarding tens of megabytes of videos around.
1 Like
For animated stickers there is Lottie Support for telegram stickers - #4 by link2xt
Yes, I understand that. Its implementation enables reusing stickers stolen from other messenger apps. SVG is also discussed in that thread.
My suggestion above was to provide a better alternative, especially for content that users are expected to edit themselves. Supporting stickers of SVG+SMIL, SVG+CSS or HTML+CSS allows greater reuse back & forth and lowers the barrier to entry for content creators who are familiar with the long standardized SVG, CSS and HTML already - correlating with webxdc.