Both of you raise important points here: > On 5 Dic, 07:04, Adam Ness <[email protected]> wrote: > > The inherent problem with deleting waves is that unlike deleting an > > email, the wave itself is shared among many users, so you're deleting > > things out of other people's mailboxes when you delete a wave. I'm > > not sure that I would like to allow other people to delete waves that > > I've been adding things to without my permission.
On Dec 5, 11:01 am, fabrizio-mc <[email protected]> wrote: > In my mind there are two ways to solve this issue > > 1) we assume that the partecipant who has created the wave has more > rights on it then other partecipants: > In this case only the creator can permanently delete the wave. > When he delete the wave other partecipants receive a notification, > > 2) we assume that all partecipants have same rights on the wave (I > prefer this solution): > Each partecipant can trash the wave > Each partecipant can permanently delete the wave but only from his > personal trash folder > The wave was automatically deleted when the last human partecipant > trashes (or delete) it (Robots are not considered as human > partecipants). However, neither considers issues of privacy control and local storage requirements, particularly once federation among wave servers is common. For that reason, true expunging is absolutely required. Imagine if you find YEARS after you broke up a bad relationship still "archived" waves in your trash, which may or may not be active because other participants didn't trash that wave. Further, this could lead to all sorts of DoS attacks: get someone to join a wave, and then keep sending massive amounts of data to that wave, filling up your wave server's storage space. Thus I absolutely cannot support this statement: > > For all intents and purposes, trashing a wave should be fine. Interestingly enough, this also touches on another sticky point: how to remove a user from a wave So what is my proposed solution? Introduce the notion of STATE to waves and users. A user can be part of a wave, not be part of a wave, a have-been part of a wave, or blocked from a wave. A wave can be active, or frozen or fossilized. A user is part of a wave or not part of a wave: same as it is now A user is an ex-participant of a wave: he will no longer see changes to the wave, but unless he deletes the wave, he still retains access to what is in the wave up to the point where he removed himself or was removed from the wave. A user is blocked from a wave: it is impossible for that user to see, join, or retain any contents of that wave. A wave is active when it behaves like waves currently do. A wave is frozen when any participant chooses to freeze it. At that point, the wave can no longer be modified, however, any participant is free to fork a new wave with a copy of that wave. Since the original wave at this point cannot be modified anymore, each user can freely delete it and expunge the trash, which in essence removes his retain pointer to that wave and changes his status from participant to ex- participant in that wave. A wave is fossilized, i.e. permanently immutable once all participants have frozen the wave, which allows the wave to stop consuming active resources, while allowing it to still live in an archive folder. When someone creates a wave he must be able to choose a confidentiality level of the wave, which determines who can or cannot be part of a wave. The levels I would suggest are: a) open (just like what exists now, democratic, users can only remove themselves) b) moderated (any new participant must be approved by the creator/ moderator, which also has the privilege to remove users) c) selective (basically an open wave, but users have the option to blacklist individual users from becoming part of that wave, be that accidentally or through indiscretion) d) confidential (like a moderated wave, but private replies and wave copies are impossible, forcing full disclosure of what's going on in the wave at all times) Here some usage scenarios: a) e.g. general semi-private communication, as is now b) e.g. communication that needs protection from spammers c) e.g. your discussing within the family the birthday gift for one family member, and you want to prevent that someone accidentally adds that family member to the wave and thus gives away the secret d) you're working on a new iPod and want to make sure the wave stays on topic, and there are no easy ways for information to accidentally leak into other waves. This may be far from complete, and it may have some issues in regards to the algorithms underlying the wave concept (I'm not familiar with what these are), but this is how it will have to work eventually for waves to replace e-mail, BBS, IM/chat and collaborative document editing systems. -- You received this message because you are subscribed to the Google Groups "Google Wave API" 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/google-wave-api?hl=en.
