Blog: 01-About #14
Blog: 01-About #14
Conversation
| about local-first software: https://www.inkandswitch.com/local-first/ | ||
|
|
||
| all apps store internal data as plain files in user-selected folders, easy to sync. but we are working on sync library too, to remove necessity to install another software. for this moment, we use Syncthing to sync internal files between devices: https://syncthing.net | ||
|
|
||
| we use "content-addressing" it to make our apps work with data identifying it by its content instead of location. it makes some things easier, too. this concept was introduced by IPFS: https://www.ipfs.tech/ |
There was a problem hiding this comment.
This is the essence of the technical side of our project. The project started in 2020 and was really slow-paced while we were developing the very first prototype of Navigator. It probably was not really good decision to develop it as an Android app first, because Android development appeared to be pretty challenging. The decision was made because state of GUI frameworks for Rust was pretty poor at that time and since the project aims at being cross-platform, it seemed to be OKish option to develop mobile GUI instead... So, this summer I've finally discovered the term "Local-first Software" and the website and it really describes what I wanted to achieve since 2020. I really recommend reading their article "7 ideals of Local-first Software".
In fact, we're designing Desktop version now and it's going to be better fit for the target audience. Tagging resources takes some time and on Mobile it's worth for important personal documents, while on Desktop it's more about "office work", study and scientific research.
But we still have the key component missing, which is P2P sync... I want to build a library for P2P sync which can be used both for generic file sync (i.e. private cloud consisting of user's devices), and by apps to sync app-specific data (e.g. notes, bookmarks, geolocations, etc.). This idea intersects with IPFS in some way, but the key feature is that each app could use the lib to sync with other user's devices under the hood without making the user to install or setup anything. It could also be used to implement sort of P2P CDN to distribute images, videos and other resources between app instances, not only belonging to same user.
There was a problem hiding this comment.
Probably we should be more careful about cloud part. Cloud is more robust, but less performant and less secure in theory. I think, when we implement our own sync, all our apps will have free Wi-Fi sync (so you come home and your phone get synced with laptop, for instance). But we might provide our servers as paid backup + additional sync when the user is not around Wi-Fi.
"Navigator" app is more about UX of workflows with local files. In my opinion, on mobile devices it's so painful to work with local files of any kind. All apps are built assuming users only play with their devices (including Instagram and Facebook). Desktop still remains preferred platform for "real work" but even there file browsing experience is pretty outdated. In my opinion, filesystems are made for machines and humans are not really adapted to interact with it. It's better on macOS since it has tags but Apple's software isn't opensource, right? Although, honestly, I lack experience with Apple devices and need to catch up with it. Also curious about your opinion.
Other apps, e.g. "Shelf" and "Memo" are more use-case oriented. "Shelf" is a bookmarks keeper, we have it on Android and Desktop. "Memo" is versatile notes maker. Both will have W-Fi sync for complete local-first experience, and cloud/self-hosted backup. By the way, ability to self-host backup server is also very important for the project.
And last, we develop the core for all apps in Rust: https://github.com/ARK-Builders/arklib This core is opensource and should become the backbone for cross-platform local-first apps.
First real post telling about our project: key concepts and how do we function.