LibAuth Comparison
This commit is contained in:
@@ -67,9 +67,9 @@ const txResult = await walletHD.send({
|
||||
|
||||
General structure:
|
||||
|
||||
- All blockchain adapters will implement `IBlockhain`
|
||||
- All storage adapters will implement `IStorage`
|
||||
- All wallets will implement `IWallet`
|
||||
- All blockchain adapters will implement `BaseBlockchain`
|
||||
- All storage adapters will implement `BaseStorage`
|
||||
- All wallets will implement `BaseWallet`
|
||||
- Likewise for any other "service" we need in XO Stack (e.g. BCMR?, Prices?).
|
||||
|
||||
Most (almost all?) service methods in our interfaces will be `async`. This is so that we can handle situations where things might be remote (or require OS approval of some sort). For example:
|
||||
@@ -93,7 +93,7 @@ Wallets can be **composed** of other Wallets. For example:
|
||||
- WalletHD **has many** WalletP2PKH
|
||||
- SomeCustomWallet **may have many** WalletHD (or other kinds of wallet).
|
||||
|
||||
The only requirement is that a Wallet **MUST** implement the IWallet interface.
|
||||
The only requirement is that a Wallet **MUST** implement the BaseWallet interface.
|
||||
|
||||
### Blockchain
|
||||
|
||||
@@ -156,63 +156,6 @@ Do we have to store a whole graph?
|
||||
|
||||
Do we just broadcast to one of our nodes and then broadcast to ALL of our nodes ~5s later to see if there's contention?
|
||||
|
||||
### Electrum 4.0.1 Notes
|
||||
|
||||
1. Maybe default constructor generic to `ElectrumClientEvents`:
|
||||
|
||||
```ts
|
||||
class ElectrumClient<ElectrumEvents extends ElectrumClientEvents = ElectrumClientEvents>
|
||||
```
|
||||
|
||||
2. `RequestResponse` might be typed incorrectly: It now takes `RPCParameter | RPCParameter[]` which are defined as follows: `string | number | boolean | null;` (note that it only accept parameters, not responses which are often/maybe-always JSON).
|
||||
|
||||
Previously, it would accept:
|
||||
|
||||
```
|
||||
export type RequestResponse =
|
||||
| object
|
||||
| string
|
||||
| number
|
||||
| boolean
|
||||
| null
|
||||
| RequestResponse[];
|
||||
```
|
||||
|
||||
Perhaps we could type it: `export type RequestResponse = RPCParameter & object | Array<RPCParameter & object>;` (replace `object` with something like `RPCResponse`, but I think that might be taken already?)
|
||||
|
||||
3. `RPCNotification` might be typed incorrectly (or maybe this is for future proofing?). The `params` property is marked as optional (but I think all notifications will have at least one). Might be more elegant to have it required and just return an empty array.
|
||||
|
||||
4. The current approach still requires polyfills because `@electrum/sockets` itself is imported by `@electrum/network` and `@electrum/sockets` exports `ElectrumTcpSocket`.
|
||||
|
||||
A workable approach might be:
|
||||
|
||||
1. Move socket interface back to `@electum/network`.
|
||||
2. Move the `ElectrumWebSocket` back to `@electrum/network`.
|
||||
3. Rename `@electrum/sockets` to `@electrum/tcp-socket` and only include the TCP Socket in there.
|
||||
4. This will still allow third-parties to define their own sockets (e.g. `@custom/electrum-libp2p-socket`).
|
||||
|
||||
5. This is what's required for polyfilling in Vite currently:
|
||||
|
||||
```sh
|
||||
npm install events
|
||||
npm install vite-plugin-node-polyfills
|
||||
```
|
||||
|
||||
```js
|
||||
[
|
||||
nodePolyfills,
|
||||
{
|
||||
include: ['events', 'net', 'tls'],
|
||||
// NOTE: Not disabling these causes an error on Vite Polyfills V0.22.
|
||||
globals: {
|
||||
Buffer: false,
|
||||
global: false,
|
||||
process: false,
|
||||
},
|
||||
},
|
||||
],
|
||||
```
|
||||
|
||||
## Markdown Extensions (TODO: Remove me later)
|
||||
|
||||
Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).
|
||||
|
||||
Reference in New Issue
Block a user