I personally think that the solution should be like this: 1) Wave servers should be able to mark users as humans and non humans 2) The deltas exchanged by Wave servers should include for each participant also its type human/nonhuman 3)Robots should be allowed to receive only events caused by humans, unless 4)Robot(A) specified in its capabilities that it is interested to receive events from other robot (B), and robot (B) specified in its capabilities that it is interested to send events to (A)
Of course such solution will not prevent DOS attacks, but at least it will totally prevent scenarios where 2 robots enter infinite loop due to bad design or bug. On Nov 1, 7:58 pm, Vega <[email protected]> wrote: > Wave allows robots to be first order participants in the waves. This a > really great feature with huge potential, however, it also might lead > to unintentional infinite loops causes by robots responding to events > caused by other robots. Google Wave implementation attempted to solve > this issue by preventing from robots to receive non human events. It > seems that this solution was effective enough in the Google Wave > implementation. > However, for a federated system, such as Wave in a Box - such solution > might not be possible even in principle, as there's no way to track > whether participant from other federated served is human or robot. > Moreover, Google Wave's solution is too restrictive as it makes robot- > robot communication nearly impossible to implement and thus limits the > robot functionality. > Let us discuss the issue and see what could be possible solution > viable for Wave in a Box. > Please also take a look at [0]. > > [0]http://code.google.com/p/wave-protocol/issues/list?cursor=131 -- 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.
