Apologies for the lengthy delay in this. Had a crazy gig schedule in Feb followed by… a relocation to South Florida!
I’ve been working on a phpBB replacement in a language / framework im familiar in. It’s largely in the completed-but-prototype phase, and has significant vibe coded elements as a POC and I would prefer to hand write everything now that it’s proven out. I have significant reservations about the current state of social media… and would like to come up with something with fewer compromises but, that’s a discussion for another time. I will open that up soon for feedback more broadly but not yet.
Therefore, since that is a big undertaking - I’ve made a few improvements, including a few I meant to make last year but didn’t have time.
You can find a staging server with these improvements at stg.trombonechat.com
The main differences, for those curious, are:
[*] fix a nasty security flaw by upgrading to the most recent point release; fortunately, we appear to not have been affected by this bug
[*] ~75% reduction in cost due to a few custom extensions that offload some of the least efficient architectural choices of phpBB, among them:
[*] offloading image and asset storage to s3 style buckets; pseudo CDN by storing some hot assets in memory rather than disk, with a medium tier cache with reasonable eviction policies
[*] complete parallel, offsite reimplementation of search; offloads things like “your posts”, “new posts”, etc. - falls back to primary search when. It available. <- this one is enormous as that was maybe 20% the problem and also phpBB search isn’t awesome to begin with
[*] migration from MySQL to PostgreSQL (also big as MySQL is a big resource hog)
[*] aggressive caching / static generation / load balancing of content for unauthenticated users
The last one is by far the biggest change. The problem with phpBB architecture is that every unauthenticated request generates a database connection. This means that if a scraper is scraping 30 pages in parallel, it “reserves” 30 database connections that otherwise actual users could be using. On resource constrained environments, this effectively means that without cloudflare protections - indexers consume ALL available resources so actual interaction is basically cut off.
That’s why I had to make the aggressive cloudflare changes last year. With this change, all human users are given exclusive access to the database and a read replica serves all cached content, including page views, search, and topics. The synchronization is approximately 5-10 seconds delayed. Net effect is I can probably allow indexers so the site is visible again.
There are also some anti scamming things I can do with this in place, but I’ll refrain from enumerating how that works with much detail because it would be not so difficult to circumvent if one knows the approach. Though it should enable less avoidable strategies too.
So, with all that said, if I can get some testers on the site to kick the tires, make sure that it works as you currently use it, and report any bugs here - I can get this deployed to this site sometime this week!
