On Sun, Dec 1, 2013 at 9:22 AM, Ali Lown <a...@lown.me.uk> wrote: >> I want arbitrary JSON documents, or arbitrary embedding like we talked >> about a few months ago. >> I want a protocol based on real P2P algorithms rather than the hacky >> mess we have at the moment with trees of servers connecting via an >> XMPP extension >> I want the same fundamental protocol to work server-server or >> server-client. The OT stuff should work like git. > > Yes. Getting the 'Wave protocol' out of the code, so that it can be > further extended (as had been originally intended with Google's work > on the protocol - and their mock RFC) is definitely the best way > forward from here.
Yep. I'm really convinced that those parts need to be separate as well so people can reuse them independently. (And so its not an all-or-nothing sort of deal when people build on top of it all). I also think we should aim to write a proper RFC on the protocol as well. I'm thinking that adding backer's names to the bottom of the RFC might be a really cool kickstarter reward - I know I'd get a huge kick out of that. >> No single person can maintain our 500k of legacy java code. I want to >> write a better version with much cleaner separation of OT protocol and >> application specifics. I still want a web client, but it should be >> written in pure javascript. > > By 'pure javascript', I assume you mean Coffeescript (or similar). I > don't know if JS is really the best approach - or simply because it is > 'trendy' in SV atm. > However, the language choice should be almost irrelevant, compared to > the protocol definitions - as whatever is produced should be easily > implementable in other languages. > (If it isn't - then it suggests that maybe we need to simplify > something else somewhere...) NodeJS libraries are moving away from coffeescript en masse at the moment so we have more consistency in npm. JS (& friends) is the best platform for making web apps for sure, but I'd also like people to make native apps which talk the same protocol without invoking a javascript VM. We could build it in C and compile to JS with emscripten, but the code that emscripten generates is pretty awful. Ultimately I think the right answer is that we have a reference implementation in *anything* - JS will do, or whatever. Once we have it working, we should port it to other languages. I'm consistently surprised how easy it is to manually port working code between languages. >> I don't know what the best way to build (3) is - but I'm more than >> happy to build the platform that a new kind of email could be built on >> top of. Maybe the current WIAB design is totally fine for that part - >> though I want end-to-end encryption. > > This is both the hardest and the easiest of the 3 sections to build. > Getting a 'Wave' system which can act in the same way as Postfix does > for mail, is a fairly simple task on top of the OT/federation tools in > the library described above. > It is then a case of putting a nice client on it... > > This does mean that the target audience for 'Wave' is changed to > developers, rather than us building an end-user product directly, > which is fine, but just something to note. Yeah - having an actual end user product would make the kickstarter much easier to fund, because we can give people something at the end. Another way to structure this whole thing is to make a business which is trying to be the gmail equivalent for wave. Then we could give backers free lifetime usage of the platform or something in exchange for their support. Obviously then we'd probably need to make a client facing product, but if it means we get way more kickstarter money, it might be the right choice. >> I don't know when the right time to do this would be. I don't know if >> I should work alone or if we should put a team together (Hi Ali!). If >> I were to do this properly it would take about a month of prep to get >> a kickstarter together, and if it is successful I'd want to quit my >> job to do it. I think it'd take me about 6 months to a year of work to >> get a stable, secure platform working (probably closer to a year), and > > > Hi Joseph! :P > This is a lot of work for a single person to achieve. It is also hard > for a single person to maintain motivation in one area for such a long > period of time, so I would strongly suggest against trying to work > alone on this. > > My only worry with a KS is how do we market it? As beyond putting it > on Hacker News, explaining an P2P OT-backend communication system is > likely to confuse (if not discourage) potential backers. > (It also sounds more like the abstract for some academic research, > than a commercial project [the issue with being on the edge of > research for this technology]). > > If successful, I would want to put my degree on hold to work on this. > > > There is definitely a lot to think about for this... > Ali When do you graduate? :p Aside from hackernews, we should talk to techcrunch and all the other little tech news places. We should do a meetup on the topic here in SF to gather support, and we should try to sell the story to our local newspapers in our hometowns. I have friends who are good at this stuff that I can call on. I agree though - the hardest part is (as you say) figuring out how we distill down the idea to make it easy to explain. -J
