I think integrating patchql into mobile apps 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.
@Hendrik Peter The current indexing workload that the JS SSB stack does is very intense, also on desktop, but there are strategies to decrease that workload, some of which are being implemented into patchql already. Also in Manyverse itself the indexing workload has reduced with the adoption of wasm libsodium and other things, so that when I ran a test on a modern smartphone (Google Pixel 3 if I recall correctly) the onboarding and indexing took just 40 seconds. Initial onboarding also depends on hops count and/or how many accounts you follow in the beginning. There are a lot of ways to improve the onboarding CPU workload, from "doing less work" to "doing that work more spread out over time" to "using faster engines", so that I wouldn't dismiss client-side processing yet.
Doing things server side with lite client really worries me, because it's a return to the current state of the internet, which is heavily dependent on servers. It's not much better than ActivityPub. I think SSB's big appeal is that it's a bold return to the end-to-end principle and works perfectly off-grid, from computer to computer in any circumstances, which also has socioeconomical benefits for underconnected communities.
But I'm loving what I see so far with Tightbeam and it's refreshing to see new apps flourishing. : )