IMHO this should not be a necessary part of the protocol. Robots should not be programmed to respond to every message. Doing that would not have any benefit to the developer because users would very quickly get annoyed with them.
On Nov 1, 10:19 pm, Alex North <[email protected]> wrote: > In fact, it was an architectural flaw in Google Wave that robots could not > talk to each other. It was never desired behaviour. Our vision was that > robots could do "anything a human can do". Of course didn't quite get there, > but were working towards it. > > In the current federation protocol there is no means to identify a > participant as being automated or not. Even if there were, that would > require trusting arbitrary federated wave servers to correctly identify > their participants. Apart from there being many valid reasons that the > distinction is unnecessary, this would be somewhat like trusting mail > servers not to send spam. Protection against abuse needs to be done > elsewhere, possibly imperfectly. > > There is some concern that two talking robots could enter an infinite loop. > I'm not convinced that this is something we need to design the protocol to > protect against. We should instead implement wave servers such that they can > handle bursts of traffic from arbitrary endpoints without falling over, > perhaps with some kind of throttle. If they detect that some (possibly > federated) participant or server is abusive, it's the receiving server's > call whether to cut them off. No loop is infinite because waves have size > limits: right now there is a size limit built right into the protocol, but > even if there wasn't there would be an effective (if unpredictable) size > limit when some server was no longer able to hold the wave in memory. Again, > a robust server should be able to evict such a wave without going down in > flames. > > There are some legitimate user experience reasons that it would be useful to > identify robots on some kind of best effort basis. Wave providers may wish > to provide a bunch of standard robots or something, and display some > indication to their users of the automated nature of these participants to > set the right expectations. But that could only ever be a best effort > service - they couldn't reliably classify arbitrary participants as > automated or not. I'm ignoring these use cases for now - such a mechanism > doesn't need to go into the core protocol but would appear in a server's > profile implementation. > > My 2 cents (ok, maybe a bit more than than) > Alex > > On 2 November 2010 05:05, Vega <[email protected]> wrote: > > > > > > > > > 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]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. -- 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.
