@steveeJ re- server-side vs client-side; what advantages would you have server-side over client-side?
it could save resources where they are limited, e.g. on mobile devices. in your example we'd compare transferring a large file only to scale it down vs transferring a smaller file
I’ve been reading through ldp servers, rdf discussions and related things. And there has been discussions of sharing data, but to the point of “running code”, are there references to mechanisms (maybe even smart contracts / brokers) for automating the sharing of subsections of data? Add to that the ability (be it in RDF/etc) revoking that specific sharing.
a simple solution would be to require the binary to be signed with a key your pod trusts. also limiting the capabilities of specific binaries can be done. by default, WASM applications can't access the host so they would only be able to do what the chosen WASM runtime enables it do. the WASI standard uses a capability model to provide host/app communication.
@steveeJ not sure what you mean; if you say you prefer server-side you would have to transfer the full res photo from the client to the server for resizing and on my phone that would be roughly 3.8Mb. Now if you used wasm client-side to resample that image to possibly 3 target sizes for desktop / tablet and mobile, you would be looking at 1.3Mb for the set of 3 and that includes using generous low compress jpgs (photoshop 12 qual) and an icc profile each; Using full-res uploads for 6 images uploaded to you social site you'd be looking at a payload of 22Mb for mobile users. (too much IMO) a nice solution would be to resize the full res to desktop, then ask the server-side to create the tablet / phone versions, that way you'd only need to send a 675kb image payload.
@Julian-Cole aha, I understood that in your original scenario the pod has the full-version stored, the mobile device downloads it and applies the WASM script to it locally. thanks for clarifying