I've probably invested about $100k worth of time into ShareJS at this point (much of that paid for by different employers). It is reasonably stable and scalable across multiple backend machines. It supports queries with results which update in realtime. I'm currently dependant on redis multi-machine scalability but I have plans to move to foundationdb in the near future to increase how large I can scale the backend.
But if I did it again, it wouldn't cost anywhere near that much. And obviously I can reuse a lot of the existing work. I don't think a p2p / encrypted protocol will cost that much. Building the actual inbox-style application will be expensive, but core algorithms require more thinking but much less work than end-user systems. At this point I feel like I (/we) have done a lot of the thinking required. A description of the hardest parts of a workable wire protocol here: https://github.com/josephg/tp2stuff/blob/master/node4.coffee#L1-L109 and a working implementation of multi-node syncronization is here: https://github.com/josephg/tp2stuff/blob/master/node2.coffee Its a few hundred lines of code, which will be shared by all peers. I honestly think it'll take less than a couple of months to get /something/ working. I'm nervous about algorithmic speed in the sync protocol, and I'm nervous about the potential for DOS attacks via maliciously chosen operations in public waves (if we have them). Implementing a JSON OT algorithm which supports TP2 will take an awful lot of thought (probably a month of it), but its possible. The thing I'm most nervous about is client side work - though I'm not even sure I want to be the one to implement a client side application on top of the protocol. And if I do, I might be able to reuse mailpile. I'm confident I can make an efficient server side renderer if need be, or a fast client side renderer on top of asmjs. I've played with asmjs a lot already and it is easily fast enough for this sort of work. Its just a case of writing a C / LLJS implementation of the renderer. Again, this assumes I'm writing an inbox style client - which again I'm not entirely sold on. All up, I think having a spec & implementation of a P2P wavey system will take me less than 6 months of work. Even a simple client will take several months more. I don't think that timeline would be possible with the current codebase (and I should know - I spent the better part of a year working with it at google). But I think its quite possible in nodejs, and porting to C will probably be another month or two of work. -J On Tue, Dec 10, 2013 at 9:19 AM, Kirill Kostyuchenko <kisel2...@gmail.com> wrote: > Hello all, > > We still working hard on wave in our company and I can say for sure, > production ready, scalable wave service will cost more, than $100k. Just > because we already spent more than half. P2P and crypted protocol are > really dreams. > > Andrew Kaplanov have done completely new protocol with reconnection > support, server restart, client update support, wave diff support. Multiple > wavelets support which will allow to handle big waves. We almost done > dynamic rendering support. Without dynamic rendering it is impossible to > work with big waves. Production ready service should be absolutelly stable > and fast. And it is impossible to do it relying on the current protocol and > renderer. > > We will announce our work on the wiab.pro in a month or two. You will be > able to try new features and check the stability of service. It is really > more stable with the new protocol, because 90% of errors where in the > protocol. > > If somebody create successfully funded project on kickstarter or so, we can > make our work opensource (new protocol, dynamic renderer, diff support, > search, tags) for the amount about $50k. > > I think, funding of such project more likely, because we already almost > 'did the work'. > > > On Tue, Dec 10, 2013 at 2:25 PM, Upayavira <u...@odoko.co.uk> wrote: > >> In case it helps: >> >> http://www.indiegogo.com/projects/a-month-of-apache-tapestry-5 >> >> A successful, if smaller kickstarter style campaign. May help you >> visualise what your 'give backs' and suggested donation sizes might be. >> >> Note that this took place within an Apache framework without issues, so >> it can be done (not that it should - ultimately tests not my decision to >> make). >> >> Upayavira >> >> On Wed, Dec 4, 2013, at 08:42 PM, Joseph Gentle wrote: >> > Will do. As I said, I don't anticipate starting the kickstarter for >> > about a year, though I want to do preliminary work (prototyping out >> > some of the protocols and such) now. >> > >> > John I agree that (1) and (2) are the most interesting parts. But I'm >> > not sure that this is the right tool to build *everything* on top of. >> > We should start with the platform and get people building stuff on top >> > of it. >> > >> > -J >> > >> > On Wed, Dec 4, 2013 at 12:05 PM, John Blossom <jblos...@gmail.com> >> wrote: >> > > Joseph, >> > > >> > > Thanks for chiming in. I'd be interested in getting crowdsourced >> financing >> > > for this also. We don't have a major corporation funding our >> lifestyles to >> > > enable such work, so we need something. >> > > >> > > I am in general agreement with your overall plan, though as I've stated >> > > before, once you have 1) and 2) done right then there's so much more >> that >> > > the platform could/should do besides an email replacement. I do think >> that >> > > the "internet of things" is a key opportunity for such a >> communications and >> > > data management model, merged with secure, network-independent >> > > communications. Nkommo can't really move forward without that combo. >> > > >> > > As for the name, all things are possible once it's on Github, it >> seems. A >> > > fresh start might be in order. >> > > >> > > Please keep me in the loop, I'd be glad to help push things in this >> > > direction. Without funding, we're nowhere. >> > > >> > > All the best, >> > > >> > > John Blossom >> > > >> > > email: jblos...@gmail.com >> > > phone: 203.293.8511 >> > > google+: google.com/+JohnBlossom >> > > >> > > >> > > On Sat, Nov 30, 2013 at 11:03 PM, Joseph Gentle <jose...@gmail.com> >> wrote: >> > > >> > >> I still really want to make the wave platform we've been talking about >> > >> for awhile. I just don't have any time because I need to work to eat. >> > >> >> > >> So I've spent the last month thinking about running a kickstarter to >> > >> fund the work. Christian's email was really timely. >> > >> >> > >> >> > >> 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. >> > >> >> > >> 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. >> > >> >> > >> Messages should be cryptographically secure from snooping. >> > >> >> > >> >> > >> The way I see it, there's fundamentally three pieces that make up >> wave: >> > >> >> > >> 1. A set of OT primitives which allow peers to generate & interpret >> > >> operations >> > >> 2. A platform on top of (1) for exchanging operations between >> networked >> > >> peers >> > >> 3. An application on top of (2) which is trying to replace email >> > >> >> > >> These pieces should be separate from one another, and usable in other >> > >> contexts. >> > >> >> > >> I have a clear idea of how we can make (1) and (2) work. The OT part >> > >> we've talked about on the list and I've been slowly prototyping out >> > >> here: http://github.com/josephg/tp2stuff >> > >> >> > >> I have a bunch of applications I want to build on top of a platform >> > >> like this. For example, I want my text editor, compiler & unit tests >> > >> to all talk to one another so my text editor doesn't need >> > >> language-specific completion or syntax checking, and so my friends can >> > >> jump in and help me code. >> > >> >> > >> 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. >> > >> >> > >> 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 >> > >> I'm also not allowed to stay in the US without an employer on my visa. >> > >> >> > >> The earliest this will probably happen is the end of the year. >> > >> >> > >> Kickstarter might also not be the right way to fund it. Cryptocat was >> > >> funded in 2012 mostly by Radio Free Asia's Open Tech Fund[1] to the >> > >> tune of ~$100k. A kickstarter would give us users (great) and >> > >> publicity, but the right private sponsor might also work. >> > >> >> > >> Maybe the most contentious part of all, I don't think I'd want to call >> > >> it wave. But it really would be the grandchild of what we've been >> > >> working on all this time. >> > >> >> > >> Thats my thoughts. If anyone has any ideas, I'm all ears. As I say, >> > >> I'm keen to build this, but I'm too old to live on ramen in a granny >> > >> shack. This thing we've been working toward has real value, and could >> > >> be put to great effect if we can actually make it good. >> > >> >> > >> -J >> > >> >> > >> >> > >> >> > >> [1] https://crypto.cat/documents/report-1213.pdf >> > >> https://www.opentechfund.org/ >> > >> >>
