Space-time correction for IPRS validity schema

[Kubuxu]

This might seem a joke now but as project is called Inter-Planetary I think we should correct for light propagation times. In case of Mars the delay would be ~20mins but we don't know how humanity might evolve so it is better to be prepared for it.

Correcting for space would be quite simple, you need to know your position in space and position in space of record origin, calculate distance between them and divide buy speed of light. This gives additional time the record should be valid.

Light cones, blue area is space-time in which record is known and valid:

[lamarpavel]

Wild idea 1:

Upon first contact a coordinate could be sent as additional information, describing the location of the peer establishing contact relative to the sun and earth at the time of sending the message.
This would be enough information for the receiver to calculate the spatial and temporal drift since the message was sent and thus know what kind of timeout to expect.

Now, on the side of the sender initiating the connection there would be the problem of whether or not to hold the connection open until an answer arrives. The receiving peer could be so far away that it can become a resource hog to hold the connection(s) open.
Instead of keeping a connection open for more than a configured time t1, the IPFS itself could be used to drop information in some form of two-way mailbox whose updates reach both the sender and receiver eventually.

After the first contact has been established the distance at the time of correspondence could be stored in a database local to each peer (or even in the IPFS itself) and any subsequent contact could look up past positions in that database and postulate where the peer could be at a later point in time, possibly making another careful negotiation unnecessary.

Wild idea 2:

Periodically every peer publishes their coordinate in space-time relative to the sun in a database(*) within the IPFS. Every peer may now decide (configure) whether or not to pin this database - thus becoming a node suitable for long-distance communication.
Peers who have not pinned this database should still be publishing their location periodically if they want to be contacted reliably. However, not pinning this database could be interpreted as configuring the client not to attempt long-distance communication and only hold open connections for a short time.

(*) There are hundreds of possible ways to realise such a database and I have no idea which would be the best.

Also, I'm sure someone has come up with some form of intergalactic coordinate system that could be made use of, though I know of none.

On a more based and serious note: NASA open sources their stuff, right? One could take a look at their publications for communication with far targets.
It might also be useful to take a closer look at GPS.

[Kubuxu]

My idea included only preparing IPRS for that as the rest of stack is very flexible, special protocols would have to be written but it is possible without changing the rest of IPFS.

Preparing IPRS for that would be a matter of agreeing on coordinate system and storing coordinates in the record and using them during validation.

[Mec-iS]

About consinstency of data and asynchronous updates, I have found great
benefit in reading this article: http://queue.acm.org/detail.cfm?id=2889274
(check links in the references also)

Lorenzo Moriondo, from mobile
https://it.linkedin.com/in/lorenzomoriondo
On Feb 5, 2016 4:58 PM, "Jakub Sztandera" notifications@github.com wrote:

My idea included only preparing IPRS for that as the rest of stack is very
flexible, special protocols would have to be written but it is possible
without changing the rest of IPFS.

Preparing IPRS for that would be a matter of agreeing on coordinate system
and storing coordinates in the record and using them during validation.

—
Reply to this email directly or view it on GitHub
#72 (comment).