Beyond the limitations of Google Wave

Google Wave has the merit of bringing very important new online communication features to reality (uh, some don't even agree on this point), and catching public attention to them. Still, in the way it is currently defined, a widespread acceptance as a replacement for email remains doubtful. More precisely, this progress remains incomplete as compared to what could be done, as I had already envisioned years before. But, once extended with further major innovations, it can finally indeed become the really successful replacement of email, and more than this, the new foundation for the Internet of the future.

To implement this, as I'm not a programmer, I'm looking for programmers or organizations willing to make it. I'm not looking for money nor trying to set up any business for myself, I'm just trying to freely speak about innovative ideas for free software creation.

If you wish to work on it, please contact me.

You can see here the details of the « Trust-Forum project » I had already envisioned way before Google Wave came. You will see important similarities. (You can check with that it was already there before)

Of course I had not envisioned all details of Wave. One reason for this, is that this description I made was already quite more than I could dream to get a programmer doing in the short term – and I hardly got anything done. At that time, fancying more of what Wave finally did, would have been mere utopia. On the other hand, some other details I wrote about, even for the conversations part itself, are still not done in Wave. Also, the technical method I considered for sharing conversations between users of independent servers was radically different. I think, it would make sense to finally let both methods work with the same data.

Another, shorter account of my ideas on the limitations of Google Wave and my suggestions of what to add to it, is here. (When I wrote this, I did not know yet that the programmers I had contact with, were giving up as it would be too hard for them. Yes, it's not a very simple project, but what remains to be done until a first real success, won't be harder than what has already been done with Wave (not mentioning some longer term vision of developments such as trust system and online money, which may admittedly be harder than this). So, if Wave could be done, why not these additions too ?)

For a new global identities system, better than OpenId

Google Wave already offers the possibility that. This way, users not locally registered, but only registered at independent peer hosts, can participate in a discussion. This way, pieces of text in a site can be authentified as coming from a user of another site, with no need for this user to create another account locally. This is good for discussions. However, there is more to do across the Internet in an authentified way, than standard discussions: it is normal for each of many independent sites to offer different sorts of services, or to let people interact in its own different, unique way.

Life would be simpler and better structured if users could just keep the same identity for all sorts of uses and operations across the web.

See my project page for details

This would solve the traditional defect of so-called social software that in fact divides people rather than unites them, as it can only connect users who have account in the same site owned by a big business, which needs to become the Master of the World in order for its official wish to unite the world, to become true; otherwise it forces every user to have virtually as many separate accounts as friends he wants to connect to.

Here is a random example of an article found on the web that points this lack of a general integration, in the current conception of Google Wave.

Excerpts of remarks by Daniel Danopia (author of Ruby on Sails):

Wave needs some way to handle large amounts of data. Imagine a wave that all 1500 users from freenode's #ubuntu channel joined and used. The channel goes by at 15 messages per minute on a slow day (i.e. now). (...). If I opened Wave for the first time in a month and saw 1080000 unread messages, I'd shoot myself. Plus imagine how badly my browser would flip out opening that. Assuming that the chat was used for 6 months, you've got 6480000 blips. In XML/XMPP format, where each new blip is about 150 chars long, the history of the wave would be 972000000 bytes. That's almost a gigabyte. This is also assuming a low-strength cipher and that each line is a single "delta" with no letter-by-letter. If I add a user on a different server to that wave, there is no way for the other server to only get the latest hundred blips. It would have to transfer the full GiB of data before the wave would be useable.
Wave works. It just won't replace every other form of communication that exists until it's fine-tuned.

My reactions:

Need for anonymity – so what about user pictures ?

There is a need for anonymity when participating to a conversation or any other interactive system. But even more, combining the use of one pseudonym with the benefit of a certification of the trust received from friends under a different pseudo, would be extremely useful.

And, as paradoxical as such a combination may sound, it can be done: having one login/pass for using several pseudos, without anyone else than the system administrator knowing which pseudos belong to the same user. The trust connections and the data of which pseudos belong to the same users, just need to be kept secret and used for the precisely needed computations operated in the database of the user's host. See my project for details.

But, in the way Wave is now displayed, all users are displayed in the form of their picture. For anonimity to be possible, there needs to be conversations with a display of user identity not including picture. OK, it is classical for people to appear pseudonymously in forums using an avatar that is not a personal picture, but a drawing, an animal or anything else. But...

Interfacing with the old email system – no need of a mailbox for wave users

I read that the current idea of Google Wave for a conversation between a wave user and an email user, is to send blips by email, and to receive the contents of email replies as replies to the wave. This destroys the diversity of ways to contribute to a wave (inserting replies inside a wave and not only at the end).

I will here suggest to make it another way, based on my idea of global identities system.

The communication with non-wave users could be obtained by extending the diversity of user types: connections of users to a site A can have the following status

local users (user@A)
remote users (user@B)
anonymous user (read-only mode)
anonymous remote user (read-only mode but with possible interaction with user's home account if user has open session at his home account)
email users (user@email-server)

An email user, defined by an email address, can be invited to a wave.

Every addition to the wave will be sent to the email address, together with a link with key for the user to visit the wave and contribute there. Remark: sending additions in a wave to an email address can't be done letter-by-letter ;)
So, Wave servers will have the possibility to send emails, but not receive any. Instead, email users, not yet registered as a true Wave users, will discuss with Wave users in Wave mode, and be notified for any update in email messages.

As for initiating a conversation, a form on a web page can be made, for a non-wave user (with email) to contact a wave user, that will create a wave between them, working as just explained.

User groups, or threads / multiple-pages displays ?

Some say there needs to be a functionality of making groups of users, to replace the functionality of a mailing list.

Indeed it may be fine.

However, for much of the same purpose, another solution may be considered.

The first Wave approach to groups, as a replacement to mailing lists, would be to make one single wave for exchanges inside a group. However, people say it's not enough, because people may need to do lots of works on different subjects in the same groups of people. And the problem is that if there is too much work on different subjects, then it makes a tooooooooo long wave to display.

Thus, just like a forum can have multiple threads to be displayed separately, we could consider making a sort of big wave (let's call it a tsunami ;) with a common list of participants, but containing multiple threads, to be displayed into separate pages.

This structure may impact the user's folder system: a tsunami could be seen in the user's inbox as a folder, but it would be a collective one. The user could be free to :

On the one hand, click on the tsunami to display it collectively is, a list of threads

On the other hand, he could manage the list of particular threads in it, for a personal ordering in his folders, to see what is there new in the specific threads he wants to follow.

Using a Wave Inbox to Include Anything Else than Conversations

If you understand well what was my solution for conversations between people with accounts at different servers, you will notice that once the new protocol doing that would be widespread, the exactly same New Wave server, could be used without any further modifications, to include in your wave inbox, bookmarks and updates notices for absolutely anything happening anywhere else on the web (example : online markets), instead of just conversations.

Ending the Spam Era

Even before developing the trust network, the end of spam can be obtained quite easily.
Spam protection won't be based anymore on contents analysis, but on senders identities.

Just don't let new users register a home account to a server without invitation by an existing user with home account to the same server, and declare the rule that every user should take care not to invite spammers.
Then, every system administrator tracking the invitations tree, and receiving spam notifications, will be able to find out which users are responsible for inviting spammers, and block their accounts and/or their possiblity to invite more people to register.
A similar invitations system needs then to be done between Wave providers.

Are Letter-by-Letter Updates Too Much ?

When reading the many comments made through the web about Wave, this remarks comes very often : letter-by-letter updates are often perceived more as a trouble than an advantage. When someone starts to write a message, it can be disturbing to know that others are seeing every hesitation, and may even understand or misunderstand before the sentence is finished, and reply to it immediately.

It is said that this functionality can be disabled by the user at will. But still, it seems to me doubtful to let it exist in the first place.

A deep logical problem I see is that: as I understand and I think would be right, the whole communication will have an history, where everyone can find out what was written by every user, and at what time. This will be especially useful for the trust system (see below). So, every update should have its own time and signature. Now, how can this be done letter-by-letter ? Will every written letter have its own time and signature ? In such a case, the stored data will be hundreds of times heavier than the contents; otherwise, the history won't be accurate. To make the history data both accurate and of reasonable size, larger pieces of texts than mere letters, are necessary. Indeed, this is already what is made: I got this explanation from Daniel Danopia on how Wave actually works:

The sandbox doesn't store a complete applied delta for each letter; this would be insane, because here's a sample packet: (...something very big) One of those for each letter would be insane. Instead, it adds each letter operation to the same delta and only commits the delta to persistant storage once the user clicks Done. This way you get less fluff stored. Each of those packets is transmitted for each letter in live mode, though.

Here is my answer:

Then, imagine : a user A starts writing something. As he writes, a user B sees what A started to write, and writes a short reply immediately. This may be because of a misunderstanding of what A meant, or maybe A was hesitating on what to write. Then B clicks Done as a finished reply to what A started writing, while A was not done yet. Seeing this, A still does not click Done. Instead, he deletes the words he had written, which B had replied to; and writes something else instead.
Finally, the conversation, as stored, includes a reply by B to some words from A that we have no more trace of, or looks like a reply to a different sentence than it really was.
In my opinion, this is a problem.

Read in the comments here: « Already I can see some flaws in its design which might make adoption difficult: the federated OT process they use for the concurrent character-by-character document editing is non-trivial and deterministic. This means that every implementation must be using the same algorithms always. »

What about drafts ?

When messages are not published letter-by-letter, are they saved as drafts before they are Done ?

So, here is how I think it should be (I did not check how it is now yet): a draft is to be read only by writer; while private blips are to be read by writer and only one more participant; it can be later edited, deleted or Done, without letting others see an history for them. This is a function that I had considered and that had been precisely implemented in my project, so you can see in its user doc (section « save, preview, post ») my thoughts on this. It included the following innovative feature: a text already sent (Done) can later be turned back as draft without trace as long as nobody else saw it. This also lets the author know whether his message has been read or not.

Precisely, regular automatic draft saving (that may be anywhere from immediate letter-by-letter, to every minute just like now in gmail), would be fine.

When Faster Means Slower

Now that I did try using Wave, I can tell about some troubles.
OK I know it's just beta now, maybe future updates will solve this problem, but...
I see that the browser is so busy updating the page several times per second, that this uses up all computer resources, which leaves it no more resources available to react to the user's requests.
Thus, for example, if I try to write in a wave, typing 4 letters per second, then my work is seriously slowed down by the fact that the Wave system is saving my letters one by one, and making another update of the whole page every time. The result is that my letters only appear to the screen at the speed of about one per second.
This makes it very impractical to write anything in Wave, and it makes it necessary to run an external text editor to compose a message before copying it into Wave.

Problem with how the spell-checking works

Daniel also explained me the following:

Spell checking currently only exists as a robot/agent. This means if there is no char-by-char, won't have a spellchecker for you. If your internet starts lagging, you lost spellcheck.

So, unless a spellchecker is implemented on the client side, an idea to operate it on the server side without displaying to all participants in real-time, would be that it acts on the saved draft. Somehow as if it was a private discussion with the spell checker. But as this is basically a different idea from the idea of a private blip to someone, it should be technically independent too. Namely, the interface shoule not say « private reply to the spell checker » and it should work in true private replies themselves too. By the way, in the current system, if a spell checker is just a participant like an other, does it work in private replies ????

I don't know whether such methods can be done as just a normal extension of Wave, or if it requires the process to be integrated in a deeper way.

Ping : maybe not the best idea as such

The role of Ping is to inform a user that one wishes to start conversation. It operates by making a pop-up appear on that user's screen.
So, what for ?
To "force" that person to start the conversation immediately. Starting the conversation, means to read and to write now.
But, maybe that person is busy now ? Maybe a pop-up can be disturbing ? What if several pings are received at the same time ?
Basically, Ping is not necessary: one can start a wave and invite someone there, so that this person will enter the wave and reply there, the next time he will look at the inbox.
So, doing more, can be useful for the case when one needs an urgent reply, maybe because one is online now to chat but later it would be too late, and the reciever may not be paying attention at this time.
Yes, but:
(I did not pay attention if this is already done: to be usable as well for starting a new wave than for requesting to come back to write more inside an existing wave ; Indeed, one may wish instead to ping a user to come back to an existing wave)

Also, more often, it can make sense to expect an urgent reply, only once the motive/question has been written. This may be a short one, to write in the title of the ping to display in pop-up, but it may also be a longer one. Anyway, if you first send a ping and then expect the receiver to accept to create a new conversation, you are wasting a few seconds waiting for this reaction, until the wave is created. And, in these few seconds, you have no place to write more what you want.

So, if it is very urgent, it would make sense that the sender first creates a wave with its title, adds the person to the wave, pings that user, then starts writing more inside the wave. So, when the reciever arrives to the wave, the first message is already more or less written in full.

If it is less urgent, then, no ping is needed. The receiver will see and come when it is convenient.

Then, let's consider the problem : how to attract a user's attention.
The basic way of doing, as is now usual with email, is to do nothing special to attract attention, but to have the title of the new message appear in bold in the inbox, together with all other unread messages. This is seen only when the user sees the inbox. Is it possible to do more, but still less disturbing than a pop-up ?

I remember using unix terminals in year 1995-96. In a corner of the screen, there was a little drawing of a mailbox. It just gave a binary information : it appeared as black lines on white background if there is no new message, but becomes white lines on black background when a new message comes. And together with this, a big BIP was ringing at each arrival of a new message.

Why not do something similar ? For example, have a little corner of the window, that may be text or picture, display a special color or blinking text or picture to mention the arrival of a request, and/or make a sound, depending on how the user configured the way to be warned. This could be sufficient to invite to the conversation, yet be less disturbing than a pop-up.

To be more precise, we can consider the question to be asked in a more general form: How many degrees of priority shall we define, to classify all updates and any thing that happens ? how to determine the way each event is classified there ? and what form will take the display of a signal of every priority level ? It may depend on many free options by the "sender" and the "reciever".

Maybe Wave is already complicated enough ? Well, things need not appear complicated to start with. We may let things be presented in a simple and naive way at first, then let users add more option if needed.

How to manage links between waves or from a web page to a wave, through the federation protocol

Now it's a bit uneasy to get the link to a wave, except if you want to just put it in another wave.
But, how will be managed links between waves through the federation protocol ?
And what if you want to insert a link to a wave inside a web site ?
With the global authentication system I had envisioned, it would have been obvious : links to public discussions would remain valid as such, keeping the user authentication regardless of where he was registered in.
But with the current Wave solution where users need to drag all discussions of the world to their own Wave provider to be able to read them and eventually reply straightforwardly, a link to a wave not hosted by the provider of the reader, can never work.
Unless of course, you add complications to convert any link to any other site, into an internal link inside your Wave provider. But this would only work inside waves, not in any other web pages willing to link to a wave.
So, you'll ultimately have to release a new browser with the wonderful new feature of being no more able to connect to any different site than the user's wave provider, in order to address to this wave provider any request of visiting something else on the web, so that this wave provider will serve as the user's Universal Proxy Server.
No, seriously, you should rather consider implementing my solution instead.

Rights system

The rights system currently working in Wave is insufficient (each wave having a simple list of participants, and nothing else). OK, this was but a first version to try, and it remains able to be changed into something much more developed in the future. Anyway, you can also go to see the ideas I defined for this in my project.

Especially, to make the difference between reading right, writing right, and editing right.

Why a Diversity of Page Formats is Necessary : wikis, blogs, directories...

Currently, there exists only only one type of pages in Wave: a wave itself, with a very specific, universally stardardised and highly complex set of features. This is not the right way of doing things.
In practice, a diversity of page formats is necessary.
The same space with its list of participants, should be able to contain several display pages, to be viewed separately, without overloading the browser with the whole contents.

Each display page, and even each subset of a display page, should be able to have a different set of features.
Already, there are subsets for private replies with different lists of participants.

But there are other situations where diversities of features is necessary.
For example, if you consider a blog, you have an article which is not a discussion space, but that only the author can edit; followed by a comments space where anyone can add a reply.

Now, there is a big problem with Wave: the list of public waves is very big, so that it is hard to find what you are looking for there.
For this, but also for the whole web, there needs to be an open directory project. You probably know
Its development is hard because not anyone can add a link, only editors with some experience can. For some aspects it is good like this, in order to avoid spam. for some other aspects it slows down its development. This way it is less open than, for example, Wikipedia.

Now, we need a better order between waves than the mere power of an automatic search function by keyword.
This requires to make a sort of big wiki directory, to make lists of public waves, which can extend in the long term into a whole substitute for  In order to be more open than, any people could be free to make his own list of links. The problem, of course, is that if everyone makes another list, this is not manageable (too much work for every single person) and won't reach any coherence. So it needs the possibility for many people to  contribute to the same list. So, to make lists as sorts of public wikis.
Also, one possibly can't pretend to reach an agreement between everybody, on what to include in a list.
For this reason, independent lists for the same purpose should exist too, then different lists would compete for popularity among authors of meta-lists, and so on.
Obviously, a directory is not the same as a conversation. It can be presented as contents of a wiki, or follow other standards. This is why it is necessary to allow for a diversity of formats for spaces.
In order to work well, a good trust system for avoiding spam would be needed (see below about trust system).

Then, we come back to the initial remark: if we don't want one big format but a diversity of formats, it should rather be approached not as one project but as a diversity of projects. And in order to turn a diversity of projects into a coherent role, and not be trapped in any backward compatibility troubles, then the right way should not be to focus on providing "the solution" specifying everything in a unique, universal standard, but rather on providing a meta-solution, that will let independent groups offer competing specific solutions for every specific purpose, while users would stay free to pick up any number of solutions given by independent providers, to satisfy their many needs. And this meta-solution is the global identities system I mentioned.

Is the Wave team able to communicate ? and How To "Think Big" ?

There is no good way to communicate with the Wave developers team, except probably if you already had a Wave invite, to communicate by waves.

I tried to contact them in many ways since October, but they never replied.

They were coming across Europe.

I followed the link to the web page about the Zurich meeting.
There was no possible contact means on that page, which is directly hosted by the Google Wave servers. The only possible action was to register. The field "What languages are you programming in?" was required. So, the Wave master team is only looking for benevolent slave programmers to obey the general predetermined format of google wave axioms, and to add more robots to serve this format.
They are not welcoming any free thinker to raise questions about where all this is going to, nor to suggest any further major innovation than those already decided from the start. Or maybe, in the programming language field, I could put: "Other : free thinking", but I was afraid to not find there anybody else who knows about this language.

I read on this blog : « Lars on video link says to budding developers ‘please think big’, think ambitious, big and meaningful about how to use this program, platform, protocol. ». 

But, developers are not used to think big, especially for inventing new uses with a system they are just discovering, that they did not imagine before. And because it is not often the job of developers to think big, but rather to make little improvements to existing systems. 

But why did he only request developers to think big, and not exepect any other people to do so instead ? Why should big thoughts and small lines of code have to be produced by the same people ? Just as if one requested a public of individual engineers to invent the best instruments for making the next big scientific discoveries. It is the normal job of programmers to think small. But the prosperity of this world largely comes from the division of labour, by which different sorts of problems can be more properly managed by a diversity of professionals, some working on details, others on global strategies.

There is another site of Wave, where people can input ideas, and vote for other people's ideas. But this only lets the freedom to propose very simple suggestions, that can be expressed in one sentence, that the Wave team would then gather and possibly implement for its own credit, without saying thanks. They don't seem to let room for expression of complex ideas, for real discussions, and for considering any further truly major innovation. So, they pretended to invite people to think big, but did not let them the place for it.

They seem to insist to stay the masters and exclusive fathers of their projects, and to treat anybody else as children and/or slaves.

So, at first, for a time I hoped it would be possible to just reorient Google Wave to integrate the functions I considered.
Now, for lack of answer from the Wave team, and their way to only call for programmers to comply to the general structure already defined and add more line codes and robots to it, I'm having strong doubts about the possibility to have such a deep reorientation done.

Can More and More Additional Robots and Gadgets Be The Ultimate Solution ??

Furthermore, their request to "think big" is somehow paradoxical. It is a sort of request to think big inside a cage. Concretely, they seem to assume that the general principle of creating more robots and gadgets to invite to waves, will be the main way to add any further innovation or solve any problem. 

Example: as an answer to the multiplication of empty blips in waves, they create a robot "sweepy" that will delete all empty blips. why did the empty blips exist in the first place ? So, they like to see the system do things wrong in order to display the magic of how more invited robots can put everything back into order. OK, this may be one of the worst examples of what a robot can be useful for, and I understand there are much more meaningful optional robots than this. But, still...

Problem: at the end, any small conversation between 2 people will require to invite many robots or gadgets: one for spell correction, one for empty blips, etc. As these robots need some deep rights of editing the conversation to do their job, this raises important security issues: imagine someone invites a malicious robot, that may or may not masquerade as another more usual robot. One more robot inside a long list of necessary robots, will remain unnoticed. And if it is a malicious one, it can create troubles.

I consider nonsense the current situation that bots are just treated as equals to humans. That they appear in the list of participants to a wave together with human users. That they appear in users'contacts list as equals to humans. I don't believe that this kind of mixing can go very far without raising a lot of troubles in the long term. So, even if access rights may be similar in some respects, I consider that the difference needs to be made, as it will surely be useful sooner or later. First, it should be visible, with separate lists of humans and of robots in waves, as well as in contacts. Otherwise, for example, if there is a poll, can robots cast their vote ? LOL
Of course some exceptions to the human/robot distinction rule can be considered, for example if it is for the sake of organizing Turing Test competitions ;).

The problem is in the right to edit other people's texts, and the risk to let this unnoticed. Basically, I'm afraid about the possiblity for a user to edit another user's text: even if it lets a trace (the mention of several authors for a given blip), and if history can show who wrote what, this possibility to distort or erase someone's words can be considered impolite and/or confusing. Well, I think there should be different sorts of communication spaces each for different uses, with different sorts of options: some where users can delete other users'texts, others where it's not possible. Anyway, I consider that the attribution of every modification to its author should be visible, but not necessarily in the same way: if it's to collaborate to a document, it makes sense to let a user edit or delete another user's text, and to have an option to see the result without the indication of who did what, in order to be more cleanly readable. If it's for a conversation, deleting other's texts should not be possible, and the indication of who wrote what should stay clear.

Now, there are some spefic reasons why some robots should be able to edit and eventually delete parts of some people's texts. Well, I see this as a security issue to address. For example, there should be special certifications for robots (an editing licence, just like a driving licence ;-) and/or an explicit acceptance by a user to a robot for editing his messages in a wave. There, there is no reason to let humans and robots the same rights.

But many more issues, and especially the "big ideas" may not find their proper solution in the form of "one more robot to invite", for a diversity of reasons. Example: it is very nice to have a robot to replace tex/latex code of a formula into a pretty display of a formula, but what if you want to modify a formula after its conversion ? Especially, what if a formula was converted by accident before it was completed, for example if two $$ appear in the wave with no intention for the second one to mark the end of a formula started with the first ? Ah yes, you can search for the initial code in history. Well, only if you are lucky enough to find it there.

Some improvements may require completely different works in the core of the system or outside the contents of specific waves. In some cases, it would be more appropriate for the user to browse other hosts directly, as I explained about remote user authentication.

How it can be made : Extending the Wave Protocol ?

If the Wave team won't do it as a part of the Wave project itself, an independent team or organization could do it instead, starting from the open code that will be realeased by the Wave team.

It must proceed according to the same scenario (which was already the scenario I had considered before knowing about Wave) : offer the service to some users on the one hand, release the code open-source on the other hand, for other people to implement independent peer sites to work in network with it.

All peer sites would include these new functionalities (and will be free to add their own further functionalities), would work together according to a new protocol, that would be an extension of the Wave Protocol.

Still, communication with servers working with the mere Google Wave protocol would be possible as well, except that, of course, these connections with « Old Wave servers » would not offer the additional functionalities.

But, I'm afraid that the protocol development has been done in the wrong order:

If it had started with an identities protocol (global login system), it would have let the freedom for a diversity of propositions for discussions formats, to be developed in parallel and to compete for adoption by users, by the users'choice of which remote servers, other than their home account servers, to discuss in. Long after, the most popular discussions systems could be formalized into a standard format of data to add to the protocol, to let users operate some discussions directly on their home server, without remote user authentication.

Now, Wave started with a protocol that fixed a format for discussion data. I'm afraid this may be an obstacle to the development of this project, because, well, fixing the right standard to start with once for all, before any public release, and expecting the whole world to follow this standard without modification forever, requires a huge deal of luck and professionalism. Or it may just be foolish. Otherwise, how can this format further evolve without raising big compatibility troubles ???

How to remove a participant from a wave ?

This is a theoretical problem: how to define, without contradiction nor raising more problems, a proper answer to the question of how it should be possible to remove a participant from a wave.

Already, it is possible for each user to resign from participation in a wave.

Let me bring some more suggestions:
In my initial concept, there was, in increasing order of access rights to a wave, after reading right and writing right, an admin right, that precisely consists in the ability to decrease or remove the access right of a non-admin. The first admin of a wave was its creator, then possibly more people could be invited to be admin too, if the wave turned out to be big.

More ideas can be added:
-  To let the invitation of a user to a wave, not be immediately effective, but only after some minutes or possibly one hour, so that the operation can still be cancelled in between, Or, in case of emergency, it would be possible for the invitation to be immediately effective, to involve a confirmation form.
- Still after this, the invitation could be cancelled by the inviter as long as the invited person did not visit the wave.
- Exclusion of a user need not be global: as the user may need to keep trace of what he already saw, this display can remain available to him. This would be a "dead access" to a wave, that is a read-only access to the version as it was when the exclusion happened, with history only browsing from the wave's creation to that point, and with no right to see the further updates in the wave, nor to write anything more inside.

By the way, is there any trace of who invited who into a wave ????

On the problems of innovation and public attention...

While, by principle, the freedom and anarchy of free software development is very nice, it may raise a few organisational troubles in practice: the general habbit of free software development just operated by programmers as they feel like doing this or that, has some limits. This is why the evolution of the Internet, and even more of email, has been relatively slow for many years, and that thousands of software projects were made for nothing, while no developers ever worked on my ideas (while I could convice most of the economics students I debated with concerning my political ideas, but they were not programmers and thus could not directly help): it was very far from what they had in mind to do. It is a common temptation for everyone to think small, which is why email stayed nearly the same for a so long time, and why it took so much time and effort to invent Wave and to force people to pay attention to it and understand what it does, not just as « a new email system » or « another instant messaging service », but really a different idea. It may be time to change habbits.

Google Wave is now very famous for being "very innovative". Yes, as compared to already implemented codes it can be called innovative. But what is truly innovative there is not the idea, which is but some variant of a subset of what I already imagined before. What is new here is to have all the Google's resources in developers, money, technology and popularity available to make it "exist" from a mediatic point of view: by such means, to have obliged many people to consider the idea seriously. Because a general problem is that, no matter how good a project is, and how convincing are the arguments for it, hardly anybody ever bothers more than a few minutes to imagine, to discuss, to tell other people about, and even less to work on, a very different concept of a system from what has already been implemented. Any idea really different than what is already done is rejected by most people as a mere utopia.

Now that the first step of the utopia is seeing the light of day, let's hope it will be possible to go further.

For a universal dating system

I have plans of how to make a new online dating system that will be by far the best one of the web.

I made a first first version of the specifications some time ago. More recently, I started writing a new version.

The reasons to choose a context similar to that of Wave - and more precisely the one of my project, to include this online dating system, are:

It is a decentralised infrastructure that potentially all Internet users will use for other reasons, without being slaves of any central business; this gives every user the opportunity to contact any other user in the Universe that may fit, without any need to try repeating the search in several systems, because all Internet users will naturally be using the same network;

Meanwhile, and even though this sounds paradoxical, this environment will respect a great deal of privacy : the global list of all dating users in the Universe won't be public, but each particular user profile will only be accessed when needed to that user's matches;

Any user can start using the dating functionalities with no need to create a dedicated login/pass;

The trust network functionalities that can be developed on the system, not only involving people interested in online dating, but connecting all internet users, can later be used to secure trust here;

Once dating matches are found, the goal is to start conversations. There is no reason to have such conversations separate from the rest of the user's (non-dating) conversations, nor using any different technology.

I will reserve the full new description to the future team that will be ready to work on it, after an agreement will be found and they will will have started to work on other aspects presented here.

For moral and philosophical motivations to care about online dating, see here.

On the usefulness of Waves for an online trust system

How something like Waves, or my project, will be a necessary tool for a proper trust system:
Just imagine.

People connect online, to prepare a transaction of any sort.
They discuss the terms of their agreement in a "wave". Each needs to have reliable (even if anonymised) identification of the other, to know what trust there is supposed to be between them at the start.
Then they process their transaction.

But one of them betrays. The other complains. So he invites to the wave a "gadget" (following the Wave's vocabulary - I think this would be more appropriate than a robot) of trial, to process the complaint.
This robot invites other people to the wave, starting with those that declared trust to either of those who disagree.
Each newly invited person can access the whole history of the discussion, from the start, so as to reliably find out what the terms of the agreement were, and how they were broken. Then, ifever things are not clear, they can write further questions to the people involved in the discussion, so that they can reply in the discussion, and explain the reasons of their disagreement.
All participants can form their own opinion about who is right or wrong. Someone invited to the discussion, who choosed who he agrees with, types his judgement to the trial robot (in a similar interface as a poll - but letting people the opportunity to change their mind).
So, this robot accumulates the data of who agrees with the one, who agrees with the other - which is called "parties", and takes account of this data to process further invitations to the waves, and to force the trust connection between disagreeing people to be broken.
This is processed until it cannot find any more person not yet invited who would trust one of both parties.
This party, with no more outside person trusting a member of, is "discredited".

For a more general an theoretical presentation about online trust systems, to understand the global trust connectivity this may build, see:

Infoliberalism : the general theory

A more technical description of the logical rules

Other existing systems or projects similar to Wave in its current form

Open source Wave federated projects :

PyGoWave : an open-source Wave implementation in Python ; needs more people to work on.

Ruby on Sails

.NET open source implementation of Google Wave

Moodle, an open source environment for education, is going to interface with waves, as Moodle Wave

This blogger reports to have successfully installed and federated the official Google Wave code on Ubuntu.

Copyrighted, for business:

Novell Pulse, also still under development, will be interoperable with Wave through a partnership of Novell with Google.

Mingle (Agile project management, by Thoughworks Studios)

Open source more or less similar systems (not wave federated):

Mozilla Raindrop (for a similar use in the short term but I don't believe in its underlying concept as a solution for the long term)

Copyrighted similar systems :


Lotus Notes

Nurphy (see article)

Other (?):

Facebook Graph

(I'll complete this list as I'll find; if you know more Wave implementations projects, preferably open-source, even at an early stage, you can write me and I'll add it to the list. Thanks)

Useful tips

It is now too easy to unwillingly add a reply, by a wrong move.
If this happens, just remember: while you are doing so, you just need to press ESC to remove your blip.

The most devastating trouble in Wave

Sorry I can't resist quoting the following, found in a wave:
"GAH! I accidentally deleted half of this wave, by accidentally selecting a large amount of text and then pressing a key. I managed to restore the main body from playback, but it was not trivial (and I lost some replies - permanently, it seems :-( - they're no longer in the playback). Can't wait for UNDO... "

Interesting Waves

List of shortcuts
Terry's thoughts and impressions part I - Part II
The official wave : "Wave Bugs, Missing Features and annoying things!" - sorry I did not get its link because it's uneasy to get the url of a wave unless you already know another wave linking to it.
Wave's greatest hits

Other interesting links and criticism

Complete Wave Guide wiki

Google Wave first look

Another introductive article

Wave rider : anticipating google wave. Some thoughts on the future of Wave

Not a good html editor

On the top of the wave

Geeks Try Google Wave, Have Mixed Feelings

5 Reasons Google Wave is Not Ready

Still some ripples in google wave beta (september 2009)

Contacts / Comments

My email : trustforum at gmail com.

To express yourself publicly in a forum you can go there where I started a thread « beyond google wave ».

The Google Wave users can also discuss this in this public wave.

My homepage