precisely @Rabble, @Piet and @mixmix.

When I did experiments with the existing ssb-server I noticed that all content going in to the database (so not only my posts, but pretty much everything that gets stored) has to go through signing using the keys. I outlined that in my previous weekly. This essentially means that I have to download a post to the phone (or sniff it up from wifi), request the previous data-set from the server-side (since we hash new records from the previous record in storage), sign it on the client side, then send the new record back. at which point 1 piece of gossip caused 2 pieces go over the wire for a a total number of 3 times.

I learned a lot of new things last week though. Between hosting a pub, dissecting ssb-server, ssb-master and pretty much every module I came across in detail. (Without too much confidence) there seem to be 3 paths that I could take from here with the private key concerns:

1. Lowest hanging fruit: Keep it as it is and limit the backend that I wrote this week to only being able to deal with 3 or so ssb-servers. This is actually already the case as spawning more ssb-servers in the contraption I made is super inefficient in terms of storage, CPU and Memory use. With this the product lives as intended: you have small hubs (NAS machines or private VPS boxes) serving 3 or so accounts in a house-hold, but yes they hold the keys.

2. beefier effort: Follow in the tracks of @andrestaltz and get ssb-server working natively on IOS and android. Serving a built-in ssb-server and bridging external non-java/swift/Objective C & JS into working IOS and Android modules. Then offloading old blobs (which after dissecting much of what I've seen so far is the biggest storage-eater) to a connected backend. My focus here is on IOS, I want to get that working; Users can already choose an android app with Manyverse out there. Apple is however incredibly picky in their reviews, so concessions will be made.

3. Over the top Rocket science: Rewrite ssb-server and it's modules to go for a more softer approach in signing, But doing that will effectively make private keys worthless, so that's not an option. or dive deeper into how messages are signed. does hashing messages really require the private keys? and could I instead sign my message on the phone, then have the server-side backend add the hash to link it into the chain?

Since I have Andre's attention here (sorry that I keep tagging you into things).
I think integrating patchql into mobile apps (doing things client side) is a bad idea, unless a full sunrise choir backend is included. It's super inefficient to run an ssb-server, have a patchql server make requests to that ssb-server for content, caching that and then serving it forward. Apart from the amount of moving parts (and what could go wrong), there is the phone-battery, I already see my battery-indicator tick away like the seconds notation on a digital clock when having Manyverse open in its current state. I don't think that will improve with patchql joining the mix, unless it replaces existing moving parts.