Vega, that is a brilliant idea! On Nov 3, 2010 1:31 AM, "Vega" <[email protected]> wrote: > 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]<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.
