Please share your feedback here

[seetadev]

We look forward to hearing your feedback here.

[PutlaTheophila]

while the applications are under review i have few questions :

LLM provider preference — is ElizaOS expected to be provider-agnostic (Anthropic/OpenAI/local via Ollama), or do you have a preferred default for the DMP deliverable?
ERC-8004 — should we target a reference implementation or integrate an existing deployment? Are agent-identity attestations in scope for the mid-point milestone or only the final?
Decentralized storage SDK — preference between Storacha (w3up) and the legacy web3.storage client, given the recent split? Any constraint on UCAN-based auth flows?
Mobile scope — for the mid-point evaluation, is a PWA install sufficient, or do you expect a signed Capacitor Android build? iOS in final only?
Invoice settlement — should x402 + MPP be wired to a testnet (Base Sepolia?) for the demo, or is a mocked settlement layer acceptable until ERC-8004 lands?

[PutlaTheophila]

Hi @seetadev and @aspiringsecurity,

I have submitted a proposal for this issue to C4GT DMP 2026 and wanted to engage here on the technical direction. The scope is genuinely interesting because it stitches together three non-trivial layers — a config-driven ecosystem abstraction, an agentic co-pilot, and Web3 invoice rails — into one coherent surface for community hubs.

What resonated in the spec
Generalizing PLDG into a config-driven ecosystem layer so any hub (PLDG, OD Hack, OSS Gardens, etc.) can be onboarded via a schema/manifest rather than a fork. This is the part that unlocks long-term reuse.
Agentic co-pilot via ElizaOS + MCP for talent matching, contribution summarization, and invoice drafting — keeping the LLM behind a tool interface rather than free-form prompting.
Web3 invoice rails: x402 for payment-required HTTP semantics, MPP/Tempo for stablecoin settlement, and ERC-8004 for verifiable agent/identity attestations on invoices.
Filecoin/IPFS for invoice and artifact storage, plus PWA + Capacitor so the same codebase ships web, Android, and iOS without a native rewrite.

Clarifying questions
LLM provider preference — is ElizaOS expected to be provider-agnostic (Anthropic/OpenAI/local via Ollama), or do you have a preferred default for the DMP deliverable?
ERC-8004 — should we target a reference implementation or integrate an existing deployment? Are agent-identity attestations in scope for the mid-point milestone or only the final?
Decentralized storage SDK — preference between Storacha (w3up) and the legacy web3.storage client, given the recent split? Any constraint on UCAN-based auth flows?
Mobile scope — for the mid-point evaluation, is a PWA install sufficient, or do you expect a signed Capacitor Android build? iOS in final only?
Invoice settlement — should x402 + MPP be wired to a testnet (Base Sepolia?) for the demo, or is a mocked settlement layer acceptable until ERC-8004 lands?
Prototype status
I have started a working POC covering the config-driven ecosystem manifest, the dashboard shell, and an early AI co-pilot loop over MCP. Happy to share the repo link if it would help shape feedback during selection.

Looking forward to your guidance.

Best,
Putla Theophila

[zsklav]

Hi @seetadev — thanks for opening this up, and for the pointer in the GovtInvoice thread.

Following up from my comment in Discussion #89 there (DMP 2026 Agentic Invoice Co-Pilot, issue #37). I've been reading through py-ipfs-lite specifically because the "validated draft -> CID -> pinned record" step in that project is exactly where this library would slot in. One real question and one forward-looking observation:
Question on codecs: the IPLD codec choice has real implications for an "AI-drafted invoice → deterministically validated → finalized" pipeline. dag-cbor would let the canonical invoice be encoded as IPLD natively, preserving line-item types and decimal-precision tagging. dag-pb + UnixFS is the cleaner path for an opaque PDF/CSV artifact. Curious how you see the GovtInvoice integration leaning — toward one of those, or both (a structured CID for the canonical record plus a UnixFS CID for the human-readable artifact)?

Observation: the IPFSLitePeer.dag.put() boundary feels like a natural place to hang a finalization gate: validated drafts earn a CID, unvalidated ones never do. In my POC (https://github.com/zsklav/invoice-guard) the deterministic validation gate is already there; a sensible next step would be using py-ipfs-lite as the DAG-level primitive on the other side of that gate — so the integration seam looks well-defined.

Also really looking forward to the libp2p / IPFS meetup on Luma later this week!
Vanshikha

[zsklav]

Hi @seetadev — really excited about py-ipfs-lite as a lightweight Python IPFS implementation. While reading the codebase for my C4GT DMP 2026 proposal (GovtInvoice Issue #37), I had one design question on encoding strategy.

For invoice records that need to be both human-viewable (PDF / CSV exports) and machine-auditable (decimal-precision IPLD where line_items.sum() == total to the rupee), would the recommended pattern be dual-CID emission?

Specifically:

• A canonical record encoded as dag-cbor via ipfs_lite/dag/ — preserves decimal.Decimal typing through IPLD tags rather than serializing as floats-in-strings. This is what an auditor would re-validate against.
• A human artifact wrapped via ipfs_lite/unixfs/ as dag-pb for the PDF / CSV export.

Both pinned through block_service.BlockService; the canonical CID is what gets passed to the settlement layer; the artifact CID is what shows up in the UI.

This is the integration pattern I'm proposing in the agentic invoice co-pilot (POC: invoice-guard) so the audit trail survives the AI-to-IPFS handoff cleanly. Would love to hear if there's a better way you'd recommend, especially around how ipfs_lite/dag/ handles the Decimal → IPLD tag mapping (or if I should be using a different layer for that).

Thanks for the work on this library — looking forward to the libp2p / IPFS meetup as well.

— Vanshikha