Roll Your Own Social, Part One
This week, I want to return to my ongoing series on building a 'zero big tech' open source web stack. In DeGooglefication Part One & Part Two, I went into the hows and whys of getting rid of Google Maps and Google Analytics on my community portal testbed site, PDXcomm.net. This time, I want to talk about the hows and whys of getting out from under another key aspect of the Tech Bro Hegemony: Social Media.
To be clear, there is no way under present circumstances that a homebrewed social media platform is going to be competitive with any of the existing majority platforms. And, while that could change, competing with the likes (so to speak) of X and Facebook is not the goal here. The goal is to drive engagement on a different type of platform, one more aligned with what the web was supposed to be in the first place.
To that end, I've spent a lot of time over the last year researching free and open source social media platforms. The finalist I originally arrived at for my own stack was originally UNA CMS. It checked off all the initial boxes of privacy, open source licensing, and a rich set of available features. But I lost the better part of a week trying to fix what turned out to be a fairly critical flaw in their internal 'app store' of available components. And even after that was resolved, the complexity of trying to create a simple menu structure in their internal CMS was just a little too much effort for the end result. Even though I like the platform and think great things could be done with it, I felt that I should be able to find something that was a better fit for my particular purposes.
And while it is too soon to say I've found that better tool, what I am working on now looks very promising.
Like UNA, the Elgg platform is open source and offers a fairly rich set of available features. What it additionally offers is SSO compatibility with my primary CMS, Concrete, and an architecture that permits creating Concrete custom content blocks that serve as 'wrappers' for Elgg plugins. This latter feature is particularly attractive, given my intention to build a seamlessly integrated web stack with a unified user experience. So far, I've managed to create a backend dashboard for managing the API integration and a couple of test custom content blocks that use the integration.
And, so far, it seems to be working.
My next step on this is to build out some fairly complex blocks and see how far I can push the integration. If it holds up, I'll have taken an significant step forward with this project. If it doesn't, I'll chalk it up as a learning experience and move on to the next candidate platform. Either way, I will have further refined my skills as a vibe coder and preserved the skills I already had as a technology project manager. I'd happily trade both for an actual job... but those are currently in somewhat short supply.
At least it's fun, right?
