Documentation Index
Fetch the complete documentation index at: https://docs.bitfield.so/llms.txt
Use this file to discover all available pages before exploring further.
Build
Build your own surface.
A good SDK gives app code a tiny surface and keeps Bitfield setup work behind the plug.
The JavaScript Runtime Kit is the example. App code gets one read hook and one request function. Bitfield still handles boot, connection, package loading, storage readers, subscriptions, and validation behind that surface.The rule
Expose the thing the app actually wants to do. Do not expose the setup steps Bitfield had to take to make that possible.Expose reads.
Give app code a stable way to receive data, loading, and error.
Expose requests.
Give app code a stable way to send a target plus payload.
Hide setup work.
Keep boot, package binding, storage addressing, byte subscriptions, and transport setup outside the app surface.
A public surface can be small
The setup surface can be large
The setup surface can do real work. It may connect to Bitfield, load packages, prepare read scopes, subscribe to updates, decode payloads, validate package boundaries, or recover from resets.That does not mean the app surface should expose those details. App developers should not have to learn the setup work just to render data.The boundary test
Ask this before adding a public SDK function:Would an app developer call this because their product needs it, or because Bitfield setup needed a place to live?
If it is setup work, keep it behind the plug.