The more I'm thinking about the issue of attaching a tag to feed ids, the less I'm convinced it is a good idea.

Conceptually, this information belongs to the feed itself. By putting it into the references, a bunch of problems arise:

• this information is duplicated in every single reference rather than having a single source of truth
  • inefficient
  • not robust, inconsistencies will crop up
• public keys do not uniquely identify feeds anymore, there can be two feeds with the same pubkey but different tag
• anyone can claim that a feed has a certain type, without needed the private key to prove it
• malicious actors can cause you to interpret data in a different way than it was intended, by specifying a non-truthful type
  • this screams "attack vector"
  • and how could you even know which type is correct?
    • trying everything and seeing what works is not a good strategy, also polyglots) can exist
• a single tag is fairly restrictive, what if we needed feed types which were parameterized over e.g. a number, or some keys, or whatever
  • all the previous issues are vastly amplified in this scenario

These problems arise because feeds - unlike messages - are not really entities that exist and can be linked to. So to solve this, we'd need a place to store information about a feed. And there's a fairly obvious one (ignoring backwards-compatibility for now): The feed's first message. It wouldn't actually have to be a real message, but the first entry of the feed's sigchain would point to a hash of some data rather than being a "null pointer". Or maybe we don't even need any indirection there, the first sigchain entry can simply contain all the feed-type data in place of the backlink.

To get this backwards-compatible: Legacy messages can't have any feed type rather than the implicit default one, and the non-legacy metadata design can accommodate this.

CC @Dominic @dinosaur