Having a block hash does not a DAG make.
Problem statement: an external tool wants to discover the state of the dag.
In theory the external system can ask for show blocks grpc api and get an approximation of the tip of the dag in the view of the given node + some history + finalised block hash and then start poking the node for blocks with show block grpc api.
This approach is inefficient and defeats the purpose of discovery of the dag.
The dag is built from many blocks identified by block hashes. These block contain deployIds.
The deployId is what a user will get when interacting with the system so the ability to track it is desirable.
A notification system “hey, your transfer went through” will require the external system to be able to track the state of the dag and be able to map deployIds to block hashes.
This boils down to:
there is a flag that runs a node with the APIs enabled
there is a way for the external system to ask for the current tip and the current finalised block
there is a way to traverse the dag by asking for parents/children of a given block
the operations don’t lock the system (replay does not affect the ability to get a 'current view')
there is a way to map a block to the deployIds it holds (vide: )