IPFS Configuration
Connection config keys, credentials, and how the node registers itself
Per-Operation Config, Not appsettings.json
Unlike networks-based nodes, the IPFS node takes its daemon endpoints as per-operation config fields rather than an application-wide settings section. Every operation carries its own connection details, so different workflow steps can target different Kubo daemons or Cluster daemons.
Kubo Connection Fields
Every operation (all 61) carries these three fields, inherited from a common base:
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
baseUrl | text | ✓ Yes | — | Kubo RPC API endpoint, e.g. http://127.0.0.1:5001. Missing/blank → CFG_MISSING_BASE_URL. |
authMode | select | No | none | none | bearer | basic. Kubo has no native auth — this covers a reverse-proxy-protected daemon. |
credentialID | vault reference | No | — | Resolved via the platform's auto-wired flat credentialID key (the "primary" alias) when authMode is bearer or basic. |
Cluster Connection Fields
Operations under cluster, plus the storage composites, additionally carry a
second connection to a separate IPFS Cluster daemon:
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
clusterBaseUrl | text | ✓ Yes (Cluster ops) | — | IPFS Cluster REST endpoint, e.g. http://127.0.0.1:9094. Missing/blank → CFG_MISSING_CLUSTER_BASE_URL. |
clusterAuthMode | select | No | none | none | basic. |
destinationCredentialID | vault reference | Conditional | — | Resolved via the platform's "destination" alias (dual-endpoint pattern). Required when clusterAuthMode is basic — otherwise CFG_MISSING_CREDENTIAL. |
BizFirst.Integration.IPFS.Services.
Registration
IPFSDependency.RegisterDefaults(services) registers everything the node needs:
- All IPFS services (one per resource, plus shared HTTP/connection/streaming infrastructure)
- The executor itself, scoped
- The
ExecutorRegistryentry foripfs
ProjectReference
alone is not sufficient — the assembly-scanning loader may not see an assembly that is never
force-loaded. Add
new BizFirst.Ai.ExecutionNodes.Blockchain.IPFS.IPFSDependency().RegisterDefaults(services);
to Plugins_RegisterAllNodes(...) in ServiceCollectionExtensionsForAI.cs
(same requirement as the Ethereum and Hedera nodes). Without this line the node type won't appear in the
workflow designer even though the package is referenced.
Project Layout
The node ships as three .NET 9 projects:
| Project | Responsibility |
|---|---|
BizFirst.Integration.IPFS.Domain | Result records for all 61 operations. No references, no packages. |
BizFirst.Integration.IPFS.Services | HTTP/protocol layer: 12 typed HttpClient resource services, connection contexts, SSRF policy, resilience (retry/backoff) handler, NDJSON stream reader. |
BizFirst.Ai.ExecutionNodes.Blockchain.IPFS | The executor: operation routing, settings, operation-info factory, per-operation feature partials. |
IPFSOperationInfoFactory.Create(resource,
operation, reader) resolves the active per-operation config DTO from the (resource,
operation) pair. The executor's settings root exposes only Resource/Operation/ActiveInfo
— every operation-specific field lives on its own sealed DTO class.
Known Deferrals
GetNodeEntitiesAsync() (ProcessStudio form-entity declarations) is not implemented,
matching the reference Ethereum node. Unit tests, DB Forms/FormControls, and live-daemon verification are
tracked as follow-up work — see Roadmap.