Skins declare
Presentation says what approved capabilities it needs. It does not bring executable machinery along for the ride.
THE FAMILY TREE, WITH THE BARK LEFT ON
How’s Yer Father?
Where SnapSmack came from, who taught it the good bits, and why it refuses to behave like ordinary software.
A Fine Pedigree
The family jewels were never venture capital.
SnapSmack did not appear from nowhere. It follows a trail broken by personal publishing systems, photoblogging projects, and the people who sustained them—often with too little help or recognition. Preserving that history means naming the work, learning from what its maintainers endured, and carrying the best of it forward.
Noah Grey comes first. He inspired me as a photographer, a creator, and a person. He is senpai. I am kohai. SnapSmack is the kohai’s offering. His photographs and his work on Greymatter showed me that publishing software could be personal, independent, generous, strange, and unmistakably human.
Pixelpost carried that independent photoblogging spirit into a system built specifically around photographs. Its interface shaped much of what SnapSmack became, and its history supplied lessons worth taking seriously rather than quietly strip-mining for nostalgia.
Well-bred, badly behaved. SnapSmack respects its lineage without embalming it. The point is to preserve what was right, learn from what hurt, and build the thing photographers need now.
Bad Habits We Didn’t Inherit
No plugin pile. No public support honeypot.
No arbitrary plugins. A SnapSmack skin manifest is not executable code. It is a validated, declarative shopping list describing the skin and naming the approved layouts, controls, fonts, and effects it needs. The CMS supplies those capabilities from its shared, reviewed library. A skin can ask for the masonry engine or a film effect; it cannot arrive carrying an unknown script and run it.
This keeps presentation separate from machinery. One library engine can serve radically different skins, and a security or compatibility repair reaches every skin that declared it. Remove a skin and it removes its presentation without leaving abandoned plugin code behind. The boundary owes a debt to b2evolution’s resistance to plugin hell; SnapSmack takes it further.
Support without a public forum surface. The support forum lives inside authenticated SnapSmack administration. Operators can ask for help from the software itself without leaving the usual public registration, login, and posting endpoints outside for bots and drive-by spammers.
Behind the Bike Sheds
The lesson nobody puts in the launch announcement.
This decision owes something to Jay Williams’ candid account of the attempted Pixelpost rewrite. Jay deserves enormous credit: he wrote most of the code that moved Pixelpost from version 1.5 to 1.6, contributed substantially to the rewrite, and spent countless hours helping its users. He deserves far more recognition for that work than he received. SnapSmack stands in the shadow of that effort.
As Pixelpost’s last active developer and moderator, Jay described automatic spam across the forum and blog as nearly impossible for one person to clean up. He was equally clear that the rewrite stopped for broader reasons: too few developers, too little available time, and the difficulty of maintaining the site while finishing the software without the collaboration it needed.
That was not a failure of effort. SnapSmack’s internal forum applies one practical lesson from his experience: public support infrastructure must not be allowed to consume the limited time available to maintain the software itself.
The Bits Under the Bonnet
One engine, declared capabilities, fewer nasty surprises.
The CMS delivers
Shared, reviewed engines provide layouts, effects, controls, and behavior consistently across every compatible skin.
Repairs propagate
Fix the shared engine once and every skin using it receives the correction instead of maintaining its own forgotten copy.
Removal means removal
Taking away a skin removes its presentation. It does not leave a midden of abandoned plugin code and database debris.
Belt and Braces
Security works better when the layers know each other.
Authentication, authorization, abuse prevention, signed distribution, integrity monitoring, breach containment, recovery, fleet intelligence, and public audit closure reinforce one another instead of operating as isolated checkboxes.
That does not make any individual ingredient a SnapSmack invention. What is unusual is the coordination: putting all the fixings on the burger and bringing the architectural and security depth people expect from paid software to freeware built for a small community.
No Claiming Someone Else’s Bastard
The claim is the combination, not immaculate conception.
SnapSmack does not claim to have invented personal publishing, photoblogging, manifests, federation, moderation, backups, two-factor authentication, integrity monitoring, or any of the other ingredients it uses.
It claims to have assembled them deliberately around independent photographers: one owned publishing home, several ways to present the work, a connected social presence, a free desktop ecosystem, and enough defensive depth to keep the whole thing alive.