@DougAnderson444 Without a little more information I cannot tell you why
ipfs name resolve /ipns/QmKeyHash isn’t resolving on the other machine. It also seems like this issue has very little to do with IPNS over PubSub and is likely a result of either networking/configuration issues (more likely) or other IPNS issues (also possible).
Below is some more information on IPNS over PubSub that should clarify a bit more how it interacts with the DHT and clear up some of your questions/issues. Lmk if you have any more questions/concerns.
DHT usage by IPNS
DHT FindProvs and IPNS over PubSub
ipfs dht findprovs $ipnsDHTRendezvous, where
ipnsDHTRendezvous is defined for a given base58 encoded multihash of an IPNS public key QmIPNSKey as
multihash(sha256, ("floodsub:" + /record/base64url-unpadded("/ipns/base58Decode(QmIPNSKey)))). Note: that while
ipfs dht findprovs internally uses multihashes it takes a CID. The go-libp2p-discovery code deals with this by creating a CIDv1 with a Raw multicodec.
Recall IPNS over PubSub is not enabled by default (as of go-ipfs v0.6.0) and requires
ipfs dht findprovs finds Provider Records (i.e. the multiaddrs of peers who have advertised some interest in a particular key, in this case a multihash). This is used for find people who have IPFS content, as well for finding people who have expressed interest in an IPNS over PubSub topic.
The key used for IPNS over PubSub provider records is SHA256(“floodsub:” + IPNS-over-PubSub Topic Name). The IPNS over PubSub Topic Name is specified/defined, however the IPNS over PubSub DHT record isn’t yet in the spec.
The IPNS over PubSub topic name is defined in https://github.com/ipfs/specs/blob/master/naming/pubsub.md#translating-an-ipns-record-name-tofrom-a-pubsub-topic and https://github.com/ipfs/specs/blob/master/IPNS.md as
/record/base64url-unpadded("/ipns/BINARY_ID"), where BINARY_ID is the wire representation of the multihash of the IPNS public key.
I’ve added some tools for calculating some of these identifiers to https://github.com/aschmahmann/ipns-utils, and just (as of a few minutes ago) added a new function for calculating the DHT rendezvous record name.
DHT IPNS Records
IPNS records (i.e. the full record as defined in the IPNS spec and contains things like the path that it points to, e.g. /ipfs/QmMyData) are published to the DHT using the equivalent of
ipfs dht put $key $value where the value is the IPNS record and the key is
/ipns/BINARY_ID (defined above and in the spec).