Feat: HCS-2 Advanced Topic Registries

[HGraphPunks]

Couple questions, but close to complete I think for a PR

t_id: Should this just be a topic id OR should we add hcs://1/ , hcs://2/ requirement and change to hrl?

I'm torn, one is more flexible and less fragile, while the other helps indexers know the protocol before digesting information.

Reasoning for t_id:

• Reading a topic memo is becoming a backbone element of standards, so it's ok to assume that the memo will have either the protocol memo or the hash (hcs-1) and then will have all the information like if it's indexed.
• lighter weight seems beneficial for ease of registries and lowers probability of incorrect data entry

Reasons against t_id:

• Higher costs on compute: Indexers must always execute another query for every registry message to grab the memo instead of loading all the messages to see if it's a file or a another registry or a logging topic id before executing the lookup memo query to digest the data.

Thoughts?

[kantorcodes]

Realizing I left my comments for HCS-2, on the HCS-6 PR 🤦

Could we introduce a ttl field to help support external infrastructure? I believe this will play well with DNS like registries in the future as well.