....what would be the necessary components for a. A Spacetimestamp?
One component would be, or would be similar to, a 64 bit integer timestamp that is the better solution to the 2038 problem. Any measurement is going to be relative. Any revenue point can be simplified, as long as it can be ascertained what it's simplified from.
We could say somthing like width depth and height from some point related to TAI or UTC but no point remains valid over the appreciable scale of a 64 bit timestamp
So I poke a hook into spacetime at the beginning of the Unix epoch.
Planetary rotation immediately disambiguates that location from its current equivalent position at the current second.
And orbiting around the moon earth center of gravity - axial tilt?
Axal drift due to water and ice shifts
Orbiting around a star
That star's orbit around the galactic center
That star's bobbing through the galactic plane
The movement of the galaxy
That's before relativistic effects
...what am I missing
That is to say, a Spacetimestamp of usable resolution might be
8.8 * 10^26 m across for the visible universe... let's give it 128bits for micron accuracy. Just because 96 bits isn't enough for millimeter accuracy.
That's 448 bits for 3.1 dimensions. Then you need to start adding on details to have any indication of what the relevant location may be now.
Of course, for only 3.1 dimensions to work, you need a clear orientation of the universe as well as an origin point.
The whole stargate coordinate "system" is. Nothing. Compared to the scale of this. That is, this is overenginering at its finest.
Sol is a white dwarf. It used to have more planets before the hungry red stage. How many numbers would I need to put In to plan a route back to see the grand pyramid getting built, then dialing the timestamp up a bit, see it done & get the t-shirt
So theoretically a Spacetimestamp would be measured in kilobytes before redundancies ... hamming but better. And yes, hamming should be built in. At the distances this is useful, build hamming in.