knowledgr/knowledgr-js

1. What this repo is

- steem-js is a client-side and server-side JavaScript SDK for the Steem blockchain.

- It is not a backend service; it is a library that wraps Steem RPC nodes and exposes higher-level API, auth, and transaction-broadcast functions.

2. Top-level public surface

- The main entrypoints are src/index.js for Node/CommonJS and src/browser.js for browser builds.

- These aggregate the main namespaces exposed to consumers: api, auth, broadcast, formatter, and config.

3. RPC/API subsystem

- src/api/ is the read/query layer for blockchain data.

- methods.js defines the RPC methods, while transports/ contains the concrete network adapters.

- transports/http.js and transports/ws.js are the two transport boundaries; both sit behind transports/base.js and are selected through transports/index.js.

4. Network/data flow to Steem nodes

- Application code calls steem.api.* methods.

- Those methods are serialized into RPC requests and sent through HTTP or WebSocket transport.

- The library talks to external Steem RPC endpoints such as api.steemit.com, node.steem.ws, and this.piston.rocks.

5. Auth and cryptography subsystem

- src/auth/ is the signing and key-management layer.

- src/auth/ecc/ is a self-contained crypto package for key generation, signing, hashing, AES, signatures, and address handling.

- src/auth/memo.js handles memo encryption/decryption, which is a distinct auth concern from transaction signing.

6. Serialization subsystem

- src/auth/serializer/ is another major boundary: it converts Steem operations and types into the chain’s canonical serialized form.

- It includes type definitions, operation templates, object-id parsing, precision/number helpers, and validation.

- This layer is used by broadcasting and by any code that needs chain-compatible binary/structured payloads.

7. Broadcast subsystem

- src/broadcast/ builds and submits signed blockchain operations.

- operations.js and param_types.js define the supported transaction operations and how their arguments are shaped.

- helpers.js and the top-level broadcast API coordinate signing plus submission through the API layer.

8. End-to-end transaction flow

- For writes, the flow is: consumer code → broadcast → auth/serializer → signed transaction → api transport → Steem RPC node.

- For reads, the flow is simpler: consumer code → api → transport → Steem RPC node → response back to the caller.

9. Formatting and utility layer

- src/formatter.js and src/utils.js provide presentation and convenience helpers, such as reputation formatting and general-purpose transforms.

- These are not network-facing; they sit above the raw API/auth layers and normalize blockchain data for app use.

10. Environment/build boundaries

- The repo supports both Node and browser usage.

- webpack.config.js and webpack/ build browser bundles; examples/webpack-example/ shows consumption from a bundled frontend.

- browser.js is the browser-specific entry, which is an important architectural split from the Node entry.

11. Examples as integration references

- examples/ contains concrete usage paths for key auth, posting, multisig, vote broadcast, streaming, and HTML/browser demos.

- These examples show the library’s intended integration points rather than additional subsystems.

12. Tests reflect the main seams

- test/ covers crypto, key formats, memo handling, serializer/types, broadcast, API behavior, and browser usage.

- The test layout mirrors the architecture: network/API, auth/crypto, serialization, and end-to-end broadcast are all separate seams.

13. Overall architecture to diagram

- A useful diagram would show a central SDK façade feeding three core internal domains: API/RPC, Auth/Crypto+Serializer, and Broadcast.

- Around that core are environment-specific entrypoints for Node and browser, plus external Steem RPC nodes as the only runtime dependency.