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
    201·
    2 days ago

    I lol’ed (lolcatted?) but isn’t the better solution not to accept PRs from unknown / untrusted sources - ai or human?

    Additionally, Codeberg is actively hostile to crawlers and ai agents isn’t it?

    Still, this is funny. Not sure Claude would fall for it, but funny anyway.

    • hoppolito@mander.xyzEnglish
      22·
      2 days ago

      isn’t the better solution not to accept PRs from unknown / untrusted sources

      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.

      • 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.