How would you handle version control with immutable notes?
Discussion
Because every note has an identifier key.
You have a nostr account for each application, and that account publishes a signed note that links to all the code containing notes.
A new application version is just a new account note, all previous versions are just that accounts past notes.
You can compile an app made of any code notes from any contributor.
It’s signed by the key that controls the nostr account.
It’s ridiculously simple.
I understand that, but how are you conceptualising the handling of what’s in versus what’s out? The differential.
A separate kind which references included versus excluded nevents signed by the app’s key?
Say my account is an app, I would publish a not that looks like this…
*****
Version 1.0
File 1 @nevent000001…
File 2 @nevent000002…
File 3 @nevent000003…
[…]
*****
Then say I modify the code base (I only change file 2), I publish a new note that looks like this…
*****
Version 1.1
File 1 @nevent000001…
File 2 @nevent000017…
File 3 @nevent000003…
[…]
*****
I have modified file 2 and so I just publish a version 1.1 note from the account with the modified code note included as a link.
For users to update their software they just lookup the nostr account, find the latest published version note and retrieve each of the file notes.