Hacker News new | past | comments | ask | show | jobs | submit login
Apache Wave on Sandstorm.io (sandstorm.io)
142 points by srpeck on Aug 20, 2014 | hide | past | web | favorite | 45 comments

Wave was a great idea that was completely misunderstood. Unfortunately, it also seemed to have been misunderstood by the people who designed it.

Wave was supposed to be a collaborative replacement for email built on the then-exciting XMPP protocol. It was marketed poorly, misunderstood, and eventually shitcanned because Google had no idea what to do with it.

The web client wasn't good enough, too. It would start lagging at ~200 posts which wasn't that many in an active multi-threaded discussion between three-four people.

Which is a shame because I liked Wave a lot.

Agreed. I liked the idea a lot and enjoyed using it while it lasted.

The lag sucked, though. Just when the discussion would start to get interesting, it would slooooowwwww dowwwwwwn.

What was exciting about the XMPP protocol itself? Were people back then just excited to be in the presence of vast amounts of XML?

I mean, that'd explain a lot.

I felt like Wave very closely approached something useful in this space, but almost anything in communications is interesting when you have another person to talk to, and very little is interesting without one. That makes it very hard to judge if the platform is helping or not.

The hype was that XML was solving the problem of knowing how data was structured. So you could send someone a message, and if you wanted to include a vector image you'd just embed an SVG. If you wanted to send equations you'd just embed MathML. If you wanted to send a Warhammer army list, you'd embed that XML.

The messaging system wouldn't have to individually add support for these things - it would just use XML schema to validate anything that got passed through. Data could come with XSLT to explain how to display it (i.e. your warhammer army list would come with a transform that told wave how to turn it into XHTML for display) - but the source data was still available in machine-readable form, with a canonical schema defined by a URL - we could have a single canonical format for everything, even things like addresses, and then rather than defining their own address type, any more complex data format that needed to include an address would just say "embed the address element defined at this schema".

It would work in the other direction too. Rather than fetching a wikipedia page, say, or a blog post, and getting a bunch of unstructured HTML, you'd get the article source in XML format, and an XSLT that said how to display that as the web page. There'd be no need for separate "web API" endpoints to fetch data in structured form, because every web page would simply be that structured data, plus a transform to render it as XHTML.

It was a glorious dream, and one that resonates even now. To my eyes the main - perhaps only - reason it failed is that XSLT turns out to be a horrible language to write and even more horrible to read, to the extent that even for transforming XML-like documents - literally the sole design purpose of XSLT - I'd prefer to use a general-purpose programming language, or even, shudder, Javascript. And people did.

Well XMPP is still an exciting protocol - you can pretty much transport anything over it, with federation built in automatically. Basically, if you were using XMPP on anyone's server (even one you stood up) you could talk to any other XMPP user. Google stood up Google Talk and became the largest userbase of XMPP. Facebook also uses XMPP, but they blocked off server 2 server connections. Eventually, Google (recently) replaced their Talk with Hangouts and will be closing off their XMPP service.

Anyways, Wave using XMPP isn't very exciting, but the the thing that was exciting about Wave was that it was supposed to be this system that organizations could install and run internally - plus they could share their waves with other organizations that also were running wave servers. Alas, Google stood up one beta server which got overloaded and they never released enough code in a form suitable for anyone to stand up on their own.

Apache got a copy of what code was released in 2010 and it's taken 4 years for someone to get it to an easily deployable state.

I remember a lot of bloggers such as Steve Gillmor writing about XMPP nearly everyday on Techcrunch Enterprise around 2009. He said it was going to change everything about corporate software. I repeatedly pointed out to him how ridiculous that was (it was just XML, managers don't care about XML, etc) and to which he replied I had my 'head in the sand'.

It was favored among the tech-hyperbole people who turn concepts like 'cloud computing' into meaningless phrases. But that faded away pretty fast.

Unfortunately Google decided to abandoned one of the actual good use-cases for it when the dropped XMPP support from Hangouts (by default), which still upsets me.

> What was exciting about the XMPP protocol itself? Were people back then just excited to be in the presence of vast amounts of XML?

It may sound hard to believe, but yes that was part of it. XML's popularity in the year 2000 was similar to JSON's popularity today.

Even more importantly, though, XMPP provides structured datagram exchange between entities using email-style (user@domain) addressing. This notion is still exciting today.

There was no IM standard at the time. Every provider had their own standard and most of the IM software was not open sourced. Jabber changed the playing field.

Changed it how? Google has since tossed XMPP integration for their whole closed platform Hangouts thing, MSN's old halfway-API-able thing has been integrated into Skype, which is entirely closed, I believe. AIM and YIM are all but dead, at this point.

"Wave was supposed to be a collaborative replacement for email"

Is this the real purpose of Wave or is this the purpose that came out because it was misunderstood?

That was the intent based on the original unveiling.

Unfortunately, Wave was never given a chance to replace anything since it was a stillborn project that barely exited the launch phase.

If anything, we all learned that invite only soft launches on something that is expected to replace a service that is ubiquitous is not a very good idea. Early invitees got in, panned it, and by the time it went live, everyone already had a preconceived notion as to what Wave wasn't.

I think where Google messed up was requiring invites for Wave.

Pretty hard to get people on board when they first have to scrounge to get an invite to something they do not quite understand. Network effect--;

It could have been so big and awesome. I'm sure after a while the speed issues would have been ironed out.

Second issue they had was scalability of the service and I suspect the invite system was probably implemented to give them time to scale it.

On some large subjects with many people contributing the service was practically unusable.

... made even more absurd by the fact that it is a collaboration platform. I actually at the time collaborated on some large, complex documents, but the people I did it with weren't on Wave.

In an alternate universe:

I think where Google messed up was letting everyone try it on day one.

Pretty hard to get on board when day one is just laggy and chaotic. Performance--;

It could have been so big and awesome. I'm sure after a while the speed issues would have been ironed out.

I liked Wave as a Google product, and I like Apache Wave self hosted. I have tried getting friends and family interested in using a self hosted instance, but not much interest. They like Facebook, go figure :-)

