I feel like Github PRs should be replaced by clientside local-first tools. A PR -> some signal that requests merging a branch onto a target branch PR review -> re-use the same signal as above, submit PR atop PR branch Now diff hunks need revision controlled comments. Done.

/remind myself to check out the new release of @radicle_xyz which aims at local-first decentralized revision control including ticketing and branch-collaboration...

Clarification: a "diff hunk comment" aims at fulfilling the functionality of a GH review comment: It is tracked in revision history, annotates a hunk (e.g. "this API fn has to be async" where the following hunks convert the function), and does not appear in code.

I would not be surprised at all if git already has this build in somewhere (under layers of complexity), since it is very close to the "email patches to collaborators" style that is closer to git's roots. The twist is revision control of diff *comments*.

Clarification 2: The original submitter can respond to the "review PR" by either accepting the diff, or by creating a third PR atop the review PR (a response-to-review). This ping-ponging continues until the parties both accept all the edits. The interaction is saved in history

ps: I'm hacking on a decentralized local first revision control tool as a hobby (~year to ∞ ship date). I'd want it to support these use cases: - PR process as above - resolution can produce a "squashed" single change as part of the "narrative" - full history still available

@lftherios @radicle_xyz @radicle I love leaf-node decentralization, but as a user 85% of apps I use vendor hosting, and if it's not out of the box, I often give up before setting up my own infra.

@lftherios @radicle_xyz @radicle Vendor hosting w/ subscription, open source infra, no-lock-in export capability is my kryptonite combo for paid apps. So my current feedback (from memory) is that I wished I could subscribe to hosted highly available node that replicates all of my repositories.