s/signature/signer info/g
On Sun, Nov 8, 2009 at 8:43 PM, Anthony Baxter <[email protected]>wrote: > > That was part of the plan for the 0.3 spec. > > Remote sends delta. > Host replies with error saying it needs the signature > Remote sends signature+delta. > > On Sun, Nov 8, 2009 at 13:19, Ben Kalman <[email protected]> wrote: > > Yes, that is the plan. It would even (perhaps) be nice to modify the > > protocol so that signer info can optionally be sent with an XMPP submit, > to > > reduce the number of necessary roundtrips. > > > > On Sun, Nov 8, 2009 at 1:14 PM, Tad Glines <[email protected]> wrote: > >> > >> OK, I should have read your previous post more carefully. > >> > >> You're saying that the host will simply reject a delta if it doesn't > >> have the signer info, thus forcing the remote to send it and then > >> re-transmit the delta. That will work. It also reduces the amount of > >> state the host has to keep track of. That's something I hadn't > >> considered. > >> > >> On Sat, Nov 7, 2009 at 5:58 PM, Ben Kalman <[email protected]> wrote: > >> > As I said before, the host of a wavelet should not have to deal with > >> > certificate distribution itself, it should just accept and distribute > >> > updates to wavelets. This is why the host will not do a > >> > getDeltaSignerInfo. > >> > > >> > > >> > On Sun, Nov 8, 2009 at 12:54 PM, Tad Glines <[email protected]> > >> > wrote: > >> >> > >> >> Sending the same certificate chain with each delta is a massive waste > >> >> of bandwidth. > >> >> There is no reason to send the same exact chain each time. If the > only > >> >> way to get a cert chain was via getSignerInfo then server's would > only > >> >> need to ask once for each new signer info id encountered. > >> >> Yes there is a little extra delay with that first delta containing a > >> >> new signer info id, but it'll save on lots of bandwidth later. > >> >> > >> >> > >> >> On Sat, Nov 7, 2009 at 5:38 PM, Ben Kalman <[email protected]> > wrote: > >> >> > Whenever a server send a signed delta (whether that be due to > >> >> > broadcasting > >> >> > an update as the host, or submitting a delta as the remote) the > >> >> > receiving > >> >> > server must be able to verify the delta, so must have the > >> >> > corresponding > >> >> > certificate (signer info) for the signer id encoded into the signed > >> >> > delta. > >> >> > > >> >> > Whether the server gets this through being posted the signer info > >> >> > (postSignerInfo) or whether it has to request it > (getDeltaSignerInfo) > >> >> > depends on where the wavelet is hosted -- it is up to the remote > >> >> > server > >> >> > to > >> >> > ensure that all the certificates in place, i.e. the host server > >> >> > should > >> >> > never > >> >> > have to worry about distribution of certificates. So the remote > must > >> >> > getDeltaSignerInfo if it receives an update with a missing > >> >> > certificate, > >> >> > and > >> >> > postSignerInfo on every submit. > >> >> > > >> >> > So, two separate issues with this: previously (up until a9597f31ff) > >> >> > there > >> >> > was a rather bad shortcut taken to avoid the complications of > >> >> > callbacks/queuing (tight time schedule :), where certificates were > >> >> > posted to > >> >> > remove servers from the host on updates. This has been fixed. > >> >> > > >> >> > The other issue is (as Tad noticed) a certificate is posted with > >> >> > every > >> >> > submit. This is necessary based on an assumption that the host > >> >> > doesn't > >> >> > have > >> >> > our certificate, since we have no way of knowing this. It's also > >> >> > somewhat > >> >> > realistic given that FedOne servers don't persist certificates. > >> >> > However, > >> >> > once we formalise an error spec (soon) and FedOne/Google supports > >> >> > propagation of error messages/codes (soon), the plan is for the > host > >> >> > to > >> >> > reject signed deltas with are missing signer info with a > recognisable > >> >> > error > >> >> > code, so that the remote can then send the signer info only when > >> >> > required. > >> >> > > >> >> > Hope that made sense :-) > >> >> > -- Ben > >> >> > > >> >> > > >> >> > On Sun, Nov 8, 2009 at 7:20 AM, Daniel Danopia < > [email protected]> > >> >> > wrote: > >> >> >> > >> >> >> This is funny because Sails hasn't gotten a single certificate in > >> >> >> over > >> >> >> a week from FedOnes, since FedOne requests them now xD > >> >> >> > >> >> >> On Nov 6, 8:28 pm, Tad Glines <[email protected]> wrote: > >> >> >> > It looks like FedOne will post signer info to the fed host every > >> >> >> > time > >> >> >> > it sends a delta. > >> >> >> > This seems very inefficient. It seems to me that FedOne should > >> >> >> > only > >> >> >> > send signer info as a result of a direct request. > >> >> >> > > >> >> >> > I thought I might have seen an issue or code review request > >> >> >> > related > >> >> >> > to > >> >> >> > this, but I couldn't find it. > >> >> >> > > >> >> >> > -Tad > >> >> >> > >> >> > > >> >> > > >> >> > > > >> >> > > >> >> > >> >> > >> > > >> > > >> > > > >> > > >> > >> > > > > > > > > > > > > > -- > Anthony Baxter, [email protected] > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
