Oddbean new post about login | logout I don't like that many clients pick up my kind30023 posts as if they were the news of the hour andput them right in my feed every time I write something or even do minor edits. I see these two kinds of posts as very different. The long-form stuff is supposed to just sit there for people interested in reading them at whatever time they see fit, while the microblogging notes are more like shouting in the middle of a public square. Since I know that clients will get any article I write and show it to everybody I follow immediately I end up not wanting to write them anymore. Maybe allowing people to choose if they want to "shout" about a long-form article instead (by publishing a kind1 note that quotes it) is better than the current state of things.
Agree! I have a similar experience. I usually do like 10 or more edits after submitting.
Completei os 3 passos do arata.se/gn01
I agree Also I'm not sure which clients support long form. So when I do post, especially when, I want it to be seen by followers I typically also post a kind 1 to ensure it is seen.
That makes sense. Gossip added these to the feed but has it off by default. They are better served by blog reading clients. Maybe we can mark them more clearly as blogs or even blog edits so that people don't infer that you are intending to shout-up-a-conversation right now.
I agree that long forms should be shown with some care. There is also a readability issue: showing an article among other small notes in an endless scroll is a mess and devalues the content. But I also think it is important to promote this kind of content in generic clients, because they are definitely the ones with a higher effort factor, so they usually have interesting value. As a basic suggestion, I would list them in the user profile in a separate view (e.g., "blog"), and always open them in a dedicated view. Clients could then implement an opt-in and per user option to alert about new long form content, such as including an abstract in the feed (rss style) or showing a mark on the user's profile. /cc @hodlbod @M. Dilger
Of course kind 30023 should never been showed. Editing a document is mostly an internal affair, tracking real-time changes is a quite specific need that should require a dedicated tool.
Replaceable events are stupid, that is the root of the main problem here. That aside, I agree with nostr:nprofile1qythwumn8ghj7cnfw33k76twv4ezuum0vd5kzmp0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qqs8hhhhhc3dmrje73squpz255ape7t448w86f7ltqemca7m0p99spgk7dgad that a way to announce or advertise a blog post would be better than picking the posts up directly.
I don't understand why you hate them so much. What is your proposal? To do "delta" events? I don't think that would work at all unless you assume you're always getting all the events in order, which you definitely can't in Nostr. What do you think? Not to mention the bandwidth and storage issues that come with this, and client-side costs of processing a big chain of diffs all the time live. Of course replaceable events are not theoretically perfect, but they work pretty well as long as you don't overuse them.
Yeah, it's just that they break the event sourcing paradigm. If you stick with that, everything else can be solved using some optimization or other. Reactions are far worse bandwidth-wise than diffs or edit events. It would have been better to do some sort of edit event, but that ship has probably sailed.
nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gfnma0u 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.
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.
We already can't make it work with replaceable events, imagine having to fetch an unreliable stream of events from an unspecified location. https://image.nostr.build/f7c47b6b2e14db8ef0416ff2285d4987dae2c01ba305f267fb4b23e908ec8eb7.jpg
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.
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?
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.
NIP-28 used this approach, which I believe I had a big part in developing there at the time. Now to me it looks ugly, dirty, disgusting, a very bad idea. I still don't get why referencing an initial event is better than using the "d" tag. Both are arbitrary strings ultimately. About not losing history, again, that's the same point from before: it has costs. Also if these multiple versions were treated the same way normal events are today it would break the relay query language, as if you wanted to fetch multiple statuses from people, for example, you would end up getting multiple old status for the same person and none from some others that hadn't updated in a while -- and so on.
And then again it's not very clear what we're getting from this. For example, in the "update" event approach the same problems of contact lists remains: one client can overwrite an update event from another client and people lose part of their contact lists. In the case of "delta" events then you must ensure that you have the full history, which means you must know the exact relays to where a person is publishing their deltas -- but if you are diligent enough to know that and you have successfully written more complex software able to handle that, then why can't you do the same for replaceable events today and fetch the damn last-updated contact list from a relay that you know will always have the last version before replacing it? I think your suggestion of having replaceable events + delta events (I don't remember the details) could have been a better approach actually, as it would preserve the best aspects of all worlds, but I'm not sure about the implementation complexity of it.
Your point about queries getting duplicates which crowd out some desired results is a good one. You could technically send one filter per pubkey with limit 1. Lists should not have create/update like blog posts, they should instead have set/add/remove, which combines diffs and replaces in a conflict-free way. From the perspective of event sourcing, projections should be a different layer from events. We have all this weird awkwardness because we have only one layer. I'm planning to work on some basic layer 2s via DVMs in the next month or so.
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?
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.
Personally, I don't dislike replaceable events, they seem a fairly logical transposition of "revisions". I suppose replaceable events are less fragile than a diff chain; all it takes is one missing event in a chain and the update is aborted, or am I missing something? Instead with replaceable events we can loose old updates (casual or by relay pruning) and still have the final version. However my perspective for now is too theoretical, I need to deal with more edge cases.
prime example of the clown show that is the rockstar devs who are making dumbass architecture and API decisions for #nostr protocol and why it's retarded that a) there is no markdown as a secondary type of plain text and b) no diffs to update/edit posts instead of deleting old ones with "replaceable" event kinds of course there is a logic for checkpointing changes at some point to eliminate losing the originals once in a while (like how video encoders usually have a complete image every so many frames) but the normal modification method should be diffs, and obviously the diff should be on the signable form (which they also clown show haven't made a proper name for: hint: it's called "canonical) this is how you know that the majority of #nostr devs are under 30 years old and mostly have not had more than a year of systems programming experience nostr:nevent1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hszrnhwden5te0dehhxtnvdakz7qghwaehxw309a3xjarrda5kuetj9eek7cmfv9kz7qpqmv2lvtdz7ckyur95sxvfqtkepj3efdvumt9kzf0lkh9xdjk5xcssk98nt8
I actually like this idea. Of broadcasting the "announcement" of the article to everyone in a Kind 1, that then embeds a link to the full article. I don't think we should be afraid of segmenting types of content to certain relays. I think that's the best way to scale in an efficient way and recreate a stack of applications and use cases via a protocol that separates them from platforms. I think this is a decent segmentation tool, and I've had a similar feeling myself about the articles. Not that I wouldn't write them, but that I want them to live in a way that the entire network sees it, but that it doesn't necessarily show up as a huge note in front of all of my follower list. 🤔🤔
Sounds to me like a client-side problem. If it’s a bad experience to dump long-form content into the feed, then clients should stop doing it, or at least give the user the choice via a setting. Segregating notes to different relays by type feels like the wrong layer of the architecture. Clients that present data wrongly will happily continue doing so connecting to more relays rather than fewer.
We need not have happened. Fathom. https://www.newsweek.com/donald-trump-iowa-speech-cnn-msnbc-1861186
