Shameless plug: A while ago I wrote a cli for firefox sync [1] (in my case mostly to automate some stuff when I create bookmarks).
It does not really solve your problem for browser-history/credentials etc. But as long as you use a client that you verified you can be kinda sure the data is E2E encrypted and can't be read by Mozilla.
Also on a side note: To this day the weave protocol is one of the more (needlessly) complex protocols I ever implemented and I'm still not sure what problems some of the design decisions solve...
A while ago I did something similar. I'm already downloading various playlists via yt-dlp and wrote a web interface [1] to view/play/search them.
My biggest annoyance at the time was importing my existing videos (and converting them to a streamable format, generating thumbnails and hover-previews etc).
Do you have any plans of allowing to import existing yt-dlp folder (in the standard layout with a bunch of mkv files, the info.json, the subtitles etc). Because my current archive contains a lot of already-deleted videos :(
I'm no cryptographic expert, but I always liked the simple design of the kdbx files. So simple that I can understand it and see tat there are no (obvious, assuming the underlying algorithms are called correctly) problems:
The whole database is a single big xml document which is then encrypted with a normal symmetrical encryption method (most of the time AES). And that is already the core of it.
There are a few additional things (A user-chosen key-derivation-function is used to increase the brute-force time and there is a header in the binary format with such things as keepass version, which algorithms are used for encrypting and a checksum...).
But in comparison to other cloud-based password managers it's a nice feeling to intuitively "know" whats happening under the hood.
a while ago I had a periodical cron script that would check if a specific domain is available. I wanted to get a notification on my smartphone as soon as the domain was free.
But I couldn't find a simple way of sending a push notification from a bash script. I ended up using the [IFTTT](http://ifttt.com/) API to send a [Pushbullet](http://pushbullet.com/) message to my phone which triggered a [Tasker](https://play.google.com/store/apps/details?id=net.dinglisch....) task to play a loud sound - it worked at that time, but I still think it was stupidly complicated.
So I decided to make an app where you can send a text to a very simple API and get a notification on your phone. And over the last weekend I decided to polish it enough in case someone else runs in the same need :D
I created an issue [0] for this.
I'm trying to find time today to organize the project structure for this, so that it shouldn't be too hard to add other UI frontends.
You are more than welcome to contribute, especially because I'm also completely unexperienced with GTK# :)
But isn't Xamarin.Forms only for mobile platforms? I can't find any information about building desktop apps with it (but also my only experience with Xamarin is currently MonoGame).
I have to admit it was mostly because I didn't like the electrum clients.
I just felt wrong to have a program always in the background runnning that permanently uses 250MB RAM.
Also last time I tested it, it ran pretty slow on my machine. But it could be that this has become better.
For the last few weeks I made my own notes client (mainly for [simplenote](https://simplenote.com/)) because the standard Electrum client felt pretty ... heavy.
Multiple backends are supported via plugins. Currently you can use it to access your notes on simplenote, Standard Note, Nectcloud/owncloud or no remote (aka local only).
I plan on adding Evernote support (only for plain, unformatted notes) and a better editor with a little bit of markdown highlighting (similiar to [qownnotes](http://www.qownnotes.org))
Tell me what you think and if you have ideas/criticism :D
It does not really solve your problem for browser-history/credentials etc. But as long as you use a client that you verified you can be kinda sure the data is E2E encrypted and can't be read by Mozilla.
Also on a side note: To this day the weave protocol is one of the more (needlessly) complex protocols I ever implemented and I'm still not sure what problems some of the design decisions solve...
[1] github.com/mikescher/firefox-sync-client