gossipsub API inconsistency between sub-unsub and topics

[drHuangMHT]

Behaviour::subscribe and unsubscribe both take Topic<H> while Behaviour::topics returns TopicHash, and Topic<H> cannot be build from TopicHash. This will make it difficult for users to unsubscribe a topic without manually mapping from TopicHash to String representation of the topic.
Both subscribe and unsubscribe are considered "human-friendly"(Topic<H>can be built from human-readable String repr of the topic), while topics is not(TopicHash is not human-readable and cannot be unwrapped to human-readable String repr of the topic).
Is this intentional?

[AgeManning]

Yep this is intentional.

Originally there was a complication where other implementations had no concept of using a "hash". There were issues with security originally and later it got adopted. The concept of a non-hash'd topic, is a user-friendly object that can abstract away the binary form of the topic. The input of a functions use this user-friendly type, however the internals of gossipsub only work with the hash'd versions. I.e once you submit a Topic gossipsub then instantly converts it to a TopicHash and stores that.

The behaviour::topics function was a helper function that was later built to get access to what topics we are subscribed to. As the internals only know about the hashes we have no way of finding the pre-image and so this necessarily must return hashes. We could make it consistent, but requiring the subscribe and unsubscribe (and other public functions) to only use hashes also, but it may detract from the usability.

Unfortunately I dont see a way around this, other than storing the pre-image of all the hashes we use along side the hash. But this seems more like a waste of memory for a slightly better user-experience, when the user themselves could also just build this mapping.

[drHuangMHT]

I understand that gossipsub only works with hashes internally. But it would be better that users can also subscribe and unsubscribe using hashes, because that's what is being used internally anyway.