Would it be possible to allow native apps to use Delta Chat as a transport between the various users, to persist the data, and to provide the identity of the users? I would expect:
The user probably needs to have Delta Chat installed to use these “native-xdc” apps
The “native-xdc” apps should communicate with Delta Chat over a standard interface, that could also be implemented by other apps (chatmail or other kinds of messengers)
They should not have access to all the user’s messages; they should only have the access to the messages that a webxdc app has, and need to be invited to each group separately just like a webxdc app
The app should not need to implement IMAP or SMTP, that should be the job of Delta Chat
All deltachat apps are actually using this strategy. They’re all nice frontends on top of chatmail core. Chatmail core is a binary you run and interact with over standard input and output with json messages. Here’s a blog post detailing how it works at the lowest level:
There are also libraries to make it easier to work from other languages, like go or python
The request uses unusual terminology and seems to blur the boundary between at least three things. Could you please share a more concrete scenario for what you would like to use this for?
Let me see whether I understand it correctly. You find the webxdc sandbox too constrained and inefficient, hence you would like to implement a game outside the sandbox (or extend an existing native app) and possibly ship it using a native package manager.
In this use case, it would be desirable if the given game would not have to rely on the lowest level RPC API that also gave unrestricted access to all accounts (or run a separate RPC loop for each such app). Rather, a more restrictive API would need to be built on top of this via which each app could be granted granular permission per-chat on a shared instance of the RPC API (or DC client). This would be very expensive to build (much simpler things could not be completed within years).
In place of having to operate a game backend, you would like to pipe the multiplayer code through webxdc update payloads or Iroh. This would already be possible without DC using WebRTC or STUN/TURN. You would like to implement access control by relying on manual invitation to private Delta Chat groups. This would also be possible to accomplish with invite code passwords. For otherwise interacting with groups by native code, separate bot daemons are usually built. What use would you have from Delta Chat?
The idea is to add collaboration to an existing native application, which might have been written using Gtk or with many kinds of legacy or native technologies. I am thinking of an old document-based application such as LibreOffice, or a more recent Mac application, for example. This way, the application can integrate with the user’s system, run more efficiently than a wasm app painting to a framebuffer, and be easier to build.
I know that webxdc applications with documents can persist their documents over time, but I’m not exactly sure how that works. For example, in the webxdc editor example, I can edit the document on two devices, close the document on both devices, and edit it later. If I edit it on device A while device B is offline, and then device A connects to the mail server, then device B edits it while device A is offline, (to my understanding) the document will contain device A’s changes when device B opens it. This is not possible via WebRTC or STUN/TURN.
Would you ship this altered LibreOffice app in an existing native package manager or do you envision it and its updates being shipped between chat members similarly to webxdc and then expect Delta Chat to supervise the executable inside a sandboxed container?
A webxdc app can store state in the local storage of a device of the user (not recommended) or within the given chat that corresponds to the webxdc instance.
Never say never. A group of 10 members can form a P2P swarm to sync all changes to a document among them via CRDT (the same algorithm the mentioned webxdc editor uses). As long as at least 2 of them get online around the clock, the changes can eventually replicate to all members sooner or later. If less are online, syncing will just happen later, not unlike what happens when one would be editing the document when offline even if they had access to a chatmail server. You would just use a chatmail server as a temporary file buffer for this use case, not unlike how you used WebDAV or any other storage through a simple API for the same purpose.
If the application is shipped and supervised separately, it does not qualify for the definition of a “webxdc mini app”, because that would imply that Delta Chat is in charge of its distribution and life cycle. Let me adjust the topic labels accordingly.
The point is that it should have exactly the same capabilities as a webxdc app and use the same kind of inter-instance communication (via iroh and via hidden messages sent in the chat), in addition to the normal capabilities of a native app. I agree that it is better to put this discussion into the “Feature Proposal” section, though.