Problem

If the GAMB contract is deployed on mainnet, then it could at times be prohibitively expensive to maintain a publishing cadence.

For example, at 21 Gwei/gas a publish transaction
costs $1. If gas price is 100 Gwei/gas, this would be $5.

This could reduce participation, and at a minimum reduce the frequency that a publisher chooses to broadcast.

Solution

One-time "I'm a publisher for this topic" transactions.

Publisher

A publisher could use IPNS as the pointer for their published manifests.

This would entail a one-time Ethereum mainnet transaction to the Broadcaster contract containing two elements:

• IPNS ID (e.g., k52...abc)
• Topic ID (e.g., my-special-database)

Then generate the manifest (which contains immutable CIDs for the database) and compute its manifest_CID.

Then publish the manifest CID (ipfs name publish mainfest_CID).

A few hours later they may have a new discrete piece to add to the database:

1. Generate the piece, including its CID
2. Update the manifest, get a new manifest_CID
3. ipfs name publish mainfest_CID

No on chain transaction necessary!

If the publisher loses their IPNS key they can submit a new transaction registering themselves as a new publisher.

Consumer

Wants up to date manifests for topic: my-special-database. Consults the Broadcaster contract and 3 publisher IPNS
IDs are returned:

> k52...abc
> k51...123
> k54...456

Looks up each one using IPFS to get the manifest from each publisher. Makes an informed decision about which is most up
to date using the info within the manifest (e.g., pick the one with most pieces or the highest block number).

Uses the CIDs from the favourite manifest to get the data.

Unresolved

IPNS ID derivation

Can a single IPFS node maintain different IPNS keys?

E.g., a single node might want to publish different topics, and could
perhaps create a new key (and hence IPNS name) for each.