thaliproject / thali

Our root repository for all of our projects
MIT License
86 stars 13 forks source link

New iOS design #274

Closed yaronyg closed 8 years ago

yaronyg commented 8 years ago

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 Reviewable

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):

Previously, baydet (Alexander Evsyuchenya) wrote… > > HTTP endpoint > > this link forwards to 404 >

Trying to fix


_pages/documentation/PresenceProtocolBindings.md, line 354 [r1] (raw file):_

Previously, baydet (Alexander Evsyuchenya) wrote… > NB: /Hexidecimal/Hexadecimal >

D'oh!


pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):

Previously, baydet (Alexander Evsyuchenya) wrote… > NB: /hexidecimal/hexadecimal >

D'oh!


pages/documentation/PresenceProtocolBindings.md, line 357 [r1] (raw file):

Previously, baydet (Alexander Evsyuchenya) wrote… > > 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 > >

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):

Previously, baydet (Alexander Evsyuchenya) wrote… > 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" > >

ok


Comments from Reviewable

baydet commented 8 years ago
:lgtm:

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.


Comments from Reviewable