# Moving over notes to make sync.py less noisy

## TODO: Sync modes, interactive (+bw -latency) and batch (v.v.)

# Need to encode logic for actions taken at given time,
# respect send_time etc,
# WRT offer messages and so on

# Batch mode first (less coordination):
# - **Acknowledge** any messages **sent** by the peer that the device has not yet
#   acknowledged
# - **Acknowledge** any messages **offered** by the peer that the device holds,
#   and has not yet acknowledged
# - **Request** any messages **offered** by the peer that the device does not
#   hold, and has not yet requested
# - **Send** any messages that the device is **sharing** with the peer, that have
#   been **requested** by the peer, and that have reached their send times
# - **Send** any messages that the device is **sharing** with the peer, and does
#   not know whether the peer holds, and that have reached their send times

# each tick
# SEND messages device is SHARING with the peer, doesn't know if peer holds,
# and reached send time
# What mean by sharing

# Member of a group:
# Two peers sync group message they share group
# Membership and sharing dynamic

# How do we de determine if two peers synchronize a
# specific group's messages with eachother?

# For any given (data) group, a device can decide
# if they want to share or not with a peer.

# TODO: ACK should also be share policy
# XXX: Encode offline mostly

# XXX: How does B look at the message?

# XXX: If A,B reliability 0.1 and C 0.9
# How does that actually realistically look?

# Need to encode the other actions and offer etc
# Exponential backoff too probably

# Then C can offer messages to B, e.g.

# How viz message graph?
# XXX: How will C receive the message from A to B?
# TODO: Requires offering to B, e.g.
# Or B requesting it

# Why is A sending same message to C over again
# and again, with reliability = 1,1?
# C no op? it acks but A ignores it?
# Duh, C sends but A doesn't see it...

# TODO: When A comes online, whenever that is
# It needs to requests messages
# Aka ask C (or whomever) for messages
# How?
# - **Request** any messages **offered** by the peer that the device does not
# But how would it know to offer messages?
# It could play nice and offer all messages it has to C, but if C has all
# There needs to be some way for C to go for it, unless A is going to over-offer with bloom filter or so
# Look into this a bit more, naive way is signal

run(20)

# XXX: What happens if ACK fails? Offer back? Lol.
# See no mention of re-send acks

# Actually C should have other message right? Oh no can't, need 4th node
# Voila, introduce 4th node only semi conected and awareness
# Even if never online or never both connected to same super node!

# It is even the case that message from A 4ea1 then B 9e70
# So A holds data from B without knowing B has it! Propagated through C
# And C got it from D!
# But if A and B online same time then this data is available

# One problem is that you don't know REQ/etc state of data. Chill and OK?

# What do we want to measure here? In terms of reliability of perf etc

# Probably want to clean up this file a bit as well
# Different basic scenarios with assumptions?
# Message propagation? Not sure

# Privacy and sharing implications
# Exact diff with peer connected to and sharing
# If you introduce new party for sharing data, well they know you connecting
# What does this imply exactly? Esp if network topology is certain way

# Write down specific questions/concerns here