That said, a self hosted Apache Wave to small teams seems like a good tool for collaboration.

I did not understand it then and am still confused.

What is this supposed to be - a new workflow? a new UI? a new paradigm to do something? Every discussion or webpage I see about this talks about mail. Is it applicable to any other application?

The end game I think for sandstorm is the equivalent of a rich AppStore/Marketplace for web apps and web services.

Instead of installing an App on your phone. You would install some service on a personal server. Without needing to be a technical person who understands configuring servers.

And for technical users, you can have one-click installs for apps that you know are secure, sandboxed against your other apps and more.

And for App writers, you have an API surface area that makes it easy to do authentication, sharing, etc...

There are lots of things to like here. And a lot of opportunity given how much richer an experience an actual persistent web server can offer over a traditional client app install.

(I am not affiliated with Sandstorm. Just dig the vision, and think that Kenton and his crew are pretty awesome engineers who can pull it off.)

Edit: Re-reading your post, I think you might have been talking about Wave and not Sandstorm :). Whoops. My bad :P.

If you're asking what Wave is, you can think of it as collaborative document sharing and commenting (like Google Docs) but with a different document type that supports threaded discussions similar to many online forums.

Wave also had its own email-like inbox for reading updated documents, and was marketed as improved email but it never really worked well for that.

These days I use Google Docs with commenting enabled for the sort of thing we used Wave for.

Not necessarily dissing Wave, but when I first saw it years ago (when it was a Google product) my first thought was "this is like 4chan enterprise!" :)

What did Wave have in common with 4chan?

As I mentioned in the blog post, one use case for Wave that I personally find compelling is design discussions. If I post a design proposal (e.g. for a new Sandstorm feature) as a Wave, people can comment on individual pieces without the discussion turning into a mess.

Wave is really just a different kind of real-time collaborative document editing that extends documents into discussions rather than just flat blobs of text.

I saw Wave as a wiki that's real-time. Whether wikis benefit from being real-time is an open question.

To me that's what IRC is for. You need a structure in Wave to make it useful as a realtime wiki. That's what etherpad is for and people then copy and paste the content into a wiki page later(etherpad is not good for continuous editing FYI so you should never edit the same Etherpad every day. It's a great way for realtime collaboration but ephemeral. You can also use Google Docs too).

Google Wave was actually inspired by EtherPad and Google ended up purchasing AppJet so that they could have the EtherPad engineers work on Wave.

From what I recall, a few of my friends actively used it back in the day at work, and they claimed it was fantastic for remote collaborations.

I used it for 2 projects at uni and enjoyed it a lot. Then it slowed down so much it was unbearable and we couldn't really discover how far the improvements go. Maybe it would get a better response from general public if the modern browsers / js engines were available then.

Wave was also incredibly popular for doing pencil-and-paper RPGs online.

Wave wasn't just laggy, it was frequently down. All sorts of apps with scaling issues can work better with the Sandstorm model. The whole Sandstorm idea really started clicking for me when I read one of their earlier posts on motivations: https://blog.sandstorm.io/news/2014-07-21-open-source-web-ap...

That made me a backer.

Good read, thanks. Is it possible to run an own, modified version of an open source app on sandstorm.io? As a non-techie user? Like - say - a small modification of Wordpress?

Yep. You could fork our WordPress port[1], repackage it as your own app, and run it on any Sandstorm server.

[1] https://github.com/dwrensha/wordpress-sandstorm

Thank you!

People keep mentioning how Wave would start lagging as you use it more. Is this still a known issue or has it been fixed?

Wave still seems like a solution in search of a problem to me.

neat animated logo

I think you guys are going too fast :)

Wave was a promising idea, but it looks like Slack[1] has become the de facto platform for team communication.

[1]: https://slack.com

Never head of Slack. Their site doesn't even describe what it is.

Slack is a collaborative tool for document sharing and communication.

You can learn more about what Slack is here: https://slack.com/is

IRC on the web with tons of work-relevant integrations. And an easy API, emojis, searchable history, etc. It's great.

It's a HipChat clone.

Except it's 10x better than hipchat in almost every way. Price, funcationality, interop, apis, permissions, etc...

What's HipChat?

Honestly, it kinda scares me how many companies are willing to transmit and store proprietary corporate data over random cloud services these days.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact