update
This commit is contained in:
parent
cfaee41cf4
commit
8626e67e97
1 changed files with 43 additions and 23 deletions
|
@ -1,7 +1,7 @@
|
|||
The way [[XMPP pairing|design/assistant/XMPP]] currently works, each
|
||||
separate repository needs to use a different XMPP account. If two
|
||||
repositories use the same XMPP account, then they will be combined together
|
||||
than XMPP pairing takes place.
|
||||
when XMPP pairing takes place.
|
||||
|
||||
There are two different UIs for XMPP pairing. While the same protocol
|
||||
is running behind the scenes, these UIs should be considered separately.
|
||||
|
@ -35,49 +35,69 @@ a reasonable requirement.
|
|||
## Share with a friend
|
||||
|
||||
Suppose that Alice wants to share with Bob. Bob is using the same XMPP
|
||||
account for two separate repositories, that are not themselves paired.
|
||||
account for two separate repositories (B1 and B2), that are not
|
||||
themselves paired.
|
||||
|
||||
When Alice chooses to share with Bob, a XMPP pair request is sent.
|
||||
Both of Bob's repositories see it, and both ask him to confirm.
|
||||
Bob can choose to only confirm the request in one repository, and
|
||||
not in the other. This should work ok.
|
||||
Bob can choose to only confirm the request in B1, and
|
||||
not in B2. This should work ok.
|
||||
|
||||
* The UI for this only says "Pair request received from #{name}",
|
||||
it does not indicate which repository of Alice's is being paired
|
||||
with. This could be improved. If Alice has two repositories as well,
|
||||
she and Bob will want to coordinate pairing the right ones together.
|
||||
Could be fixed by just displaying the description of Alice's repisitory
|
||||
Could be fixed by just displaying the description of Alice's repository
|
||||
to Bob.
|
||||
|
||||
-----
|
||||
|
||||
Now, suppose that Alice makes a second, distinct repository, and chooses to
|
||||
share it with Bob (intending to share with his second repository). This
|
||||
Now, suppose that Alice makes a second, distinct repository (A2),
|
||||
and chooses to share it with Bob (intending to share with B2). This
|
||||
sends an XMPP pair request to both of Bob's repositories.
|
||||
|
||||
One of Bob's repositories has already paired with Alice, so it assumes this
|
||||
B1 has already paired with Alice, so it assumes this
|
||||
new pair request is from a different device belonging to Alice, and it
|
||||
automatically ACKs the pair request.
|
||||
|
||||
The result is that Alice's new repository combines with Bob's repository,
|
||||
which is already combined with Alice's old repository. Effectively
|
||||
combining both her repositories, unexpectedly. **This is a bug**.
|
||||
The result is that Alice's new A2 repository combines with B1,
|
||||
which is already combined with A1. Effectively combining all of A1, A2, B1,
|
||||
and B2, unexpectedly. **This is a bug**.
|
||||
|
||||
1. I think this could be fixed by simply not auto-accepting pair requests
|
||||
Some possible fixes:
|
||||
|
||||
1. Stop auto-accepting pair requests
|
||||
from friends we're already paired with. Require another confirmation.
|
||||
2. Or, only auto-accept pair requests from friends we're already paired with
|
||||
when they come from a repository whose UUID we already know. This
|
||||
enhancment to fix #1 makes it easier to build more robust networks of
|
||||
repositories.
|
||||
3. Alternatively, we could say that the problem is that Bob has two
|
||||
distinct repositories using the same XMPP account, and try to prevent
|
||||
him from doing that in the first place.
|
||||
|
||||
One way to do this would be, when configuring the
|
||||
XMPP account, scan for other repositories using the same account, and
|
||||
don't let it be used unless the user confirms they want to pair them.
|
||||
But, this doesn't seem viable because if the other repository is on
|
||||
another device, which is turned off, this check wouldn't see it.
|
||||
|
||||
Or there could be a warning about account reuse. Doesn't seem likely to
|
||||
be effective.
|
||||
Hmm, I don't think those fixes are sufficient. Suppose they're in place.
|
||||
Then when Alice shares A2 with Bob, both his repositories will ask him to
|
||||
confirm the pair request. He confirms in B2, and pairing proceeds.
|
||||
|
||||
But, XMPP git push is broadcast to all clients of an XMPP account.
|
||||
So when B2 sends a push, A1 sees it, and happily merges away. The
|
||||
repositories still combine!
|
||||
|
||||
So, we need another fix:
|
||||
|
||||
* Send UUID in XMPP git push protocol messages. Only respond to git push
|
||||
messages from a known UUID, and ignore all others. (XMPP pairing
|
||||
already sends the UUID, so it will be known.)
|
||||
|
||||
----
|
||||
|
||||
* Alternatively, we could say that the problem is that Bob has two
|
||||
distinct repositories using the same XMPP account, and try to prevent
|
||||
him from doing that in the first place.
|
||||
|
||||
One way to do this would be, when configuring the
|
||||
XMPP account, scan for other repositories using the same account, and
|
||||
don't let it be used unless the user confirms they want to pair them.
|
||||
But, this doesn't seem viable because if the other repository is on
|
||||
another device, which is turned off, this check wouldn't see it.
|
||||
|
||||
Or there could be a warning about account reuse. Doesn't seem likely to
|
||||
be effective.
|
||||
|
|
Loading…
Reference in a new issue