alialbaali
Cloud storage
Noto will support cloud storage with Client-Side Encryption in the next major version. It's currently in the work using Supabase for cloud storage, and Bouncy Castle for encryption. For more details, please check #92.
There will be 3 options available to the users to choose from:
- Using the app completely offline, and free of cost, like its current state.
- Using the app with limited cloud storage, and free of cost. For example, limit of 5 folders, 100 notes per folder, 10 labels per folder; This is just an example and not how it's going to be limited.
- Using the app with unlimited cloud storage, and a monthly/yearly subscription to cover the costs of hosting, and maintaining the project.
Please use this issue to discuss your thoughts.
How about a self-hosting server? Will you support it? It would be great if I can run a sync service on my own server.
Great idea, but it is on the long term roadmap, where all of Noto would be self-hosted and usable across all platforms.
Add a sync feature to Google drive with password protected would be enough. Like 2fas is doing
What about reusing Matrix? It's an HTTPS REST publish-subscribe API, self-hostable, open specification, bindings to the major langs, built-in E2EE, file upload, multi-user support (may be relevant if collaboration features are to be supported), a lot of third-party clients. It's used for IoT besides chatting. This app becomes a client that only understands text messages:
- the app settings have the user ID, server, and room ID
- download new events for that room
- for each new event: if it is a message (= not a file, state change, ...) and it contains the identifier of a note, then consider it as an update (the last update wins)
Or there is Etherpad (collaborative notetaking server, famous in the FOSS ecosystem) but I'm not sure if / how encryption could be implemented.
I'm not sure how a communication protocol can be used for a note-taking app?
It's a generic cloud. The server is a Postgres database of JSONs + HTTPS endpoints. The client syncs the DB two-way with a local cache. You can only talk to your home server where you made the account; it's not peer-to-peer. Replicating JSONs among servers (federation) is opt-in and not really relevant here.
The docs emphasize that it's a generic communication protocol, because the free software ecosystem, which is historically dependent on IRC, has a thing about hosting Matrix-based chats to extend / replace IRC, as a chat is basically a cloud-hosted DB of structured data. But it's communication in the sense of "distributed DB" not in the sense of a transport protocol.
The server enforces a few standard JSON formats (room message vs file vs metadata ...), but you can use a "room message" as an envelope and encapsulate your own format inside that.
The benefit is the ecosystem around it, there are multiple servers, plenty of clients (GUI, TUI, CLI) and libraries for all languages, it's privacy-first, and the usual primitives are implemented (incl. file sharing, E2EE).
