"Jack of All Trades, Master of None". This is a common assumption.
What I agree on is it didn't meet expectations in in it current form
was not usable (just because seasoned users can use it in chrome
doesn't mean it is usable, seasoned geeks aren't always the best
judge), and was essentially always going to fail, because it was a a
rough diamond, and largely entwined in a subculture (firefly).
Although that was sort of an in joke that was really at the heart of
the issue. There isn't another Google product I can think of that
doesn't have in the name what it is for. The team were naive in
thinking that it would somehow magically find it way, and they should
have had help developing into a nieche implementation and directly
targeting a specific type of use. Only then can you build on that. A
wize person once said ther is no such things and the "mass market".
You have to start somewhere.
However Wave as a concept isn't so much a replacement email. it is
more significant than that, it is more on the level that the internet
is in relation to the telegram. But a lot needs to be worked out
"Wave" should not be uttered outside circles developing wave service
or client. That isn't relevant to the user base. What is important is
it improves the way they do things. There need to be an intuition to
using it, but an enhancement as well.
Another reason why it failed is ironically it was limited by it own
freedom. It is typecast into a use which at worst is dubious because
of the limited Access Controll. However I also agree that just putting
a bunch of arbitrary AC setting could actually make things worse,
because you are potentially limiting how it might be used in the
I had some really blue sky ideas public via proxy with publishing
agents, etc to try and provide a more ad hock approach to what wavelet
interaction actually means for a user. of course this is not a trivial
thing, it has to federate, and federate simply without without the
need for stipulation, and also it can't afford to be too slow for the
users. Also how much to do on trust? One the idea to speed thing up is
to have distributed agents, which would be a condition of publication
for that federation (there can only be one PvP agent added by whoever
creates the wave), in other words if someone doesn't include that
publishing agent they can still federate with that service (that uses
publishing agents), however the service doest have to publish it in
whatever form, nor has to take pride of place within the concept of
that wave service concept. Publishing agents allow wave to be
meaningful within a specific context. because users do actually have
certain exceptions within a specific context and it is not always free
for all. if a service provider, doesn't distribute in good faith, then
you can always decide not to federate with them. Publishing agent
versions could have a checksum. The original issuer may chose to
update and this will be distributed to replace the existing agent
version. Perhaps a more egalitarian or flexible way needs to be worked
out in some instances.
RPC is all well and good. But you may want to be able to distribute
something that will run as an agent for the wave in a sandbox
environment, it takes the weight off a single service provider, and is
faster for the participants.
How do you decide what form this would be distributed in. Well it
distribute an "agent" of the app to the client (browser). So it is not
really that far removed to distrubute agent to wave providers.
Some agent don't need to be distributed such as "spelly", that is a
luxury or considered part of the interface. However the idea of
publishing agents is as above make sure interaction works as expected
for that context. This in itself will increase the use cases for wave,
and the inflexibility born out of freedom has definitely been a
stumbling block of wave.