Thread - Nostr Hypermedia

hodlbod hodlbod@coracle.social 1 year ago

@fiatjaf I re-broadcasted my note. To actually answer your question, probably the best solution would be a full in-place "update" event as a separate kind with an `e` tag pointing to the original "create" note. This way you you don't have to trace a chain of diffs, just look at the timestamp, and you get verb semantics. This would only be a problem if a blog post had a million revisions, like if a client spammed a live draft as revisions. 5-10 revisions is a lot for a blog post, and easy to process. I do still think there's a place for "annotations" that clients can display in a privileged position (the use case being updates at the bottom of a blog post, corrections, etc). Diffs are way more complex, and dependent on each other, but also probably unnecessary for blog posts.

↑ Parent

Replies (8)

ben ben@northwest.io 1 year ago

I like this idea. I previously worked on graph systems and this is how we handled revisions- changes were stored in new nodes with edges back to the original. this model works well with event sourcing.

fiatjaf _@fiatjaf.com 1 year ago

Imagine you're browsing a feed and your client fetching metadata for all those people on the fly. You can either fetch an event for each or you can fetch 20 events for each and reduce them to a metadata object by applying diffs locally. Do you really think the second is the best solution in the real world? Also, since you're just fetching random people's profiles you cannot ever be sure (or how could you be?) that their sequence of diffs is complete. You would actually need a blockchain to be sure.

2 replies ↓

fiatjaf _@fiatjaf.com 1 year ago

How is doing "update" events any different than bare replaceable events? You still get a single event in the end that replaces the previous ones, right?

1 replies ↓

fiatjaf _@fiatjaf.com 1 year ago

We already can't make it work with replaceable events, imagine having to fetch an unreliable stream of events from an unspecified location.

fiatjaf _@fiatjaf.com 1 year ago

Nothing prevents relays from storing all revisions of a replaceable event today. Would you want to do it if you were running a relay? I wouldn't, unless the user was being charged for each post individually. Would the average user be happy to pay for storing every single edit they made in a post or on their profile or every time they switched to listening to a new song and that updated their NIP-38 status?

1 replies ↓

hodlbod hodlbod@coracle.social 1 year ago

I think a history of statuses over time would be cool. I didn't even realize that was a replaceable event. A history of profile edits would be less useful, but how often do you update your profile? The ratio of kind 1's to kind 0's would be probably around 100. Replaceable events are "good" for infrequently updated things, because otherwise you run into collisions from multiple devices updating the same list or what have you. Which means the volume isn't significant. But if the volume is, replaceables start to break.

1 replies ↓

hodlbod hodlbod@coracle.social 1 year ago

Yes, but you have an event id that serves as the handle, rather than an `a` tag. Replies would tag the update event, which tags the create event. Since the updates don't replace the create, the create is still accessible, so you can pull all events, or just events for a given revision. No data is being deleted, so clients don't have to guess. Right now, replies that only tag the `e` tag of a given revision get lost when the post is updated.

1 replies ↓

hodlbod hodlbod@coracle.social 1 year ago

I wouldn't use diffs, I would just grab the most recent event and use that. You might occasionally miss the correct one, but with caching you'll eventually find it and hang on to it. DVMs can do a lot of the heavy lifting with bigger caches for stuff like this to reduce computation and bandwidth client-side. In my mind, DVMs are just nostr clients that run on a server.