todd, can you talk me through how the hub.secret scenario would work? at first glance, it feels like there would be 2 ways to do it:
a) request a hub.secret each time you publish (wastes requests) b) request a hub.secret once and store that on the publisher (adds complexity for publishers) also, can you give a more specific example of where this is an issue so I understand the use case better? i guess my general assumption is that most stuff done on a "low power device" would be synced to the cloud and the backend servers could easily take the weight of the GET request from the hub. On Jan 30, 9:58 am, todd hoff <[email protected]> wrote: > Can't something like hub.secret be used? And if the publishers has to > format the data correctly for a get why is it a problem to format it > correctly in the push? > > On Jan 30, 8:39 am, Josh Fraser <[email protected]> wrote: > > > > > Isn't the real challenge around protecting the hub from spoofing? The > > way it is now it doesn't matter if someone fakes a ping to the hub as > > the hub will fetch the feed for itself and verify it. If you switch > > to fat pings you open yourself up to spoofing. You could add another > > form of authentication to deal with this, but it starts to get more > > complicated. Not to mention the challenge of getting data > > normalization right on the publishers end when one of our core > > guidelines is "keep the complexity at the hub" > > > On Jan 26, 10:22 pm, todd hoff <[email protected]> wrote: > > > > My understanding is that there's a light ping from the publisher to > > > the hub. It would be convenient to use a fat ping here for the same > > > reason as a fat ping makes sense from the hub to the consumer. > > > Especially for low power devices the extra operations are a bit of a > > > drain.
