Theres been webxdc in Nostr clients. This is not crazy imo
Login to reply
Replies (18)
It's very easy to do on web clients... We don't have that luxury.
Do you know how Webxdc works? I've only used Webxdc in Native apps. I added it to my Kotlin client.
Yep. It's just a zip file of html + css + js. Then people put a wasm runtime in there to run more interesting things. You still need a browser/webview somewhere.
Yeah perhaps but its super light to implement. In fact my entire Client's apk is only 8mb even after the Webxdc support was added
Yep, if you don't care about security, the browser can just share the same memory of the app in a way that they can see each other. Then it's super easy. Kotlin has this baked in. But only because it uses the default installed browser on Android.
There is nothing like that on Kotlin desktop.
If its not secure why do White Noise, Delta chat, Armada & Vector all have it? I would think they would need more security than a social client
Maybe then haven't even realized the damage that running external code in your app can do. Amethyst runs the browser in a separate OS process in a way that disk, cpu and memory are fully isolated from one another. That's 50,000 lines of custom sandbox code just to do that.
Basically, the xdc game can see your nsec/wallet credentials in memory if it wants.
Webxdc is sand boxed though doesn't that mean anything? Also as far as Nsec you kinda gotta login with Amber for mine so no worries there also no internal wallet
Not if they just open in a web view. I have seen all kinds of security issues over the years. All your DMs are visible, they can access the camera, microphone, do a key logging. There are so many forms of attacks. Of course, the default libraries are trying their best to isolate it but the surface layer is absolutely massive, especially when you allow wasm binaries.
But by having it fully offline that means theres no outside directions or anything to send to. Then there's the possibility to make them malicious but same with anything else. If you make them with ai unless you're trying to it wouldn't since it goes off of Webxdc.org which tells it to build them to be private. I just really dont see anywhere it could go wrong honestly
The xdc file is just a zip file with a website. There is no sandbox at that level. The javascript can go crazy. If you just display on a webview, it has full permissions to render anything, since the view is equivalent to an iFrame, which has some protections to avoid mixing data between websites but it is not a sandbox. There is a lot that can go wrong, especially if the host app is vibecoded, which all of the ones you mentioned are these days.
Idk I really dont know enough about it. You should talk to the guys who have implemented it in their messengers
Why? I already implemented that as well with a separate process. Full sandboxed. I now we just added the same work to the desktop version, which doesn't have a OS-native browser (we had to add Chromium to play them)
So you're saying in order for them to be secure you need to basically build a browser into the app. Since I have basically nothing in my app that requires trust would it even make sense for me to do it especially if it causes bloat?
Not only build a browser in the app, but run it as a separate process from the OS, so that memory is fully separated from the app by the OS. Which means you have to create a way to render things in one program and send that image to another program to be displayed in the feed via some type of data bus. In that way, the OS can make that process offline without requiring the entire app to be offline. Similarly, the OS can manage permissions for that process regardless of the permissions granted to the app.
Why do things have to be so complicated I'll ๐ญ๐ญ๐ญ
welcome to software development. There is always an easy and wrong way to do things :)
Unfortunately so. Thanks for the info though