Robot Request - text locker

[Akiva]

I know Wave does not allow users to lock the text of their original
blips. Could someone build a robot that would, when enabled, watch
the text of particular blips for edits and restore the original text
if edits are made? This is of particular interest to me because I'm
considering opening a number of public waves on political issues, and
that's exactly the sort of contentious public debate where bad actors
would be likely to alter an author's post in order to discredit them.

[David Nesting]

This sounds easily achievable with a robot.  For each event, the robot checks to see if the edit is authorized, and if not, reverts it to the last known authorized edit.  The caveats:

1. Depending on which blips you want to lock, the robot may need to be added prior to an authorized edit, for it to see the content (since all of the blips in a wave aren't normally sent with events).

2. You'll effectively need to store your own copy of the content of all of the blips locked in this manner.  The storage burden may be significant.

3. Wave has no functionality to authenticate events[1], so it would be possible for someone to forge an event to your robot containing a fake "authorized" edit to a blip (or an unlock command), causing your robot to accept the edit.  It also allows someone to read blips in a wave they don't have permission to see, assuming they could get their hands on the wave ID, by submitting a bogus edit event to that blip and watching what your robot reverts its content to.

David

[1] http://code.google.com/p/google-wave-resources/issues/detail?id=344

--

You received this message because you are subscribed to the Google Groups "Google Wave API" group.
To post to this group, send email to google-...@googlegroups.com.
To unsubscribe from this group, send email to google-wave-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.

[Olreich]

Robots can now see the entire conversation upon addition, by adding a
context="children" to the "WAVELET_SELF_ADDED event in
capabilities.xml according to cmdskp. I've not tested it, but from the
feedback it appears to work intermittently this is probably because
the whole child-parent thing and context thing are both in early beta
and subject to change without notice, meaning that we're trying to
shoot a moving target, as cmdskp said.

> > google-wave-a...@googlegroups.com<google-wave-api%2Bunsubscribe@ googlegroups.com>
> > .

[Stephen George]

Oreich, just fyi, I have tested cmdskip's approach and I personally
did NOT have success. My capability was:

<w:capability name="WAVELET_SELF_ADDED" content="true"
context="children"/>

As he said though, it's possible that the lack of data is an
intermittent issue, and that ultimately this approach will work (I
hope).

S

[Austin Chau (Google employee)]

Hi Stephen,

Did you try to change the version # of capabilities when you change the context attribute?

Austin

To unsubscribe from this group, send email to google-wave-a...@googlegroups.com.

[qMax]

There is "readonly" robot, that restores blip content when it changed.
Have you checked it?
(i can not find it right now)

[cmdskp]

My robot is: clea...@appspot.com

Please test it yourself - just create a new wave and add lots of
nested blips with a lowercase word in each, then add my robot. If any
have missing capitals it'll correct them.

The only types of blips I've not tested are internal comment blips.
So, do not expect them to change - they may, I don't know.

Proof is in the trying - so please do.

[cmdskp]

(It won't let me post a full URL, please join the following three
lines to see the screnshot)

http:

//img268.imageshack

.us/img268/268/exampleallblipsmodified.png

This is a screenshot straight after being added to the wave of blips.
You can see the highlighted changes wave shows for the modifications.

On Nov 25, 1:52 am, cmdskp <cmd...@gmail.com> wrote:
> My robot is: clean...@appspot.com

[cmdskp]

My appologies for the triple-post, but on-topic, here's the address of
the readonliebot:

readon...@appspot.com

Never tried it, but hopefully that'll do some of the job you want in
the meantime, Akiva.

[Akiva]

Thanks - I'll give it a shot

[RoboPhred]

To use readonlybot, add "OWNERONLY" to the blip. if you add
"readonly" then noone can edit it including yourself.

If you want to control who can edit the blip, you can use my security-
b...@appspot.com. you can use
security: blip-edit allow us...@address.com
to let others edit it. if you just want to deny a few specific users,
use deny instead of allow.
The benifit of mine over readonlie is that it will also revert changes
to gadgets as well (this needs to be a seperate access control set,
right now its in blip_edit). However, i have seen it choke on some
gadgets before, mostly the whiteboard gadget, so test it in a private
wave first.

The robot is still under development, and still has bugs. It might
hiccup from time to time as I add in more access control and a finer
level of permissions.

On Nov 24, 7:23 pm, cmdskp <cmd...@gmail.com> wrote:
> My appologies for the triple-post, but on-topic, here's the address of
> the readonliebot:
>

> readonlie...@appspot.com