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