Monero integration stuff can remain in the bin where it belongs.
I’m still a fan of nostr:npub1w4swqedal6gcw23ndd93tkkdy3zj2l6zjdjvzrhu8rnw0k8lc8lswzprhz GitHub replacement concept
Monero integration stuff can remain in the bin where it belongs.
I’m still a fan of nostr:npub1w4swqedal6gcw23ndd93tkkdy3zj2l6zjdjvzrhu8rnw0k8lc8lswzprhz GitHub replacement concept
It would be quite easy and sinple to store code on nostr. Complete with version control, permissions and forks, but everyone then said they would never leave Git.
How would you handle version control with immutable notes?
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.