-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geographic Redundancy #13
Comments
A single byte should be sufficient to store the octancy of a point in space, along with features useful for surviving solar flares and other cosmic events. Storage providers on geostationary satellites will have a fixed octancy (it should never change), and any higher is considered a "graveyard orbit", so at that distance, orbital decay is not as much a concern beyond stationkeeping to maintain axial tilt with respect to the planetary body and its orbit around the sun. If the provider is in a lower orbit, its octancy may be updated. This can help balance orbital replicas over their respective ground stations. Due to their stability, lagrangian orbits will be given special consideration, and for this reason, 3 bits will be used to indicate orbit. A value of 0 indicates the provider is terrestrial. A value of 1 indicates it's within an orbit that is low enough that there is a highly likelihood that if the spacecraft is no longer capable of altitude or attitude control, it will deorbit within a decade. This will likely include most LEO satellites, including those used by Starlink. A value of 2 indicates geostationary orbit. And values 3-7 correspond to L1-L5 lagrangian points. In summary, bits 0-2 are used for octancy. Bits 3-5 are used to indicate orbit, if applicable. Bit 7 will be set to 0 for Terra, and 1 if the provider is extraterrestrial. Bit 7 is set to 0 for Sol, and set to 1 for interstellar storage providers. These last two bits will determine if the cartographic decoder is to look for additional bytes to indicate additional planets or additional solar systems and their planets. These will then be coordinated with a lookup table in additional specs. Ultimately, Carbonado isn't an Interplanetary File System (IPFS), it's an Interstellar Archive System (ISAS). Archives have similar functionality to file systems, but have different contexts and expectations. Archives are more durable, and indexed differently due to a desire for permanence. Due to the simplified flat-file persistence format, and since storage contracts can vary greatly in agreed upon latency, even retrieval intervals of years or millennia can be accommodated... By the protocol, at least. Furthermore, an astronomical authority can be designated to approve, sign, and certify the storage provider's cartographic code. They may provide a GPS app along with additional proof for terrestrial certification, and radio telescopes could be used to verify the telemetry of extraterrestrial storage providers (ETSPs), which can of course then ask a premium for their storage, the ultimate form of geographic arbitrage. |
It was recommended to include a longitudinal offset in respect to an epoch. This would solve the lack of alignment of the octants, by offsetting the map by, say, half an octant. |
Octants are used to better ensure geographic distribution of data. This is volunteered data, and won't have as much an effect on geographic arbitrage if default storage modes are tolerant of some measure of adjacency. By using an octant system, it's easier to select a different storage region to avoid putting all replicas in the same region without necessarily needing to resort to trigonometry.
The Carbonado Octants System:
Although O4 is quite sparse, if there are no providers available within this region (or others), an adjacent octant will be chosen.
The text was updated successfully, but these errors were encountered: