💡Service as a DAG

[Gozala]

You can see a preview on hackmd (but please comment here not on hackmd).

Idea is not fully flashed out and mostly was inspired by schema limitations ipld/ipld#263 and ipld/ipld#262

I'm not 100% in love with the idea described, however there are few key discoveries that I think are worth considering / highlighting and incorporating into our work:

1. We should have a logical (DAG) model of our system.
   • Right now we have bunch of loose parts that connect, but no coherent picture. Having one would help ourselves and our customers
2. We should define a state machine for our model
   • We have vague idea how request goes through system pipeline, but again having an actual model would really help
     • It also would allow us to encode some invariant about which state transitions are impossible (e.g. from complete to pending).
3. Receipts need to provide complete trail of state changes
   • If customer has receipt for some request new receipts for that request should contain one user has
     • That helps with accountability if new state invalidates old one it should be captured
4. This one is bit abstract, but I think we naturally end up in situation where we have same set of operations (add, remove, list) across most namespaces.
   • Perhaps subconsciously we're already be desiging "service as a dag" ?
     • If so perhaps we should just make it explicit ? Would it lead to more simple to understand design ?
   • On the flip side graphql is leading you to think of service(s) as a graph yet it does not limit you to set of operations, instead it forces you to think of operations as queries and mutations
     • On the other hand "dag/post" described here is a generic "request" operation, we just formalize that target state starts off with whatever you've posted.