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