Full on, federated Apache Wave

[bb010g]

(Originally at sandstorm-io/sandstorm#730; was told to also put here)

I love Wave and am glad to see it on Sandstorm at all, but I think a bit of the point of it was missed during packaging. Wave was created to be federated—Google knew from the start it couldn't succeed at all if it was just another proprietary Google product. Watch the introductory Google IO talk (01:05:17–01:11:48), and they demo three Wave servers communicating in complete harmony. (Here are some pages about the protocol.) Wave is still at its core a communications platform, not a document editing platform. It's not Etherpad. Dovecot and Roundcube are both seen as communication platforms, and thus kept in their more "monolithic" setups because you don't want a new email address every time you send an email. You want to be able to quickly send a message on the side. Wave is made to work with an open web, and I think it fits very well with Sandstorm's long term goal of ubiquitous self hosting. Just let it be free.

[ocdtrekkie]

You shouldn't have to drag other people running non-Sandstorm Wave servers over to Sandstorm just to talk, though. Also, what about bots, like Aunt Rosie?

I'm not saying this to be dismissive, but I'm honestly curious: Is there an active community using the Wave protocol currently? (I loved Wave when it was Google's and I was a hopeless Google fannerd, I haven't used it since.)

Anyways, it's XMPP-based, which is cool. I think Sandstorm will eventually almost certainly have some form of XMPP driver (drivers in Sandstorm are network protocols, basically), which means at some point it will be possible to support that.

At that point, I imagine one creating a Wave on Sandstorm might be able to interact with another Wave server. I still think the more granular nature (one Wave per grain) on Sandstorm makes sense though, because I may want to sort Waves in with other types of grains about the same thing. It does present the question of how another Wave server would easily nudge Sandstorm to make a grain, or if such a thing is possible, but all of this is very theoretical at this pre-Powerbox stage of Sandstorm, I think. All of this said, I know little about XMPP, Wave, and how the Powerbox works, so I'm mostly just theorizing aloud.

[jparyani]

Thanks for the good response @ocdtrekkie, I agree with everything you said.

Let's table this until Sandstorm drivers are written for XMPP.

[bb010g]

There's an active community in Wave Watchers. Could you explain how drivers work more? Do you have to have a driver for IO with the rest of the web? Also, how do you handle things like wavlets with Powerbox? They're embedded in the wave and the protocol. And as you mentioned, if we're doing federation with arbitrary Wave servers, being able to receive Waves is important. If we stick with a grain per wave, how would federation know which the server to contact?

[ocdtrekkie]

Um, so, Sandstorm apps cannot access anything outside themselves without permission (once all the sandboxing is complete), explicitly, to what they want to access, and it's routed through Sandstorm capabilities via Cap'n Proto. (I am regurgitating this, ask a Sandstorm dev if you want more detail here.)

Drivers are the methods that apps can use to request access to the outside world in a prescribed manner. It ensures apps cannot call home in ways that the user does not expect.

[kentonv]

Some links that may be worth reading while thinking about this:

https://blog.sandstorm.io/news/2015-06-10-network-access-permission-android-vs-sandstorm.html https://docs.sandstorm.io/en/latest/developing/security-practices/#capability-based-usable-security https://blog.sandstorm.io/news/2014-12-15-capnproto-0.5.html