My interpretation was that the server simply wouldn't allow a specific subgroup of people (non admins, for instance) to communicate with entities outside of the server. So that wouldn't apply to specific waves, I don't think. -- Nathanael Abbotts
On Wed, Nov 3, 2010 at 07:32, dougx <[email protected]> wrote: > Hm... this sounds a lot like copying the wave into a private wavelet > with only a subset of the participants...? > > How could the document handle a different set of events for each > client? The wave would lose sync instantly and fragment into sub-waves > for each different group of participants, no? > > ~ > Doug. > > On Nov 3, 1:31 pm, 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 > > > > ... > > > > 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.
