Thinkofname/steven

[Request] Port to run on the web using emscripten?

Opened this issue · 3 comments

satoshinm commented

Any interest in targeting steven for web browsers using emscripten? Could be a possible viable alternative web-based client (background why I'm interested: been working on https://github.com/satoshinm/NetCraft/ which I ported from https://github.com/fogleman/Craft, written in pure C so it ported easily with emscripten, however, steven is much more fully-featured so it could be a good replacement).

Steven almost compiles with emscripten when passing --target asmjs-unknown-emscripten to cargo build, after applying #68 and updating a dependency satoshinm#1 but the main problems then seem to be:

  • OpenSSL: cross-compiling (or replacing? #67) for the web
  • Replacing download_vanilla - can't download arbitrary files (at least, I think that is the error I see in mangled C++ backtrace here: satoshinm#1 (comment))
  • Conditionally-compiling out other code as needed with #[cfg(target_os = "emscripten")]
Thinkofname commented
  • OpenSSL: Minecraft uses cfb8 which is outdated and not supported in ring
  • Running the download locally and letting emscripten pack them should work
  • This makes heavy use of threads for building chunks, emscripten stubs them out unless you have SharedArrayBuffers enabled (which only firefox really supports)

Additionally the networking wouldn't work as you can't use tcp within a browser.

I should also add that I don't have the time to work on steven so I wont really be able to help if you want to continue trying this

satoshinm commented

Thanks for the response! Totally understand not having time to work further on steven, appreciate what you've done so far, this is really neat. Some notes, to myself or others if they are interested in continuing trying porting Steven to Emscripten:

  • CFB mode: not supported in rust-crypto either... may have to add it, or another possibility, remove the MC protocol crypto and use HTTPS to communicate back to a server endpoint
  • SharedArrayBuffer: support is in-development on Chrome. However, although emscripten ostensibility supports it, in my testing adding -s USE_PTHREADS=1 to the emcc compile flags, it seems to never finish building (or takes unreasonably long). May need to be refactored to reduce use on threads. On the other hand, Craft compiled fine with tinycthreads? Not sure why (or does this explain the missing chunks? satoshinm/NetCraft#75)
  • Networking: This one is tractable, in NetCraft/WebSandboxMC I use WebSockets to communicate back to a WebSocket server written in Netty which runs on the Bukkit server and relays commands to/from it. WebSandboxMC uses a custom protocol, interacting with parts of the Bukkit API, but in principle it should be possible to bridge WebSockets to the MC protocol, with the proxy running on the MC server. The proxy could also handle the nasty CFB crypto, rewrapping it in SSL (wss://, or without: ws://), and would probably also have to do something about authentication (since the web client would not be permitted to contact the 3rd party authentications servers).
iceiix commented

@satoshinm I've made some progress on web support in my fork (using wasm32-unknown-unknown, not asmjs/wasm32-unknown-emscripten as in satoshinm#1):

web.mov

still a long ways to go, but its a start. iceiix/stevenarella#446 🕸️ Web support