Brilliant, thanks.
As you probably know I’m also working in getting wpe/wpeqt (and webkit-gtk) packaged on Chum/SFOS.
Currently that’s a bit tricky as we lack modern enough compilers in SFOS5.0 so I have to use an unstable, older version of upstream wpe and webkit.
That why I use a modern Ubuntu with just the sysroot of SFOS.
Using a native ARM server helps a lot, not having to deal with cross compilation is so cool.
glibc is also an issue, since SFOS has an older version, I need to patch it in the binary to run on the device.
Have either of you considered nix? It’s a godsend for getting whatever version of anything locally.
I used this one to get the versions needed to build the app with the correct glibc.
You create a flake.nix file which you can distribute with your source and then anyone can run nix develop to get the exact same versions of everything in the file.
Kind of irrelevant in a thread about new work/fuctionality, guy with AI assistance is showing promising progress, if someone with months of real-human-bean-only work has nothing to show for it I’m gonna cheer on the ai-assisted guy and for the case you mentioned, sure throw it away or request partial PRs that can be reviewed sensibly, costs them almost nothing with the current subsidizing by big tech, why waste limited human time on reviewing behemoths. One thing that’s interesting here is the amount of progress achieved in so little time (@flypig’s 91 esr took about a year of part-time voluntary work, 102esr is now taking over a year full time jolla investment), maybe safari is the future if OP can deliver a working browser (or close to it), 102 is already few years after extended support has ended, this thing is likely to be actually up-to-date/secure’ish??? Maybe time to reevaluate commitment to FF
Edit:
Jolla was supposed to be a nimble boat that can adapt quickly to challenges (see libhybris and most current mobile linuxes using halium, that was jolla move when st ericsson failed, browser being stuck few years after end of life for close to a decade is not a jolla move at all)
No, it is in fact exactly what I was talking about. The seductive, ah, it’s just new features bit is biting me in the ass at the moment. I STILL consider it a net plus just want to advise caution which seems in play. Obviously pile driving a browser with code pilot is a good idea. Evil, but good. I think it will probably be impossible to audit it but I don’t think the NSA or the israelis care about our niche enough to take advantage of that 
I assure you noone is going to complain if you sloppa together camera2 api support, even if it will have a ton of spaghetti sloppa, it will be easier to cut than it being in forever… Whelp, noone managed to implement it at all state (and android codebase should be in all ai’s, very likely to be doable, the sfos compositor is probably hardly in the dataset)
Edit: as to the nsa I’m going to assume it’s a joke, or would you miss camera api code having weird http requests/servers being set up…
All of the publicly available code from SFOS and adjacent projects seems to be in Claude, at least. It’s impressive. I really don’t have an issue with people doing it in a way that is structured enough for me to pick up. What I won’t do is use it if I can’t trace what’s going on. Something like that what’s app client in go up on openrepos, I had a look at and it’s a no deal. It’s a one shot that will get you banned after eating your breakfast.
EDIT: The issues, claude based, I’m dealing with now are not really so much with the shiny new features (in tooter) but with the rewrites it did of older code. It went idiomatic and introduced a) a new race condition b) increasd the frequency of an old race condition. That means, tooter crashes 2 to 3 times as often as it did. So, although I like the new shiny bits, the regressions and new bugs make me unhappy. Sad camper. Wet camper.
It is, but with zero repos modifying it etc, android source has been rehashed by thousands of repos. I’ve no idea about whatts ap code or if anyone suffered what you describe, from what I hear it was a webview so might look like browser usage, irrelevant, the ai-doomerism and trying to discredit ppl bringing new and very much awaited features to sfos because ‘muh-ai’ uhh ick, is dumb tho
Ah, not so sure about that. In any case I was talking about: whatsapp | OpenRepos.net — Community Repository System
It’s based on a well known backend in go. It’s not bad even, but it ignores some fundamentals. And that has nothing to do with AI this or that. It has to do with sloppy engineering. If a couple of basics or even the will to make notes were present, I’d be cheering from the sidelines. But, as it is, I won’t use it.
Really, I need all the help I can get, but doing it with claude or copilot properly is not as speedy or cheap as you paint it. I’d have to spend about 200 euro a month with my set of problems.
You do you man, but the negative nancies need to rethink their stance, AI is nowhere near one-shotting ‘browser for sfos’, the guy is spending a shit ton of his time (and resources) guiding an autocomplete towards a goal and progress seems amazing (and most likely full of NSA backdoors etc, simple solution: don’t use it), once we reach android level of too many apps you guise can come back, we NEED a freaking working uptodate browser, go complain somewhere else
Edit: and I have never painted it cheap or speedy, yet from his OG post to posting from browser was absurdly fast, compare to flypig’s diary and one has to wonder, is sticking with ‘true and tested and forever few years behind’ (and growing with each esr release) the way for jolla, keeping up with FF has proven to be untenable(literally the most complained issue with sfos for years, even on tjc, here we are decade later, same sht), do we need another decade of that, or are we ready for new approach?
Exactly. If you could stop cheerleading, I’d like to get involved in developing, ai or not. My points are directed at a developer who I’m hoping is preserving ‘context’ for step wise prompting and, if using mcp, documenting the workflow. I actually look at this stuff and work on it. AND @nephros has done work in this domain, so I’m hardly a naysayer. I have demonstrably accelerated development with claude and I’m just trying to OPTIMIZE that, damn it. You are just slowing me down. 3 packages pushed today, and it could have been 4 if I stopped talking to you.
Could be 256 if you only used openclaw, issue still remains, you throw shade at actually new and revolutionary developments for sfos (omg who will review all these nsa backdoors)
Edit: stop arguing on the internet, back to shipping features!
Update: I’ve done some housekeeping.
I have worked toward getting things clean and somewhat usable, code- and doc-wise. The code is split across two repos:
This one contains all the code and scripts necessary to build and package WebKit:
This one is a fork of the Jolla browser; it removes the Gecko stuff and adds the new layer for Browser ↔ WPEQt.
I have managed to get the RPMs and install them on my device; the browser runs. Video and audio playback are working, but they are software-decoded (it’s slooow).
Another issue I have is that if I use a UA from an iPhone, Cloudflare and Google let me navigate the web freely. But if I switch to an Android Agent (which allows getting supported codecs on YouTube), every website thinks that I am a bot. That’s not fun.
On the conversation about AI slop: Yes, this is mostly AI slop. I didn’t hide it in the first post, and I don’t really care if that bothers some. Security-wise, the core browser is free of AI slop and battle-tested. I only use my slop to glue WPEQt and Jolla Browser together. The scope is limited and constrained, and in my experience, this helps limit the sloppy slop.
Honestly, I don’t expect Jolla to ever ship this code. I hope that it allows, along with Nephros’ work, to open a conversation about switching to WebKit, and that these early implementations show the path for a better, official one.
My end goal is to offer a modern browser on an openrepos, even if it breaks conventional packaging. I have my ticket for the first batch of J2 I intend to have a native modern browser to use with!
Ps: if anyone with some spare tokens and a bit of money for the Hetzner server could try to build the packages that would be fantastic.
That is the spirit I like. If someone thinks the big bad AI being used to glue an existing engine to an existing UI is too scary, then they can simply choose not to install it from OpenRepos.
Thanks for the clear documentation in the wpe-sfos-build … along with the commit history in the browser it’s fairly clear what goes where. Looks like it might give @nephros a leg up and maybe provide some motivation for jolla to address a couple of updates (eg. glibc 2.29+ )…
Where’d you get this data?
My CTO gut feel says it’s taking forever because ESR102 is at-mal’s parallel project no 6, or something similar. There is no way somebody’s has been working on it full time for a year, and making so little progress that nothing could be said about it all this time, after what and how at-flypig pulled ESR91 off 
Gecko blog for flypig List items - 339 days
For jolla’s official attempt Gecko ESR102 development - announced Feb 20 2025 (already in progress at that point)
Indeed, you just need to look at the commit history of the next branch. Nice to see that commits from @nephros and @ichthyosaurus got merged. But it’s relatively little activity for the last year.
In related news, here’s SailfishOS Browser, Luakit, GTKWebKit Minibrowser, and QtWPE Minibrowser running side by side:
I think with all these possibilities, a brighter future for SFOS Browsing lies ahead…
Not pictued: Cog, but that’s a bitch to launch ATM.
