@lat-murmeldjur/weeb_3 0.0.295001

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2024 lat-murmeldjur
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/README.md ADDED
@@ -0,0 +1,205 @@
1
+ # Weeb-3 - A Swarm client for browsers
2
+
3
+ This project is a work in progress swarm client implementation relying solely on browser side technologies.
4
+ It uses [wasm-pack](https://rustwasm.github.io/docs/wasm-pack/) to build the project for use in the browser.
5
+
6
+ ## Building the code
7
+
8
+ Ensure you have [`wasm-pack`](https://rustwasm.github.io/wasm-pack/), [`protoc`](https://grpc.io/docs/protoc-installation/), and [`clang`](https://clang.llvm.org/) installed.
9
+
10
+ 1. Build the client library:
11
+ ```shell
12
+
13
+ RUSTFLAGS='--cfg getrandom_backend="wasm_js"' wasm-pack build --target web --out-dir static --out-name weeb_3
14
+ ```
15
+
16
+ 2. Start the local server to serve html, js and wasm files:
17
+ ```shell
18
+ cargo run
19
+ ```
20
+ Note this server uses an unsecure self-signed certificate to provide https, which is not sufficient to enable Service Workers in chrome etc. This enables displaying single files from swarm, however to display websites a service worker is necessary, which requires a certificate deemed safe by the browser. You can however get your own safe certificate from - for example - github pages by forking the repository and setting the github pages to 'docs', and copying your latest version of the files from the static folder to the docs folder.
21
+
22
+ 3. Open the URL (https://localhost:8080/weeb-3 or for the github pages hosted version https://lat-murmeldjur.github.io/weeb-3)
23
+
24
+ ## Using the npm package
25
+
26
+ The wasm-pack build now prepares the generated `static/package.json` for publishing to npm together with the assets required by the wrapper:
27
+
28
+ - `static/snippets/web3-0742d85b024bb6f5/inline0.js`
29
+ - `static/weeb_3.js`
30
+ - `static/weeb_3_bg.wasm`
31
+
32
+ After publishing, the package can be used with the same API shape as `static/example.html`:
33
+
34
+ ```js
35
+ import init, { SekireiNo103, BootstrapNode } from "@lat-murmeldjur/weeb_3";
36
+
37
+ await init();
38
+
39
+ const weeb3node = new SekireiNo103();
40
+ ```
41
+
42
+ The workflow defaults to publishing under the GitHub repository owner scope. If you need a different npm scope, set the `NPM_SCOPE` repository variable in GitHub Actions before pushing to `main`.
43
+
44
+ ## Automated publishing
45
+
46
+ The GitHub Actions workflow rebuilds the wasm package from `static`, rewrites the generated `static/package.json` into the publishable npm shape, checks the tarball with `npm pack --dry-run`, and publishes it on every push to `main`.
47
+
48
+ Published versions are rewritten to unique stable semver numbers derived from the Cargo version plus the GitHub Actions run number and retry attempt, so each `main` publish gets a new release version without hand-editing `package.json`.
49
+
50
+ To make the publish step fully automatic, configure npm trusted publishing for this repository and the `plain.yml` workflow.
51
+
52
+ If you prefer a token fallback instead, add a repository secret named `NPM_TOKEN`.
53
+
54
+ ## [Notes]
55
+
56
+ ### Compatibility - Supported Browsers
57
+
58
+ - Chrome (on Windows 11)
59
+ - Chrome (Android)
60
+ - Brave (on Windows 11)
61
+ - Edge
62
+ - Firefox (on Windows 11)
63
+ - Firefox (on Android)
64
+
65
+ Testing and modifying for other browsers is planned.
66
+
67
+ ### How it works (architectural overview)
68
+
69
+ The weeb-3 client consists of several logical components:
70
+ - The web interface (implemented by src/interface.rs & of course static/index.html) that creates with the main weeb process and loads the service worker
71
+ - The libp2p/swarm client (with main entry point in src/lib.rs)
72
+ - A service worker, that enables hot-loading assets on relative paths for websites loaded from swarm (found in static/service.js)
73
+
74
+ Below is a piece by piece overview of the current logic of components
75
+
76
+ #### The interface
77
+
78
+ As of "commit number 189" the instantiator of all components is the index.html that starts the interface (by calling the function "interweeb" from src/interface.rs).
79
+
80
+ The interweeb function has the following roles (in order of appearing in the code):
81
+ - Starting the libp2p/swarm client in an async block
82
+ - Setting a listener on the settings text input fields, triggering changing bootnode and connection settings to the weeb process on a button based event
83
+ - Setting a listener on the navigation text input field, triggering requests to the shared worker on content change of the navigation text input field
84
+ - Setting a listener on the create storage input fields, triggering connecting metamask and buying a batch with provided parameters
85
+ - Setting a listener on the reuse space button, triggering resetting an already existing batch to clean slate
86
+ - Setting a listener on the upload input fields, triggering uploading with the existing batch if there is one
87
+ - Listening to logs sent back by the weeb process, as well as resources and responses of triggered requests and displaying them
88
+ - Starting connection to bootnode after 600 milliseconds
89
+
90
+ #### The weeb process
91
+
92
+ Originally implemented in a shared web worker, the main weeb process was intended to function as a common resource for multiple tabs of the same origin.
93
+ This design would have enabled having one swarm client serving multiple open tabs, however, at the cost of giving up on the possibility of being able to open webrtc connections. However, chrome on android does not support shared workers, so for the time being, the main weeb process was transfered back into the tab.
94
+
95
+ The high level architecture of the client resides in src/lib.rs, which (in order of appearing in the code) implements the following functions:
96
+
97
+ - Defining and importing the swarm protocols generated by the protoc compiler
98
+ - Defining the client (as the class Sekirei), it's in-memory registry of peers and their accounting (as the struct Wings)
99
+ - Defining the 6 main functions of the client, namely
100
+ 1) Changing the bootnode address and network id
101
+ 2) Uploading a file or a tar based collection, optionally to a feed as well
102
+ 3) A function that enables using the running client to retreive resources (the function "acquire")
103
+ 4) A function to reset a postage stamp to original state
104
+ 5) Instantiation (the "new" function), that starts the libp2p client
105
+ 6) A function that continues running the client, asynchronously maintains/establishes connections, serves requests from the interface, and engages in protocols with the swarm (the "run" function)
106
+ 7) Helper functions for the interface to get new log lines, connection numbers, and to submit new logs meant to be shown on the interface
107
+
108
+ In slightly more detail, the new function does the following (in order of appearing in the code):
109
+ - Randomises a new secret keypair
110
+ - Starts a libp2p client with the stream libp2p behaviour enabled using webrtc transport
111
+ - Creates a registry of peers (connected_peers, overlay_peers) and peer accounting (accounting_peers, ongoing_refreshments)
112
+ - Creates a message port (to be listened to by the client and to be used by the acquire function)
113
+ This message port can receive the writing end of a channel of bytes along with an address, so that it can write back the results of looking up the address to the channel received.
114
+
115
+ The run function of the client implements an asynchronous architecture that does the following functions (in order of appearance in the code):
116
+ - Creating channels for swarm specific functions
117
+ 1) Receiving new peers to connect from the gossip protocol (peers_instructions_chan, connections_instructions_chan)
118
+ 2) Accounting related functions (accounting_peer_chan, pricing_chan, refreshment_instructions_chan, refreshment_chan)
119
+ 3) Receiving new bootnode address to connect to
120
+ - Setting up listening to gossip protocol messages (information about existing peers) and pricing protocol messages (for receiving connected peers payment threshold updates)
121
+ - An async routine to continously establish new libp2p-connections (dial) and consume libp2p-swarm events (swarm_event_handle) as well as dialing to bootnode
122
+ - An async routine that wraps a number of further async routines for the following functions (event_handle):
123
+ 1) Accounting connecting newly established peer connections (k1)
124
+ 2) Setting payment thresholds for peers after successfully receiving payment threshold updates in the pricing protocol (k2)
125
+ 3) Initiating refreshments/pseudosettle protocol for peers when triggered by accounting actions (k3)
126
+ 4) Registering the results of successful refreshments towards peers (k4)
127
+ - Two async routines that listens to high level download / upload requests
128
+ - Two async routines that listens to data object level download / upload requests enabling joining and splitting of chunks
129
+ - Two async routines that enable concurrent chunk level pushsync and retrieval requests
130
+ - An async routine that attempts to conduct handshakes with dialed connections
131
+
132
+ Currently - due to the blocking - non-blocking nature of the async framework, and to avoid a waiting thread hogging the single execution thread, the aforementioned routines intermittently try progressing every 600ms with non cpu intensive async sleeps happening in-between.
133
+
134
+ #### The Swarm Client Subcomponents
135
+
136
+ The aforementioned architecture further depends on the following code modules:
137
+ - The protocol handlers for handshake, hive, pricing, pseudosettle and retrieval (src/handlers.rs)
138
+ - The accounting functions, such as calculating chunk prices, reserving, crediting, refreshing (src/accounting.rs)
139
+ - The retrieval logic such as selecting peers to retrieve chunks from, decrypting chunks, joining files and triggering manifest interpretations (src/retrieval.rs)
140
+ - The pushsync logic such as selecting peers to push chunks to, encrypting chunks, splitting files, triggering manifest and soc creation (src/upload.rs)
141
+ - The manifest creation logic (src/manifest_upload.rs)
142
+ - The manifest interpretation logic (src/manifest.rs)
143
+ - The ENS contenthash resolution logic (src/ens.rs)
144
+ - The indexeddb in-browser storage solution (src/persistence.rs)
145
+ - Common methods and struct declarations including DOM manipulation, calculating proximity orders, validating content addressed and single owner chunks, calculating feed addresses, and encoding/decoding resource groups to communicate through byte channels e.g. towards the interface (src/conventions.rs)
146
+
147
+ #### Persistence and identity
148
+
149
+ The weeb process persists 3 types of data:
150
+ - Caching chunks retrieved previously
151
+ - Identity related keys and identifiers used for uploads and creating feeds
152
+ 1) Batch ID
153
+ 2) Private key of Batch Owner
154
+ 3) Batch Bucket Limit
155
+ 4) Private key of Feed Owner
156
+ - Saturation of individual Batch Buckets
157
+
158
+ The indexeddb access is denied to loaded websites by opening websites from swarm in iframes marked with the sandbox attribute.
159
+ The private keys are not used for blockchain purposes, the wallet responsible for buying a batch can only be connected through metamask currently.
160
+ The libp2p node keys are chosen randomly each time the tab is reloaded, resulting in a unique overlay every time
161
+
162
+ ### The Service Worker
163
+
164
+ Quoting from the [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API), "Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests, and take appropriate action based on whether the network is available, and update assets residing on the server. They will also allow access to push notifications and background sync APIs.".
165
+
166
+ The weeb-3 interface functions can display single files, for example pictures, documents, and other single files without relying on the service worker through dynamically creating blobs with associated mime types from the data retrieved from swarm, and making them available on [virtual urls](https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static). These resources are displayed in embed tags prepended to the content of the resultField html tag.
167
+
168
+ However, this createObjectUrl method inserts random strings into the virtual urls assigned to individual resources, which makes it unfeasible to be used to render complete websites, as relative paths of assets embedded in the site would be broken by such random strings. This necessitates the use of a service worker, which can intercept the http requests aimed towards the de facto server (for example github pages) and is able to create objects with deterministic url paths to be served in response to these requests, making serving relative assets possible.
169
+
170
+ To enable this, upon detecting a website manifest, the interface sends each retrieved resource complete with relative path and mime type to the service worker (the message event listener in static/service.js), which injects it into a named cache ('default0'), before prepending the website index document as an iframe to the resultField html tag of the weeb-3 browser tab.
171
+
172
+ This service worker is only enabled by the browser if the browser detects that the site is served through a secure https connection based on a trusted certificate, as this functionality is clearly a security sensitive asset that can be used to intercept http requests and inject arbitrary resources. The use of this functionality also creates new surfaces of attack such as creating malicious websites that could load a malevolent service worker at runtime, to enable further malicious injections. Disableing such attacks is part of the security development topic of the planned developments section.
173
+
174
+ ### Main dependencies
175
+
176
+ The weeb-3 project uses the following main rust crates:
177
+ - libp2p
178
+ - alloy
179
+ - ethers
180
+ - web3-rs
181
+ - async-std
182
+ - wasm-bindgen
183
+ - js-sys
184
+ - web-sys
185
+ - indexed_db_futures
186
+
187
+ ### Concurrency and memory limitations
188
+
189
+ The architecture of the weeb process enables a high level of concurrency between different tasks, sending a high number of different types of protocol messages parallelly. The webassembly architecture currently does not support threads or utilizing multiple CPUs, and the 32bit memory addressing scheme limits the usable memory to 4 GBs. Offloading the work to multiple non-specialized web-workers would increase this limit in both dimensions as each web worker has a separate memory address space and a separate physical thread.
190
+
191
+ ## [Planned development]
192
+
193
+ - Adding functionality to the service worker to enable triggering requests towards the shared worker, to retrieve resources when swarm references are present in a website, alternatively, achieving the same by overwriting navigation bar contents when an onclick event is detected to be a swarm reference
194
+ - Simultaneous manifest fork lookups
195
+ - Multi-threading through web-workers
196
+ - Adding the swarm ACT feature
197
+ - Wallet related functionality such as using cheques
198
+ - Penetration testing against service worker replacement and other injection types of attacks
199
+ - Penetration testing loaded websites access to keys in indexeddb / loading single executable files
200
+ - Refinements in error propagation, reliability, robustness, status updates in ongoing processes
201
+
202
+
203
+
204
+
205
+
package/package.json ADDED
@@ -0,0 +1,46 @@
1
+ {
2
+ "name": "@lat-murmeldjur/weeb_3",
3
+ "type": "module",
4
+ "description": "A Swarm client for browsers",
5
+ "version": "0.0.295001",
6
+ "license": "MIT",
7
+ "repository": {
8
+ "type": "git",
9
+ "url": "git+https://github.com/lat-murmeldjur/weeb-3.git"
10
+ },
11
+ "main": "./weeb_3.js",
12
+ "homepage": "https://github.com/lat-murmeldjur/weeb-3#readme",
13
+ "types": "./weeb_3.d.ts",
14
+ "module": "./weeb_3.js",
15
+ "bugs": {
16
+ "url": "https://github.com/lat-murmeldjur/weeb-3/issues"
17
+ },
18
+ "publishConfig": {
19
+ "access": "public",
20
+ "registry": "https://registry.npmjs.org/"
21
+ },
22
+ "files": [
23
+ "snippets/web3-0742d85b024bb6f5/inline0.js",
24
+ "weeb_3.d.ts",
25
+ "weeb_3.js",
26
+ "weeb_3_bg.wasm",
27
+ "weeb_3_bg.wasm.d.ts"
28
+ ],
29
+ "sideEffects": [
30
+ "./snippets/*"
31
+ ],
32
+ "keywords": [
33
+ "bee",
34
+ "browser",
35
+ "swarm",
36
+ "wasm",
37
+ "webassembly"
38
+ ],
39
+ "exports": {
40
+ ".": {
41
+ "types": "./weeb_3.d.ts",
42
+ "import": "./weeb_3.js",
43
+ "default": "./weeb_3.js"
44
+ }
45
+ }
46
+ }
@@ -0,0 +1 @@
1
+ export function get_provider_js() {return window.ethereum}
package/weeb_3.d.ts ADDED
@@ -0,0 +1,131 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+
4
+ export class BootstrapNode {
5
+ free(): void;
6
+ [Symbol.dispose](): void;
7
+ constructor(multiaddr: string, usable: boolean);
8
+ readonly multiaddr: string;
9
+ readonly usable: boolean;
10
+ }
11
+
12
+ export class RequestArguments {
13
+ private constructor();
14
+ free(): void;
15
+ [Symbol.dispose](): void;
16
+ readonly method: string;
17
+ readonly params: Array<any>;
18
+ }
19
+
20
+ export class Sekirei {
21
+ private constructor();
22
+ free(): void;
23
+ [Symbol.dispose](): void;
24
+ acquire(address: string): Promise<Uint8Array>;
25
+ change_bootnode_address(address: string, _id: string, usable_in_protocols: boolean): Promise<Uint8Array>;
26
+ get_connections(): Promise<bigint>;
27
+ get_current_logs(): Promise<string[]>;
28
+ get_ongoing_connections(): Promise<bigint>;
29
+ interface_log(log0: string): void;
30
+ static new(_st: string): Sekirei;
31
+ post_push_chunk(d: Uint8Array, soc: boolean, chunk_address: Uint8Array, stamp: Uint8Array): Promise<Uint8Array>;
32
+ post_upload(file: File, encryption: boolean, index_string: string, add_to_feed: boolean, feed_topic: string): Promise<Uint8Array>;
33
+ reset_stamp(): Promise<Uint8Array>;
34
+ run(_st: string): Promise<void>;
35
+ }
36
+
37
+ export class SekireiNo103 {
38
+ free(): void;
39
+ [Symbol.dispose](): void;
40
+ constructor();
41
+ postPushChunk(data: Uint8Array, soc: boolean, chunk_address: Uint8Array, stamp: Uint8Array): Promise<string>;
42
+ resetStamp(): Promise<object>;
43
+ retrieve(address: string): Promise<Array<any>>;
44
+ start(bootstrap_nodes: BootstrapNode[], network_id: string): void;
45
+ upload(file: File, encryption: boolean, index_string: string, add_to_feed: boolean, feed_topic: string): Promise<object>;
46
+ }
47
+
48
+ export class Wings {
49
+ private constructor();
50
+ free(): void;
51
+ [Symbol.dispose](): void;
52
+ }
53
+
54
+ export function interweeb(_st: string): Promise<void>;
55
+
56
+ export type InitInput = RequestInfo | URL | Response | BufferSource | WebAssembly.Module;
57
+
58
+ export interface InitOutput {
59
+ readonly memory: WebAssembly.Memory;
60
+ readonly __wbg_bootstrapnode_free: (a: number, b: number) => void;
61
+ readonly __wbg_sekireino103_free: (a: number, b: number) => void;
62
+ readonly bootstrapnode_multiaddr: (a: number) => [number, number];
63
+ readonly bootstrapnode_new: (a: number, b: number, c: number) => number;
64
+ readonly bootstrapnode_usable: (a: number) => number;
65
+ readonly sekireino103_new: () => number;
66
+ readonly sekireino103_postPushChunk: (a: number, b: number, c: number, d: number, e: number, f: number, g: number, h: number) => any;
67
+ readonly sekireino103_resetStamp: (a: number) => any;
68
+ readonly sekireino103_retrieve: (a: number, b: number, c: number) => any;
69
+ readonly sekireino103_start: (a: number, b: number, c: number, d: number, e: number) => void;
70
+ readonly sekireino103_upload: (a: number, b: any, c: number, d: number, e: number, f: number, g: number, h: number) => any;
71
+ readonly interweeb: (a: number, b: number) => any;
72
+ readonly __wbg_sekirei_free: (a: number, b: number) => void;
73
+ readonly __wbg_wings_free: (a: number, b: number) => void;
74
+ readonly sekirei_acquire: (a: number, b: number, c: number) => any;
75
+ readonly sekirei_change_bootnode_address: (a: number, b: number, c: number, d: number, e: number, f: number) => any;
76
+ readonly sekirei_get_connections: (a: number) => any;
77
+ readonly sekirei_get_current_logs: (a: number) => any;
78
+ readonly sekirei_get_ongoing_connections: (a: number) => any;
79
+ readonly sekirei_interface_log: (a: number, b: number, c: number) => void;
80
+ readonly sekirei_new: (a: number, b: number) => number;
81
+ readonly sekirei_post_push_chunk: (a: number, b: number, c: number, d: number, e: number, f: number, g: number, h: number) => any;
82
+ readonly sekirei_post_upload: (a: number, b: any, c: number, d: number, e: number, f: number, g: number, h: number) => any;
83
+ readonly sekirei_reset_stamp: (a: number) => any;
84
+ readonly sekirei_run: (a: number, b: number, c: number) => any;
85
+ readonly __wbg_requestarguments_free: (a: number, b: number) => void;
86
+ readonly requestarguments_method: (a: number) => [number, number];
87
+ readonly requestarguments_params: (a: number) => any;
88
+ readonly wasm_bindgen__convert__closures_____invoke__h06a7e7b2a563bd9a: (a: number, b: number, c: any) => [number, number];
89
+ readonly wasm_bindgen__convert__closures_____invoke__h2b3586c1e5138808: (a: number, b: number, c: any) => [number, number];
90
+ readonly wasm_bindgen__convert__closures_____invoke__h88996e8058e7b4cf: (a: number, b: number, c: any, d: any) => void;
91
+ readonly wasm_bindgen__convert__closures_____invoke__h2c2b25660306fe52: (a: number, b: number, c: any) => void;
92
+ readonly wasm_bindgen__convert__closures_____invoke__h592ace81aa415f10: (a: number, b: number, c: any) => void;
93
+ readonly wasm_bindgen__convert__closures_____invoke__h592ace81aa415f10_3: (a: number, b: number, c: any) => void;
94
+ readonly wasm_bindgen__convert__closures_____invoke__hb7695be2fdd72d20: (a: number, b: number, c: any) => void;
95
+ readonly wasm_bindgen__convert__closures_____invoke__h592ace81aa415f10_6: (a: number, b: number, c: any) => void;
96
+ readonly wasm_bindgen__convert__closures_____invoke__hb28937c0609bdd79: (a: number, b: number) => void;
97
+ readonly wasm_bindgen__convert__closures_____invoke__h294687bdb60910fc: (a: number, b: number) => void;
98
+ readonly wasm_bindgen__convert__closures_____invoke__h41947166d8d508a5: (a: number, b: number) => void;
99
+ readonly __wbindgen_malloc: (a: number, b: number) => number;
100
+ readonly __wbindgen_realloc: (a: number, b: number, c: number, d: number) => number;
101
+ readonly __wbindgen_exn_store: (a: number) => void;
102
+ readonly __externref_table_alloc: () => number;
103
+ readonly __wbindgen_externrefs: WebAssembly.Table;
104
+ readonly __wbindgen_destroy_closure: (a: number, b: number) => void;
105
+ readonly __externref_drop_slice: (a: number, b: number) => void;
106
+ readonly __wbindgen_free: (a: number, b: number, c: number) => void;
107
+ readonly __externref_table_dealloc: (a: number) => void;
108
+ readonly __wbindgen_start: () => void;
109
+ }
110
+
111
+ export type SyncInitInput = BufferSource | WebAssembly.Module;
112
+
113
+ /**
114
+ * Instantiates the given `module`, which can either be bytes or
115
+ * a precompiled `WebAssembly.Module`.
116
+ *
117
+ * @param {{ module: SyncInitInput }} module - Passing `SyncInitInput` directly is deprecated.
118
+ *
119
+ * @returns {InitOutput}
120
+ */
121
+ export function initSync(module: { module: SyncInitInput } | SyncInitInput): InitOutput;
122
+
123
+ /**
124
+ * If `module_or_path` is {RequestInfo} or {URL}, makes a request and
125
+ * for everything else, calls `WebAssembly.instantiate` directly.
126
+ *
127
+ * @param {{ module_or_path: InitInput | Promise<InitInput> }} module_or_path - Passing `InitInput` directly is deprecated.
128
+ *
129
+ * @returns {Promise<InitOutput>}
130
+ */
131
+ export default function __wbg_init (module_or_path?: { module_or_path: InitInput | Promise<InitInput> } | InitInput | Promise<InitInput>): Promise<InitOutput>;