mirror of
https://gitlab.com/veilid/veilid.git
synced 2024-10-01 01:26:08 -04:00
Merge branch 'clarify-wasm-limitations' into 'main'
Clarify that WASM bootstrap uses ws, not wss or DNS See merge request veilid/veilid!205
This commit is contained in:
commit
bb78723ce8
@ -6,22 +6,23 @@ This package is a Rust cargo crate the generates WebAssembly (WASM) bindings for
|
||||
|
||||
Running Veilid in the browser via WebAssembly has some limitations:
|
||||
|
||||
### Browser-based limitaions
|
||||
### Browser-based limitations
|
||||
|
||||
1. TCP/UDP sockets are unavilable in the browser. This limits WASM nodes to communicating using WebSockets.
|
||||
1. Lookup of DNS records is unavaible in the browser, which means bootstrapping via TXT record also will work. WASM nodes will need to connect to the bootstrap server directly via WebSockets, using this URL format: `ws://bootstrap.veilid.net:5150/ws` in the `network.routing_table.bootstrap[]` section of the veilid config.
|
||||
1. Since a WASM node running in the browser can't open ports, WASM nodes select another node to act as it's Inbound Relay, so other nodes can react out to it and open a WS connection.
|
||||
1. TCP/UDP sockets are unavailable in the browser. This limits WASM nodes to communicating using WebSockets.
|
||||
1. Lookup of DNS records is unavailable in the browser, which means bootstrapping via TXT record also will not work. WASM nodes will need to connect to the bootstrap server directly via WebSockets, using this URL format: `ws://bootstrap.veilid.net:5150/ws` in the `network.routing_table.bootstrap[]` section of the veilid config.
|
||||
1. Do not set up any nodes with a core.network.protocol.wss.url IP address such as wss://12.34.56.78:5150/ws to support SSL. Even though a Certificate Authority (trusted by browsers) will give you an SSL certificate for an IP address, this is unsupported by Veilid as of v0.2.3. Any wss:// URL containing an IP address causes an RPC error in veilid-core and your node will lose communication with other nodes.
|
||||
1. Since a WASM node running in the browser can't open ports, WASM nodes select another node to act as its Inbound Relay, so other nodes can react out to it and open a WS connection.
|
||||
1. Because of browser security policy regarding WebSockets:
|
||||
1. `ws://` only works on `http://` sites
|
||||
1. `wss://` only works on `https://` site with SSL certificates.
|
||||
|
||||
### Running WASM on HTTPS sites [Not currently implemented]
|
||||
|
||||
Since WSS connections require WSS peers with valid SSL certificates, `veilid-core` plans to implment a feature called Outbound Relays. Outbound Relays will likely be hosted by the same host of the WASM web-app, and must run have valid SSL certificates that are signed by a Certificate Authority that's trusted by browsers. Outbound Relays will allow WASM nodes to communicate to other nodes over TCP/UDP/WS/WSS through the Outbound Relay's connection.
|
||||
Since WSS connections require WSS peers with valid SSL certificates, `veilid-core` plans to implement a feature called Outbound Relays. Outbound Relays will likely be hosted by the same host of the WASM web-app, and must run have valid SSL certificates that are signed by a Certificate Authority that's trusted by browsers. Outbound Relays will allow WASM nodes to communicate to other nodes over TCP/UDP/WS/WSS through the Outbound Relay's connection.
|
||||
|
||||
## Running unit tests
|
||||
|
||||
Prerequsites:
|
||||
Prerequisites:
|
||||
|
||||
- NodeJS - ensure `node` and `npm` are installed.
|
||||
- Firefox browser installed, and available as `firefox`.
|
||||
|
Loading…
Reference in New Issue
Block a user