kittygram
codeberg.org
A nitter-like frontend for instagram

Kittygram is an Instagram frontend, like nitter and invideous.

A lot has changed since I first posted about it. Kittygram now has:

  • a developer API
  • atom feeds
  • ratelimit tracking
  • explore/popular pages
  • more themes
  • SuspiciousCarrot78@aussie.zoneEnglish
    7·
    2 days ago

    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.

    • Pieisawesome@lemmy.dbzer0.comEnglish
      3·
      5 hours ago

      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.

      • SuspiciousCarrot78@aussie.zoneEnglish
        1·
        1 hour ago

        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:

        • what changes
        • what does not
        • whether this is proposal / proof / implementation

        Why this exists

        Describe:

        • concrete failure mode
        • why current behaviour is wrong
        • why this is architectural not cosmetic
        • why local patches are rejected

        Include: We do not want … We do want …

        Proof requirements before implementation

        Hard gate.

        Before implementation exists, prove:

        • seam exists
        • ownership is correct
        • contract can be enforced
        • no god-object expansion
        • no hidden coupling

        If proof fails: stop and escalate. Do not patch.

        Gates

        • Step 0 GO/NO GO
        • Step 1 GO/NO GO
        • Step 2 GO/NO GO
        • Step N GO/NO GO

        Each gate:

        • exact thing being proven
        • explicit stop condition

        Test Plan

        Mix of:

        • unit fixtures
        • regression replay
        • smoke coverage
        • edge cases
        • negative cases

        Prefer: prove behaviour changed, not just coverage increased.

        Definition of Success / PASS

        Minimum acceptable state.

        Must describe:

        • observable outcome
        • old failure closed
        • contract enforced
        • ownership preserved

        Definition of Success / EXCELLENT

        Stretch target.

        Usually:

        • generalises across adjacent lanes
        • demonstrates reuse
        • proves contract not logging theatre

        Assumptions

        State assumptions explicitly.

        Examples:

        • baseline already proven
        • implementation surface bounded
        • no broad whitelist/regex fix

        Proposed shape

        Describe:

        • modules
        • packets/cards/contracts
        • ownership boundaries
        • interfaces

        Prefer: small typed objects.

        Thin leaf intent

        If adding logic:

        prefer:

        • thin leaf
        • compact return object
        • narrow ownership

        Avoid:

        • diagnostic fluff
        • local maxima

        Policy versus signal

        Policy: config

        Signal: code

        Config controls behaviour. Signal detects reality.

        Scope

        Explicitly include:

        • what this ticket covers

        Non-goals

        Explicitly exclude:

        • unrelated cleanup
        • opportunistic refactors
        • god-object growth
        • broad routing changes

        Acceptance criteria

        Numbered list.

        Must be testable.

        Definition of done

        Agreement on:

        • ownership
        • interfaces
        • config surface
        • enforcement point

        Only then may implementation tickets follow.