Closed yaronyg closed 8 years ago
yaronyg
commented
8 years ago @baydet Make sure to grab me on Monday and we should walk through the text together. I'm going to ask you to please explain to me what you think the text means and I'll then answer questions.
baydet
commented
8 years ago Review status: 0 of 1 files reviewed at latest revision, 2 unresolved discussions.
pages/documentation/PresenceProtocolBindings.md, line 311 [r1] (raw file):
HTTP endpoint
this link forwards to 404
pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):
but if it wishes to do so without hiding all of its identity
What is the cases when advertiser want to hide its identity? How advertiser will know that it should create completely new UUID
Comments from Reviewable
baydet
commented
8 years ago Review status: 0 of 1 files reviewed at latest revision, 4 unresolved discussions.
pages/documentation/PresenceProtocolBindings.md, line 354 [r1] (raw file):
; UUID is defined in [RFC 4122](https://tools.ietf.org/html/rfc4122) Generation = 1*HexidecimalDigit HexidecimalDigit = 0-9 / A-F
NB: /Hexidecimal/Hexadecimal
_pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):_
Whenever a Thali app is told to start advertising it MUST generate a new UUID for its MCPeerID (and this UUID MUST be generated separately from the UUID used with the service browser to make sure that the two UUIDs are different, this prevents state issues with having multiple MCSessions between the same two peers). It MUST also start its generation counter at 0. If the peer wishes to notify the peers around it that it has a new value but if it wishes to do so without hiding all of its identity then what it can do is start a new MCNearbyServiceAdvertiser object with a new MCPeerID that consists of the same UUID as the previous MCNearbyServiceAdvertiser but with the generation incremented by 1. Note that the generation value MUST be a string encoding a hexidecimal representation of the counter. This will let remote peers recognize that this is the same peer they have seen before but with new data. This trick is used to make it easier for peers to preferentially look for data from known remote peers.
NB: /hexidecimal/hexadecimal
Comments from Reviewable
yaronyg
commented
8 years ago Review status: 0 of 1 files reviewed at latest revision, 4 unresolved discussions.
pages/documentation/PresenceProtocolBindings.md, line 311 [r1] (raw file):
Trying to fix
_pages/documentation/PresenceProtocolBindings.md, line 354 [r1] (raw file):_
D'oh!
pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):
D'oh!
pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):
Check the new text. It tries to answer the question.
Comments from Reviewable
baydet
commented
8 years ago Review status: 0 of 1 files reviewed at latest revision, 2 unresolved discussions.
_pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):_ Cool. Explanation below seems to be fine. But I would like to leave previous statement
if it wishes to do so without hiding all of its identity
because it was straighter than the new one. The new is kind of slippery because of words "slightly more trackable". For my engineer brain it is hard to understand what logic stands for "slightly more"
Comments from Reviewable
baydet
commented
8 years ago Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.
pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):
ok
Comments from Reviewable
baydet
commented
8 years ago 
Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.
Comments from Reviewable
Everything we thought we knew about MPCF in iOS has turned out to be wrong. This is an attempt to provide a design based on what we have learned.
This change is