Attest Hubzilla Post prepare path is now working
View article
View summary
Webforms has reached an important next boundary in the IPFS and Attestation work: the Attest Hubzilla Post workflow can now prepare a real Hubzilla source record and submit it to orchestrator1. This is not just a rendered form anymore. The workflow now connects a participant-facing Webforms interface to a controlled backend prepare step, while keeping the source material anchored in Hubzilla.
The milestone matters because attestation should not begin as an arbitrary upload or pasted text field when the source record already exists inside Hubzilla. The user writes and publishes a post in their own channel. Then Webforms, running on the same Hubzilla node, uses the authenticated current channel to locate the latest eligible own post. That post is encoded through Hubzilla’s own Nomad/Zot6 payload path, and the local delivery report is collected as part of the prepared record.
The delivery report is useful, but it should be described carefully. It does not claim that a particular human read the post. It records Hubzilla delivery-system context: where the post was delivered or attempted through the channel’s network path. That helps preserve publication context alongside the author’s own account. The result is a more meaningful attestation package than a detached text copy would be.
The architecture boundary remains the main point of the work. Hubzilla/Webforms prepares the source-side record. orchestrator1 performs controlled workflow execution. ipfs1 performs the later IPFS and git/POSIX backend work. Webforms is not becoming the backend. It does not call raw Kubo RPC, hold git write tokens, mutate pinsets directly, store service credentials, or bypass the orchestrator.
The working model is still:
Service Pack → Webform → certified JSON → workflow panel → rendered interface
For this milestone, the Attest Hubzilla Post webform now has a Prepare Package action. The successful result from orchestrator1 was a prepared and stored operation. The package included the authenticated Hubzilla source, the encoded post payload, the collected delivery manifest, and the next planned operations.
Those next operations are not active yet. IPFS publish, pin, POSIX mapping, unpin, and read verification remain separate later stages. That separation is deliberate. The prepare step needed to work first, with the correct boundary: Hubzilla prepares what Hubzilla knows, and the orchestrator receives that prepared package for controlled publication work later.
The next development step is to build from this prepared/stored package toward the next controlled operation, without collapsing the boundary between Webforms, orchestrator1, and ipfs1.
