Is it possible to offer delta.chat on Cloud Phone? Cloud Phone is a Chromium-based remote browser with the same WASM and networking (HTTPS, WSS, SSE) support as desktop Chromium, except it doesn’t offer WebRTC yet. Is a fully web-based app possible, or does it need to have TCP socket access for protocols like IMAP?
1 Like
Never heard of Cloud Phone, is it just sth like KaiOS based on chromium instead of firefox/gecko?
- WebRTC → is not needed by DeltaChat, for webxdc we went to great lengths to disable it.
- delta chat core (was recently renamed to chatmail-core) is written in rust, so it will be possible to adjust it to work in wasm, but will still take some work because of the non rust dependencies and the api differences between native and WebAPIs.
- You need TCP to speak SMTP and IMAP, but at least for chatmail we could host a proxy that translates web socket to those email protocols.
- we can add such a proxy to the chatmail relay, which means that every chatmail relay will have one eventually, though there is the question whether it would only allow to connect to the relay it is hosted at or to any email server, in the latter case it may get banned by bigger email providers for too much traffic.
For more details see the discussion in What would be needed for a Standalone web version without a server component?
Kind of. Both are web platforms that run on feature phones. However, KaiOS runs on device which means its resource constrained and in practice, it never gets updated. Cloud Phone is a remote browser like Opera Mini, but with many more features. It gets remotely updated regularly, and isn’t limited by on device storage or CPU/RAM. Although connections between the Cloud Phone client and server are encrypted, this means it’s not E2EE.
That’s interesting, although I’m not sure I understand the implications. Why would Delta Chat on Cloud Phone get banned by email providers? There’s no TCP socket API, so a WSS proxy would be needed.
I’ll follow the standalone web thread to see how that progresses
I mean if you use a classical email provider over a public proxy that many people with the same provider also use, then it may look like abuse from the providers perspective, like too many people connecting from the same ip address. But if the proxy is only for the chatmail relay instance it is hosted at, then this potential problem doesn’t exist.
so do the apps run on their cloud or on the device?
If you don’t care about E2EE and have always a connection, then you could already spin up a dc core for each user in the cloud and just connect over jsonrpc and https to it.
So you would basically need to host a server for each user. not ideal, but can be already done today without all the work that would be required to make deltachat core run standalone in wasm in a browser.
This would be similar to my plan of making a kaiOS version for rooted kaios phones, the only difference is that the web server would run locally on the phone as native process.
(BTW all the building blocks for a KaiOS version are there meanwhile, I just didn’t find enough time yet to assemble them together and write a web UI that works with small screen and keypad)
If you would be interested in helping me to write a UI for such keypad feature phones, then we could even attempt to apply for nlnet funding for developing a prototype.
We could use such an UI on Cloud Phones and KaiOS phone, use jsonrpc for core communication and a runtime interface similar to how we do it in desktop:
Later when core can be compiled to standalone wasm, then we could easily switch to it. The communication between core and ui would still use jsonrpc after all.
Apps run on the cloud, and the screen contents are streamed to the device
If the server needs to live longer than a single Cloud Phone user session, then this wouldn’t be viable. It would be better to wait for a standalone Wasm binary, since Cloud Phone uses Chromium 128+ it has much better Wasm support than KaiOS.
Sharing the UI is a good idea, although Cloud Phone goes as small as QQVGA (128x160), which can be quite different from QVGA (240x320). I’ve never heard of nlnet, but ideally the end outcome is an app that’s easily usable on these devices without complex configuration or a desktop computer. For many Cloud Phone users, this is the first time they will use the internet
1 Like
Well one of the points of delta chat is that it still works reliable in flaky/bad network conditions. The other one is privacy through E2EE. Both these points get taken away when you stream it onto a thin client.
Anyways the good point could be giving access to a big number of new users, which will sooner or later upgrade to a real phone, so it would could serve as advertisement, similar to how Microsoft, Apple and Adobe give special offers to schools to get the new generation hooked on their products. Or what was your initial idea on this?
So could be an idea to make a special lite version of delta chat that only supports chat mail servers to make it available to new internet users.
A bit unfortunate that push notifications don’t work yet: Progressive Web Apps for Cloud Phone
Also we’d need another way to get into contact, if qr code scanning is not possible because many devices have no camera, if I understand it correctly.
right, could also have scaling issues, even when you only run it only per session, it would still be ~14-40mb per instance¹, depending on usage. So something completely managed by the Cloud phone infrastructure would be better.
¹ I bet the wasm will also be much smaller because it won’t include big libraries like openssl.
Could be like this:
We have a “Lite”/“Cloud” version of Delta Chat for the cloud phone service. And one special chatmail server for them.
Users can onboard with a single click after typing in their name (if cloud phone does not already provide the user name to the app),
They can then get in contact with the normal delta chat qr codes or as a fallback, for the case that bot contacts use a cloud phone without camera, there would be a service where you can connect by typing in a short pairing code.
They can use a subset of what delta chat has to offer and when they buy a new phone later, they can move their profile / account to their normal phone or computer
→ there is a menu item which opens a screen about this, where they can learn about the advantages of the full delta chat version:
- even better encryption
- mini apps
- and other things the lite version lacks
This “Promo”-screen for the full version would also be shown when you try to access a mini app that does not support keyboard navigation and small screens (which could be a webxdc manifest key).
There would also be the option to transfer a profile to another cloud phone, but you can only transfer from dc lite to full dc, not the other way around (because a full dc account may make use of features that are not supported by the lite version, like using a classic IMAP/SMTP email account).
Haven’t read the full thread, just replying after taking a very short look at the Cloud Phone webpage
This would be possible with the recent work on de-coupling Delta Desktop from Electron
However it seems like it would absolutely impact, if not even outright break end-point security as it’d be Delta running on someone else’s machine, so I have my doubts Delta would officially be part of such a platform
Cloud Phone servers use ephemeral sessions only active when users launch the app. They’re encrypted using private keys only stored on end-user devices. However, you’re correct that the Cloud Phone server need to decrypt messages, store them on in data centers (using another private key), and effectively stream screenshots over an encrypted TLS socket.
It’s not true E2EE, and deviating from an official client would be unfortunate since we want a chat client that is interoperable with smartphones while still offering a good user experience. With proper branding, this could be an effective long-term advertisement to support user acquisition in emerging markets. If this becomes a Cloud Phone only app (so as to not violate E2EE), we could sponsor a relay server, some design work, and 4G develop phones, but we don’t have the engineering capacity or expertise to develop a forked Delta Chat app ourselves
1 Like