Thread

🛡️
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.

Replies (12)

🛡️
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 @Mike Dilger ☑️
🛡️
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 View quoted note →
🛡️
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. 🤔🤔
↩ replying to Guy Swann
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.