Hi@coolsoftwaretyler ! Thanks for taking the time to answer :)

Yes, indeed your suggestion is a quick way to get the primitive. But my issue extends to the async loading of data, and wanting to keep my api response and state as close as possible to each other, without having to write much glue code.

Coming back to my initial example, if my Todo API returns:

{   "id": 2,   "tittle": "hello world",   "author": "3342"}

and I haveauthor as a reference in my model, chance is I might not have the user3342 loaded in the tree, since there might be thousands of users i don't want to pre-load them all in my state (or even not have access to that particular user due to permissions).

I could inline serialise author, but then we need to create glue code, where I have to 2 step update the store, first adding the user to theuserStore, and then modifying the snapshot, changing the inline user to its reference to insert it in thetodosStore. And I cannot usesafeReference because it will turn the reference toundefined, and hence lose data.

Maybe my main issue is losing the data withsafeReference. But if I create a non destructive reference that returnsundefined, the model won't get observed once the referenced object does appears in the tree.

This leaves me with custom references where I have to do a bit of glue code for loading missing references during resolution. I think this is the canonical way of solving my problem. But still very feels very boilerplatey, and doesn't solve the problem of not having permission to load that particular resource from the server

Sorry for the rambling, just putting my thoughts into words.

No apologies necessary - I think the rambling provides good details!

I do think you've sort of found the conventional way to do this. I would offer two pieces of advice to either you or someone else who finds this thread:

1. I do wonder if you could do fewer intermediary steps by lifting your network request up higher in the tree, so that you get all the data you might need, figure out where it needs to be placed in the tree, and then apply it as a snapshot or patch to child stores. So in your example, your network request might come back with two sets of data: one for the TODOs, another for the relevant authors. Then you would add todos and authors in separate actions (or even just one particular patch/snapshot action) to child trees.
2. Alternatively (or maybe this works alongside that option), I find that glue code like this is easier to manage if you treat it like aMiddleware. It doesn't stop you from having to sort of do a bunch of pre-and-post processing, but it does feel like a much more "conventional" place. We have a few places in my app that need to extend MST functionality, and it's nice to know that the edge cases almost all get handled as custom middlewares.

Other than that, I don't know if I have a better answer to your original prompt about the conceptual difference between identifier and tree nodes as references. Maybe someone else will!