Add publisher-signed Protomux channel so external publishers can submit custody entries without HTTPS

[iainkek]

Context — Pear manifesto §5

The Pear ecosystem manifesto commits applications to no required infrastructure:

Every application must work peer-to-peer with zero HiveRelay nodes online. Infrastructure improves the experience; it does not enable it.

For drop-pear, an end-to-end-encrypted share-drops app, three of four operating modes already satisfy this:

• Public drops ✅ — pure Hyperswarm + URL-fragment key, no HTTPS dependency.
• Private drops ✅ — Hyperswarm + blind-pairing handshake, no HTTPS dependency.
• Burn-receipts ✅ — signed tombstones gossiped over Hyperswarm.

The fourth mode, escrow drops (Shamir-split key distributed across N custodian relays for atomic single-recipient handoff with a quorum-receipt commit), is currently HTTPS-only. Every step of the custody pipeline — intent → seed → receipts → commit → source-retired — goes through /api/v1/custody/* REST endpoints. As long as that's the only path, drop-pear's escrow mode violates §5.

We've shipped what we can on our side (v3.0.10 added adaptive resilience against partially-broken relays), but the structural problem stands: when zero HiveRelay nodes are reachable over HTTPS, escrow drops cannot be created. That's the wrong shape for an app that's otherwise fully peer-to-peer.

Today: the Protomux custody channel is relay-to-relay only

p2p-hiverelay already has a Protomux channel for custody at packages/core/core/protocol/custody-channel.js.

It's used between relays to gossip-propagate custody entries that one relay has already accepted via REST. Each relay PUSHes every new entry it appends to its connected peer relays. That works — it's why our collectReceipts aggregator can see receipts from any relay regardless of which one anchored.

But there's no message type on that channel for external publishers to submit an entry. Publishers can read (status polls) and listen (gossip), but to publish they have to go through HTTPS.

Proposal — extend with a SUBMIT message type

Two equivalent shapes; either works. I'd defer to whatever fits the existing protocol style.

Option A — extend hiverelay-custody with new message types:

hiverelay-custody messages:
  PUSH_ENTRY       — existing relay→relay broadcast (unchanged)
  SUBMIT_ENTRY     — NEW: publisher → relay, signed entry to append
  SUBMIT_RESULT    — NEW: relay → publisher, accept / reject

Option B — new hiverelay-publish channel:

hiverelay-publish messages:
  SUBMIT_ENTRY     — publisher → relay, signed entry
  SUBMIT_RESULT    — relay → publisher, accept / reject

The submit payload would be the same publisher-signed body that /api/v1/custody/intent and /api/v1/seed accept today — same Ed25519 signature scheme, same canonical layouts (serializeSeedRequestForSigning for seeds, the existing intent-body hash for intents/commits/retired). Relays already know how to verify these; the only new code is the channel wiring + a routing entry into seedingRegistry.publishCustodyIntent / equivalents.

Client API

HiveRelayClient would expose Protomux-flavoured mirrors of the existing REST helpers:

// Existing (HTTPS, post-v0.8.6):
//   client.publishIntent(intent)
//   client.seedForCustody(args)
//   client.publishCommit(args)
//   client.publishSourceRetired(args)

// New (Hyperswarm, post-publisher-Protomux):
await client.protomux.publishIntent(intent)
await client.protomux.seedForCustody(args)
// etc.

Drop's adapter (app/lib/escrow/relay-adapter.js) would gain a parallel makeHiveRelayProtomuxAdapter factory and the worker would prefer it when available, falling back to REST.

Benefits

• Restores manifesto §5 compliance for escrow-style apps. Drop's escrow mode could ship purely over Hyperswarm. Other custody-pattern apps inherit the same property.
• No new auth surface. Reuses the same publisher-signature scheme — the relay already trusts an Ed25519 signature over the canonical payload, regardless of transport. No operator API key, no new identity model.
• Coexists with HTTPS. Doesn't break existing REST clients; both paths can land entries in the same seedingRegistry. Operators choose what to expose; publishers choose what to use.
• NAT-friendly. Hyperswarm handles hole-punching that mobile / restricted networks struggle with on raw HTTPS to a non-CDN domain.
• Sidesteps the "corestore is closed" 400 path. Whether or not the eagerReplicate session leak (filed separately as #12) gets fixed, the Protomux path provides an alternate pipe into the registry that doesn't go through the HTTP layer at all.

Stays compatible with everything you've already shipped

• v0.8.6's publisher-signed REST endpoints stay. They're what drop-pear uses today and will continue to use as a fallback.
• Existing relay-to-relay gossip on hiverelay-custody stays unchanged.
• Existing operator REST (/api/custody/* + Bearer) stays unchanged for self-hosted publishers who prefer that auth model.
• No protocol-version bump needed if the channel-extension shape is used (new message types on an existing channel are forward-compatible per Protomux semantics); if a new hiverelay-publish channel is preferred, that's an additive change too.

Concrete consumer

drop-pear v3.0.10+ would adopt this immediately. Our worker already auto-discovers reachable HiveRelay nodes (configured + localhost-sweep + federation-query of /api/network); we'd add a Hyperswarm-side discovery step (DHT lookup of a well-known topic, mirroring how we find publishers) and the adapter would prefer Protomux when both are advertised.

I'm assuming this is non-trivial and you've got other priorities — happy to draft a patch if it would speed things up. If there's a preferred shape for the SUBMIT_RESULT envelope (status codes, error categories, etc.), even a stub of that would let us prototype against it. And if there's pushback on the proposal (e.g., the channel's intended to stay relay-only by design), I'd rather know now so we can plan around it.

Thanks again for v0.8.6 — none of this would even be a coherent ask without the publisher-signed REST work.