The only example that I can think of where it would greatly improve what a robot can do, is with a moderation robot, which would go through different processes based on whether it was a robot or a human. But yes, well coded bots shouldn't have this problem, with one exception. Robots which respond to specific events *every* time they happen, with no exceptions.
On Tue, Nov 2, 2010 at 22:00, Nathanael Abbotts <[email protected]>wrote: > With my system, it is up to the robot. The robot can choose if it wants > events from robots or not. > Unless there is a way for servers to tell each other what is and isn't a > robot (even if it requires the server that doesn't know explicitly asking), > then it isn't truly up to the robot, as it won't know. > -- > Nathanael Abbotts > > > > > On Tue, Nov 2, 2010 at 21:55, Gamer_Z. <[email protected]> wrote: > >> But would it not be easy for a server to tell another server that a >> given participant is a human when it is actually a robot. I still >> agree with Joseph and think this should be up to the robot. A well- >> coded 'bot should be programmed to avoid infinite loops. >> >> Also, regarding your example of a translation 'bot, we found out with >> Aunt Rosie that a robot that replies with translations gets annoying >> quickly, so I doubt that someone would repeat it. Better to do it >> Rosy-style where the client can be set to show translations in-blip if >> the user requests it. And if there were a standard "translation" >> annotation, then robots could be set to look for it so they know >> whether or not to translate a given blip. >> >> On Nov 2, 5:49 pm, Nathanael Abbotts <[email protected]> wrote: >> > Is there no way that it could be possible for a server to identify >> someone >> > as a robot? >> > Surely if we had profile operations, then it could be done. Not sure >> though >> > - this solution would only work if we have a rusty-esque robot proxy, in >> > which case the rusty agent could decide to withhold an event based on >> the >> > capabilities, if only for robots that connect to that particular server >> (via >> > rusty), and not for robots connected to other servers. >> > -- >> > Nathanael Abbotts >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Nov 2, 2010 at 21:44, Joseph Gentle <[email protected]> wrote: >> > > Right; but we still have no way to tell who's a robot and who's not >> > > via federation. >> > >> > > I think we should keep things simple; and make it up to the robot >> > > which blips it responds to. >> > >> > > -J >> > >> > > On Wed, Nov 3, 2010 at 5:16 AM, Nathanael Abbotts < >> [email protected]> >> > > wrote: >> > > > If in the capabilities.xml of the robot (or equivalent), a robot >> could >> > > > specify if it wants to receive events triggered by robots for each >> event, >> > > > then this problem could be fixed. >> > > > For instance, a translation robot wouldn't want to receive >> blipsubmitted >> > > > events from other robots, but a table of contents robot definitely >> would. >> > > > If even more detail is needed or wanted, a robot could specify only >> to >> > > get >> > > > events from specific robots. Here is an extract from an example xml >> file: >> > >> > > > <w:capabilities> >> > > > <w:capability name="ANNOTATED_TEXT_CHANGED" context="ROOT,SELF" >> > > > filter="myrobot/annotationname" >> > > > robots="[email protected],[email protected]" /> >> > > > <w:capability name="BLIP_SUBMITTED" context="ROOT,SELF" robots="" /> >> > > > <w:capability name="WAVELET_SELF_ADDED" context="ROOT" robots="*" /> >> > > > </w:capabilities> >> > >> > > > Here, we have 3 events. The first one is annotated_text_changed, >> which is >> > > > used by the robot to track specific selections within a blip. The >> robot >> > > only >> > > > cares if a human, or one of 2 specific robots, changes this. >> > > > Next, blip_submitted. For this event, the robot is not interested in >> > > events >> > > > from other robots, so an empty string is provided. >> > > > Finally, wavelet_self_added. Because this robot happens to do an >> > > important >> > > > action which, if not done, will cause errors in future, the robot >> wants >> > > this >> > > > to happen regardless of who added it. >> > > > -- >> > > > Nathanael Abbotts >> > > > Email: [email protected] >> > > > Wave: [email protected] >> > > > Twitter: @natabbotts (http://twitter.com/natabbotts) >> > >> > > > On Tue, Nov 2, 2010 at 07:32, Vega <[email protected]> wrote: >> > >> > > >> If it is possible to handle bursts of traffic from arbitrary >> endpoints >> > > >> without falling over - it is great. But what about robot providers? >> > > >> Let's take for example a robot running on App Engine. It only takes >> a >> > > >> child to create a new wave, add there some text, then add 2 >> > > >> translating robots and let them translate each other until the wave >> > > >> explodes (or wave server somehow discovers abuses and... close the >> > > >> wave?) These robots will burn a lot of their quota. And it only >> takes >> > > >> a child to cause such abuse. I think translating robot will be >> > > >> interested to react only on human events, or on nonhuman events >> that >> > > >> it trusts. Failing to provide such mechanism will totally expose >> > > >> robots to abuse, imho. And wave server providers will also pay the >> > > >> price in form of handling spam traffic. >> > >> > > >> On Nov 2, 6:50 am, Wim <[email protected]> wrote: >> > > >> > Why not? If the robots aim is best served by responding to all >> > > >> > messages then why shouldn't it respond to all messages? Imagine >> a >> > > >> > translation bot that embeds replies in a blip translating that >> blip >> > > >> > into selected languages, why should other robots blips be ignored >> by >> > > >> > this bot? >> > >> > > >> > It should be up to the robot to determine what messages it is >> > > >> > interested in, first case for almost all robots would be ignoring >> > > >> > messages from itself. After that it would have to filter based >> on >> > > >> > what it is setup to do; whether that is checking the content to >> > > >> > determine if its control commands are there, or if the author >> matches >> > > >> > the author that added it to the conversation, or .... This is >> all >> > > >> > part of the logic of the robot based off how it is to behave. >> > >> > > >> > Allowing robots to respond to other robots definitely does have >> the >> > > >> > problem of infinite recursion. Something as simple as two echoey >> > > >> > robots in the same wave from different servers could cause this >> > > >> > problem, or two spell checking robots battling over whether it is >> > > >> > spelt "color" or "colour". As Alex said this issue should be >> dealt >> > > >> > with at the server level, maybe servers should have some method >> to >> > > >> > provide both clients and robots with a 'warning' that they are >> close >> > > >> > to being cutoff and then remove them from the wave if they >> continue >> > > >> > spamming it. >> > >> > > >> > This problem should also be dealt with at the robot level as >> well, >> > > >> > something like a spell checking robot should be storing a list of >> > > >> > words it has changed in a private wavelet and not trying to >> change a >> > > >> > word a second time, e.g. if you are commenting on the "Color" >> class of >> > > >> > some code and the spell checker changes it to "Colour" you should >> be >> > > >> > able to change it back and the spell checker should ignore the >> word. >> > >> > > >> > On Nov 2, 3:27 pm, "Gamer_Z." <[email protected]> wrote: >> > >> > > >> > > 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 >> > >> > ... >> > >> > read more ยป >> >> -- >> 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%[email protected]> >> . >> 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.
