Yes. two approaches: 1. git's `iterdiff` could be used to generate this within ngit and submit it as part of the cover letter (if one is included). There is too much duplication here and there is no garentee that PRs will include this as they may be generated by other tools. 2. apply the patch and output the diff. this could either be done in browser or by a proxy. Ideologically I don't like the idea of being overly reliant on a proxy as I think reliance on back-end infrastructure reduces the simplicity, robustness, and censorship resistance nature of a client. It looks likely that gitworkshop.dev will do a *shallow clone in the browser to deliver files and other git information. Experimentation is needed to see if PRs can be applied without checking out (and downloading) just the reliant files to the PR rather than all files in the latest state. Otherwise this could be bandwidth intensive for the user. Another possibility I have been thinking about is having nostr specific git implementations (like song) apply PRs submitted so the commits could be downloaded via the efficient git protocol and potentially could be used to access the PR diff in a bandwidth efficient way. Ultimately it would be ideal if we could do approach 2 with everything done in a bandwidth efficient way in the browser. *for context see View quoted note →

Yeah, #1 would probably blow up the even -size, as well. They're already quite large.

With the song, you mean have it be a sort of automatic proposal-puller? Would we need an instance per repo or per gitworkshop? Like, if we hosted song and gitworkshop, then it would be our own song, and otherwise you would provide a central one?

What do you think about #2 @ChipTuner @Finrod Felagund @MichaelJ ?

Yes. I think I've mentioned it before but I'm planning on using blossom as a fallback for large commits that result in events that are so big relays won't accept them. I think this is the bestway of doing it without relying on the contributortoo indefinitely host a git server with the patch on it. This does add complexity and depending on how it was handled in the interface, effect other NIP-34 clients as they may no longer be displaying all PRs submitted unless they add at least partial support. I'd love to get the input from your team on this. Could I join one of your dev calls to discuss it with you?

I'm definately not interested in hosting a central one as I don't want to create a point of centralisation and I do host content. You wouldn't need an instance per repo but you'd need to use an instance that you or someone else is hosting and allowing your pubkey to write to. What in suggested would just make pulling proposal commits marginly more efficient. Thinking about it, probably only if the commits where too big for events and you had to use an alternative like I just mentioned with blossom.

Could we arrange a Corny Chat, with the four of us + @DanConwayDev? Maybe for Sunday evening, 19:00 UTC (that's 1 pm in Texas and 8 pm in Germany)? View quoted note →

I can't do this Sunday

I kinda like the song idea better, as it seems like it has more potential for further development. I mean, if they had no song setup, it would just revert to the current state, which is fine for most npubs.

8 pm -- 10 pm is fine for me, any day of the week. I can also do 6 am, our time, but that's then in the middle of the night for the Americans.

Is that UTC?

France/Germany is UTC+01

I can make a call during those times most evenings.

Totally down to join a call on this! For #2 I think all content should be in a uniform place, ideally that would be relays, but of course blob-sizes would hit a maximum, I'm not sure what limits are but I have dozens of source files over 100KB for what it's worth. As much as I like dumb clients (especially browser based), I understand the idea of reducing server dependence, specifically non-standardized communications. I have a lot to chat about but my lack of in-depth knowledge of git makes it difficult. So many ideas, likely so few of them relevant XD

I can do most days 11pm-12am CDT (6am-7am CEST). In the meantime, I'll make a note to myself to read up on git diffs to be sure I understand the proposed solutions.

Hrm. That's 5am for me which is a little early. I could do an hour later?

That's past my bedtime 😅

Do mornings work for you?

8-9am CDT usually works for me. I could probably pull 7am CDT as well.

8am CDT works for me

What about @Silberengel?

I need to carve out some time to familiarize myself with all the various things. I really haven't had time to check out things like Alexandria and gitnostr. I feel like I am missing the bus on so much that is going on.

this feature request is dependant on