LibAuth Comparison

This commit is contained in:
Jim Hamill
2025-02-03 11:40:38 +00:00
parent 14506d4ca6
commit f2b182c882
6 changed files with 1152 additions and 72 deletions
+4 -61
View File
@@ -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).