Or do you mean we should allow major and minor versions? 🤔
So that they can determine which ones should be archived? Otherwise typo-corrections would fill up their allotted versions, correct?
Discussion
nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn nostr:npub1ecdlntvjzexlyfale2egzvvncc8tgqsaxkl5hw7xlgjv2cxs705s9qs735 nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 nostr:npub1cpstx8lzhwctunfe80rugz5qsj9ztw8surec9j6mf8phha68dj6qhm8j5e nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Can we have an additional tag, or something?
no, your algorithm needs more logic than just flat 21 versions... for this particular issue either the diffs i talked about or a fuzzy match to discard the older versions of minimally changed, the fuzzy match would entail doing a diff in any case, the actual diff storage is a bit more of a complex task, since it's like 10% of what git does
Maybe I'm thinking the wrong way around and the relay should have a git server and decide what to delete that way.
Like, maybe this is one of those relay admin events, you were mentioning.
yes, it would mean having two different event stores too, forking from the abstraction, that branches according to purpose...
i think that for this there needs to be some kind of chain of association or top level id, like, the first version ID should be a tag that all versions share...
i've talked about this idea and it's penciled into my ACL administrative events code that i haven't finished yet, a "blockchain" back-reference "replaces" is the tag i've suggested, i think it has many uses throughout, and especially for all kinds of replaceables - parameterised replaceables would be faster to associate if they had these as well since they are multiple
I think they're just going by time stamp, at the moment. nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn was working on events to track versions as a chain. I think it was similar to yours.
i hope we get blockchains on nostr... because that's what they would be, and nothing to do with consensus, just tamper resistant chains of events, they would also make it easy to know when a version has gone missing as well
You. Me. Same page.
Haha, the exact same...
Now, all we need is ssh with nostr bip340 signatures and you can push and bump the update on protocol, and then you need a http/s git interface, like the one https://mleku.net uses and a simple mirror protocol that watches for the events to duplicate
It can do whole filesystems then too
nostr:npub1tcekjparmkju6k83r5tzmzjvjwy0nnajlrwyk35us9g7x7wx80ys9hjmky since I see you, my last autozap didn't work for you. Is your wallet online?
Oh thanks for the poke! Lemme check.
Found the issue. My tor address was not working as expected...at all O.o
To be fair my tor daemon lives on another server, chances are it is not quite liking that lol.
Done! Decided to forego the Tor in my kubernetes cluster for the time being. Should be reachable again in a little bit when tor starts to pick up on circuits.
I think a new tag "keep" or something like that could be a good hint for relays that they should keep that.
But what if a buggy client starts spamming "keep" tags every second on a replaceable?
Yeah, something like that. I don't need a version for every third character, but if I finish a section or add a meaningful amount it would be useful if some relays maintained that history.