Nice work! I spent about six months pursuing the exact same idea about five years ago with the hope of building a company around it. I got reasonably far with a prototype, but gave up on the business side of things after doing more extensive market research and interviews.

One of the people I talked to had been involved with a startup called Adrenaline Mobility which did something very similar, but ultimately ran out of runway and was acquired by Twitter. He told an interesting story about how they (over-)built a highly scalable service but had a really hard time selling it. Those who lack the training to know the difference between good security and hand waving didn't see the value, and those who did have the training and skills didn't trust a third party to do it right anyway.

Nonetheless, a lot has changed in the past five years, and end-to-end encryption is more widely appreciated now. I hope you have better luck with the commercial side of things; this looks like a very promising start.

Thanks a lot! Things have indeed changed, and I feel like the public is really starting to understand the dangers with having their data exposed. I've been running EteSync for years now, and it's still growing.

I'd love to have a chat with you to learn from your experience if you are willing! My email is tom at etebase, please drop me a line (or let me know how to best reach you).

Thanks again!

This might be very good timing for your product - the European Data Protection Board has just out their first guidance after the Schrems II case. It seems to firmly point towards cloud services where the provider can access the data in plaintext as being "unable to have the risks mitigated" from the perspective of international transfers.

Perhaps a straightforward E2EE toolbox could help companies implement their products rapidly so they remain complaint. Clearly this won't help fix issues like Microsoft 365 or GSuite (which need access to the plaintext for email and similar), but it might help some types of SaaS to thicken up their client application and prevent the backend having access to unencrypted data, thus making the transfer permitted.

I just want to echo the above comment around how most customers don't have the knowledge to understand the benefit of this, but hopefully this is changing as we see more strict enforcement of penalties for data breaches. Data is fast becoming a liability you don't want to have the ability to see, and systems like yours offer usable solutions for those who don't understand all the technology, but need a solution.

Thank you so much for this feedback! I missed the guidance you mentioned!

I sincerely wish you luck with this.

I wrote something similar, a couple of years ago[0], but it doesn't include encryption; it merely gives a place to add encryption. I didn't want to deal with the legalities of included encryption, and I think others can do far better than I (but it is quite secure, nonetheless[1]). It was really done, just to "retool" my architectural and engineering skills, as I was pivoting from being a manager, back to being a developer.

I am now using it as a backend for an app under development (currently closed-source). It has been working a treat.

But after the app has been released, I may encourage the folks to look at alternatives for the backend. I am not really into maintaining a server system. I like to stay on the app side of things.

[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...

[1] https://riftvalleysoftware.com/BAOBAB/PDFs/Security.pdf (Downloads a PDF)

Thank you for your kind words!

I think the encryption is the key differentiator here, at least for me. I don't want my data saved exposed on someone else's server, AKA the cloud.

The deal with mine, is the encryption is left to the client. The server just stores a binary "thing." That "thing" can be an encrypted envelope, managed by the client[s]. Since it's a closed-loop system, then a key could be shared programmatically, outside the purview of the server.

Yeah, in Etebase the server also just sees "things", though it tries to make it easy on the client to only get what's changed and etc.

Just curious, how does that differ from a system like Firefox sync which is also using client side encryption?

I don't think Firefox sync makes it very easy for devs to build other encrypted applications. Even if they did however, there are a lot of challenges with encrypted applications that they just don't take care of. Not to mention that they are very we centric and don't have developer APIs in many languages.

Is there any technical document describing how it works ? For example, order-preserving indices (for range queries) are often an issue in end-to-end databases ; did your design allow to you to provide them, or did you just consider solving this problem out-of-scope ?

There are docs here: https://docs.etebase.com/ Though they mostly focus on how to use rather than how it works (though we are making progress on that section).

As for your specific question: we currently don't solve that, but we plan on doing it in the near future. Our approach will be to maintain a client-side index that will be synced across devices. Etebase already utilities to maintain consistency, so this can be done safely.

This question, and ones like it, are exactly why we created Etebase. Building encrypted applications is fundamentally different and comes with a lot of challenges. We plan on continue building all of the tools needed to develop using this different paradigm.

Congrats! Kudos for making the server component open source, something your competitors aren't doing.

Flutter please lol

Anyways, great work!