I want a relay for some of the OtherStuff documents like wiki pages that keeps n number of replaceable events, maintaining a working history, and then deletes the rest.
Maybe 10-20 events back, or something. Much more and it becomes an archiving service. Much less and I can't show any change history.
20 events sounds like a lot, but my event register is already at like 8 events, or something, within a week.
How do you query older events? since the protocol requires only the latest event be returned in this case? Maybe you need to draft a nip for archived events?
The events are still there, unless someone deleted them. Long-form articles are parameterized replaceable. You can just have the server keep n number of events or hold older versions for n number of months (whichever is higher).
>>events are parameterized replaceable, which means that, for each combination of pubkey, kind and the d tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.<<
So, you could say that you keep 20 replaced versions or hold one replaced version for 20 months.
As soon as they hit 21 versions, you delete the oldest, or you delete a version, once it gets past 20 months.
My logic here is that there are probably forks and backups of documents that change quickly and the other documents are only edited rarely and they need to see what happened last time.
the signatures must be fully retained, but the content can be compressed down to a series of diffs in the actual database storage format, if the concern is about efficiency of data storage... a compression algorithm will also automatically do a lot of this, but is more expensive than unpacking diffs
Yes, the events might still be there but the querying mechanism doesn’t allow you to query for older versions, it would break the functioning otherwise, there’s a nip that needs to be drafted that lets you do that. Or the relay needs to provide “out of band” ways to let you access the older events.
Don't need a NIP to do something. We can just do it.
I noticed some clients are more aggressive with sending replaceable events. Sending every small pause is input, so it would be important to discard events based on size of diff or something and not remove real history for incremental edits. Just from a desired outcome perspective.
Well, there are draft events, too. Only need to save the last one, of those, and only until it's published. Could also offer a client utility to see all draft events and delete some.
I might be confusing the two. I think they were added around the same time so I'm likely conflating then.
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?
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.
I think you are looking for git.
Yeah, just came to the same conclusion, lower down. 😂
i'm not sure if git is precisely suited to single documents though, that's kinda overkill for the multiple files, but for sure the same principle, it would be a block graph of sorts (you could have forks and joins)
