Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
I think that's partly the point of this exercise - if they find a meow they now know this is an untrusted source.
Because it's pretty easy to say 'ignore untrusted sources' but when you're maintaining an open source repo (especially if it's still pretty small/new) this detection is part of the cognitive burden. Almost every contribution will technically be from an unknown source for a long time, until, if you're lucky, some drive-by contributors turn regular.
True...but the arguably better / more defensive stance is "accept no PR unless the user explains wtf it does and/or I personally trust them".
Iow, stop accepting PRs from randos - clanker or meatbag - full stop. The lowest cognitive load is "none".
I don't know you / we can't have a convo why you sent me this? Into the bin.
(In my humble opinion, for a small or new project, that's a cleaner footing anyway)
The claude.md file is cute, but I don't think a claude would actually be tripped up by that.
It's not such a high bar to pass to be honest with you. You'd probably need something more subtle, at which point you're just shooting yourself in the foot.
The meow thing is more like a philosophical line in the sand than anything else and I respect it.
But given the way that Codeberg actually blocks crawlers and agents (and how Claude works), it probably doesn't really do what we think it does.
How does a developer with good intentions prove their trustworthiness?
What about the XZ Utils backdoor? That was inserted by a trusted maintainer who literally spent years building up trust.
Let's tag it as "provisional" then. As in, once you have my provisional trust, accrued over time, I'll probably stop auditing every single line. I'll still look tho.
But the long and short of it is this - XZ utils backdoor actually makes case for trusting clankers more than human collaborators. Clankers are incompetent... they usually aren't Machiavellian.
I've heard it said that an LLM is like a Labrador retriever when it comes to coding. Overly excited, pulls ahead, does some really goofy shit and sometimes chews up your couch (hello Qwen 27B)...but it is trainable.
Human devs are like cats...which is oddly on brand for this project :)
I'd sooner trust a clanker I had prompted with my house style ticket and narrowly sandboxed than a rando online. Of course, the difference is, a rando may eventually earn trust...a clanker doesn't - but it doesn't need to if narrowly scoped.
EDIT: here's a template I use / created for Qwen / Codex. It's...opinionated and bears scars of prior over eager Labradors. This is usually step 1 I fill out. My fingers are going to shit with O/A , so am trying to minimise scut work.
TICKET-Px-SHORT-DESCRIPTIVE-NAME
Status: PROPOSED Timestamp: DD-MM-YY-HH-MM Priority: P0 | P1 | P2 | P3
Purpose
One paragraph:
Why this exists
Describe:
Include: We do not want ... We do want ...
Proof requirements before implementation
Hard gate.
Before implementation exists, prove:
If proof fails: stop and escalate. Do not patch.
Gates
Each gate:
Test Plan
Mix of:
Prefer: prove behaviour changed, not just coverage increased.
Definition of Success / PASS
Minimum acceptable state.
Must describe:
Definition of Success / EXCELLENT
Stretch target.
Usually:
Assumptions
State assumptions explicitly.
Examples:
Proposed shape
Describe:
Prefer: small typed objects.
Thin leaf intent
If adding logic:
prefer:
Avoid:
Policy versus signal
Policy: config
Signal: code
Config controls behaviour. Signal detects reality.
Scope
Explicitly include:
Non-goals
Explicitly exclude:
Acceptance criteria
Numbered list.
Must be testable.
Definition of done
Agreement on:
Only then may implementation tickets follow.