Skip to content

[Hermes] Upstream change in sdn (carry-over: the six requirements upstream-sdn-1 did NOT deliver) #124

Description

@TJKoury

Graph task: upstream-sdn-2 · state: open · priority: 1 · components: [sdn]
Agent: Hermes
HERMES SPLIT, 2026-07-30. upstream-sdn-1 had SEVEN unrelated requirements merged
into it by successive escalations. I delivered exactly ONE of them (the record-catalog
replay rowid defect, landed a93b9200, live on host-01 2026-07-30T23:39Z). Closing
upstream-sdn-1 wholesale would have silently unblocked six dependents whose
requirements are untouched, so those six move here verbatim and their dependents were
re-blocked on this task.

Requirements carried over from upstream-sdn-1 (unchanged, none of them addressed):

  • [from ops-host02-disk] host-02 disk is structurally overcommitted: 48G disk vs kubo StorageMax 30G (23G already pinned, ipfs repo gc reclaims ~0) + 14G /var/lib/spacedatanetwork; ops cleanup recovered 3.5G free (was 0) but steady state sits in the WARN band. K3's second half — reconcile the ingest free-disk guard with the D3 disk-quota/eviction work (J2 appendix items 2/3) and/or a retention policy for pinned publication batches — is sdn-component work. Alternative is an owner disk resize.

  • [from saw-beta-correction] sdn-js/src/node.ts:445-452 subscribe() JSON.parses every pubsub payload and returns on failure; live PNMs on /spacedatanetwork/sds/PNM.fbs are binary size-prefixed FlatBuffers (verified live: $PNM identifier at offset 8), so the documented browser subscribe API silently drops 100% of real PNM announcements. publishRaw exists (node.ts:357) but there is no subscribeRaw counterpart. Connector-only fix: add subscribeRaw(schema, (bytes: Uint8Array, from: string) => void) mirroring publishRaw, no decode in the host lib. Ships in the sdn-js npm package; does NOT require a node binary deploy.

  • [from saw-beta-correction] OrbPro packages/sandcastle/gallery/_shared/celestrakSdnCatalog.js:31 pins CELESTRAK_IPFS_PROVIDER_BOOTSTRAP_ADDRS to a webtransport multiaddr with two certhashes, and fetchCIDBytesFromHelia is called with maxProviders:0 (no DHT fallback). Verified live 2026-07-28: delegated routing shows provider 12D3KooWGhZfrxQVvwQHNGRkeJhGqMbkDqjktfpBXzn47N78XY9j no longer advertises ANY webtransport addr; it advertises /ip4/167.172.219.213/tcp/4002 and /dns4/167-172-219-213.k51qzi5uqu5diqcia4ahdv9x3znxts7c3swrel32a0i1mk3qukdg25z4h6rypi.libp2p.direct/tcp/4002/tls/ws. I dialled the libp2p.direct wss addr successfully (kubo/0.39.0/sdn-celestrak, /ipfs/bitswap/1.2.0). webtransport certhashes rotate, so any pinned certhash in a shipped browser bundle is guaranteed to rot. Connector fix: prefer libp2p.direct /tls/ws bootstrap addrs and allow delegated-routing provider lookup. Same rot risk applies to sdn-js/src/edge-discovery.ts:34-37. Routes: cc orbpro-oracle for the gallery file.

  • [from orbpro-bootstrap-rot] SDN module-delivery to the full node 16Uiu2HAm1LbvwjEHW2GDP2ZQZvwHLZrz2jbYoRLQmJEQ3wZ5Fm45 fails from the browser under ?loadMode=sdn, so the gallery's SDN lane cannot be end-to-end live-verified. Two distinct live failures observed 2026-07-28 on digitalarsenal.github.io: (1) 'licensing grant provider signature verification failed' from decodeGrantResponse, and (2) 'failed to dial /space-data-network/module-delivery/1.0.0 ... Cannot open protocol stream on transient connection' — i.e. only a relayed/transient connection is available, which corroborates that the two webrtc-direct certhash edge relays in SDN_FULL_NODE_BOOTSTRAP_ADDRS have ALSO rotted (OrbPro removed them). Needs a CA-authenticated direct browser transport (AutoTLS /tls/ws or wss) advertised for the full node, plus limited-relay/transient handling for module-delivery streams. The catalog half is fixed and live-verified (OrbPro da75493a3d).

  • [from upstream-orbpro-flatsql-like-ignored] OrbPro Pages deploy is blocked: 'spacedatanetwork plugins publish-orbpro' cannot dial the module-delivery provider. All dials to 16Uiu2HAm1LbvwjEHW2GDP2ZQZvwHLZrz2jbYoRLQmJEQ3wZ5Fm45 fail with 'websocket: bad handshake' on /ip4/104.21.35.243/tcp/443/tls/sni/sdn.spaceaware.io/ws and /ip4/172.67.181.124/tcp/443/tls/sni/sdn.spaceaware.io/ws (both Cloud
    Mirrored from the dev graph (graph/tasks/upstream-sdn-2.md in DigitalArsenal/spacedatanetwork-stack); closes automatically when the graph task completes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions