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 > >> >> > >> > > >> > > >> > > > >> > > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
