Presently we're maintaining two kinds of treasure maps: TreasureMap and SignedTreasureMap. This stems from a difference in serialization formats due to different signing mechanisms. In blockchain mode Alice signs the treasure map with her ethereum wallet so that it can be verified that it was authored by the same actor that published the policy on-chain. An EIP-191 (65-byte) signature is applied which is different than the signatures that can be created using stamps in federated mode. This results in the following patterns appearing in several places in the codebase:

if federated:
    from nucypher.policy.maps import TreasureMap as MapClass
else:
    from nucypher.policy.maps import SignedTreasureMap as MapClass

Or this monster from interface validators:

def _validate(self, value):
    try:
        # Unsigned TreasureMap (Federated)
        from nucypher.policy.maps import TreasureMap as UnsignedTreasureMap
        splitter = UnsignedTreasureMap.get_splitter(value)
        splitter(value)
    except InvalidNativeDataTypes:
        try:
            # Signed TreasureMap (Blockchain)
            from nucypher.policy.maps import SignedTreasureMap
            splitter = SignedTreasureMap.get_splitter(value)
            splitter(value)
        except InvalidNativeDataTypes as e:
            raise InvalidInputData(f"Could not parse {self.name}: {e}")
    return True

• Is treasure map signing by ethereum wallet a valid protocol security concern? If not we can simply sign with stamps or not at all.
• Can we implement an EIP-191 compatible signature for federated mode?

The goal of this issue is to unify treasure maps into a single class or entity that can be used in both operating modes, if possible.