Heh, I think Isaac Asimov would be delighted to read this discussion :) Joseph, I agree that matters should be kept as simple as possible, but there's also a danger in over simplifying. I think in current state, the protocol is over simplified and doesn't give enough control to it's participants: humans and robots. In fact I think that any participant should be able to provide a capabilities xml to wave server where she specifies exactly what event the participant is interested - be the participant robot or human. In case of human participant - such a need arises when you are admin and you want your users to be blocked from receiving events from users outside of the company. In case of the robot provider - you want to expose your robot only to your payed customers and you don't want to pay for the inbound traffic caused by events sent to your robot by non customer participants.
There's such a thing - too much freedom. Too much freedom leads to anarchy. I think Wave in a Box should address this vulnerability by providing built in mechanism of inbound traffic control. Such control will also benefit the wave server providers as it will minimize spam traffic. On Nov 2, 11:59 pm, Joseph Gentle <[email protected]> wrote: > We could add it to the federation protocol; but it makes the protocol > more complicated. I don't want to add yet more complexity to the > protocols without a good reason. > > Sell me on it - what robots are difficult to write without this flag? > I'm not convinced by the translation robot - it might make sense for a > translation robot to listen to events from other robots, if those > robots submit blips in foreign languages. > > -J > > > > > > > > On Wed, Nov 3, 2010 at 8:49 AM, 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... > > 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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
