@happyvertical/smrt-gnode
Federation scaffolding for gnode knowledge bases: published types and class shells, with none of the discovery or exchange behavior implemented yet.
What it gives you
Federation scaffolding for gnode knowledge bases: published types and class shells, with none of the discovery or exchange behavior implemented yet.
- 01Ships today: the GnodePeer, FederationConfig, and WebFingerResponse types
- 02Ships today: Federation, WebFingerProtocol, and PeerExchangeProtocol class shells whose methods return an empty array or null
- 03Planned: WebFinger discovery at /.well-known/gnode, peer exchange at /api/federation/peers, and ActivityPub-inspired cross-gnode queries
What you can rely on now
The exported type definitions are stable enough for design work. A peer has a url, name, discoveredAt, and optional lastSeen. Federation configuration covers enabled, discoverability, peers, autodiscovery, and peerExchange. Nothing behind these types does network work.
What is still to be built
Peer discovery over WebFinger, the peer-exchange endpoint, and cross-gnode querying are all unimplemented. Until they land, an application that needs federation has to implement the transport itself rather than importing it from here.
Check upstream before you plan around it
The source is the current truth. The README has the same stubs-only warning, but some parts are behind the code. It reports no dependencies, although the package declares smrt-core and several SDK adapters. Read the source before you assume that planned behavior is available.
Open the package source →