Let the chips fall where they may, and we'll have innovation along the way.
Discussion
Yeah, but fair game to point out that someone's new feature might be a bug.
Not every NIP is a winner.
Not every change is an improvement.
Sometimes developers just build stupid stuff because someone gave them a hammer and now everything looks like a nail.
1) Also, I think we're losing sight of how much the lack of complexity contributed to the success of Nostr, so far. That was feeding the innovation and kept the applications light-weight.
2) We're trying to build a SDK for a very simple, basic client, and it's a big ball of NIPs.
And now everyone is under pressure to implement edits and these stupid tweet forks, so they're going to want that in the SDK, so it will take us twice as long to finish.
Can you point me to your git repo?
I agree with you. There are so many NIPs.
We aren't publishing everything, until we're done, but here's a little sample he published in his personal repo, as proof of building.
https://primal.net/e/note1zf3udv3f7xl2tphsa2573hazcpesd5m56w7fs3z3vxgp3ver30lshg9j6a
Thank you for sharing.
We realized this was stifling innovation, by leaving smaller development teams with way too much front-loaded work, just to get a Kind 01 feed going and keep up with NIP changes, so they are often using SDKs and we think they need more SDK choices.
But now we're the NIP bagholders. Especially anything that messes with the Kind01 feed dramatically is like ugh.
What are some SDKs that help you build a client?
This is probably the biggest one
https://github.com/nostr-sdk/nostr-sdk-ios
This is just a client library, but probably also interesting.
I will look into these. Thankx
3) Throws new development back weeks or months, unless you do this full-time.
So, it feels like an attempt to shake off new competition, that was going to bring real innovation, through a form of protocol capture.
4) You know what I'd like to see? Threads. 🧵 That's something real writers often really like.
But the guy who wants to build it for me is now busy trying to figure out tweet forks. 🤦🏻♀️
Threads somehow are a huge blindspot for devs.
It was the n°1 reason why I liked Twitter.
I don't know 1 client that displays them properly, let alone incentives their creation on the "New Post" screen.
They gave us tweet-forks instead.
And now, they're like, "Please, clap."
I know someone who has the idea of creating article threads for a wiki. So that it looks like one long-form note, but is actually a collection of long-form notes in order.
So you could refer to sections, version sections, delete sections, comment on sections, etc. You could even include sections within your own articles, instead of copy-pasting the content. For instance, diagrams, tables, quotes.
Like the highlighter NIP, but the other way around.
Just to be clear. You do mean "collection of kind1 notes" right?
No, for an article-thread, you take a long-form note with markdown and split it into separate notes, by sections, that is held together by an index note.
A tweet thread would be Kind 01 notes, linked together as a collection.
I'm just saying that you could do it with either type of note. The use case is the same.
Aaaah, I see!
That's exactly how books should/will work on Nostr btw. Forgot if there was s NIP for that yet.
And you can go as granular as you want with a tree like that I guess.
Yes, the author can determine the granularity. It's a design decision.
I tried to publish some post-copyright books as long-form articles with footnotes and index, but habla had a meltdown because the doc was so large. I spent hours editing it as markdown, and testing all the links carefully, very frustrating.
I still have them, but I want to use my friends' wiki format to publish them, so that I can break the bits down and publish them as separate chapter-notes, joined by an index. Or something like that.
I do a kind of book-club on here, with old texts, and I'd like to host the texts on relays. That was the motivation.
I can't find a NIP for it. You would think there'd be one, since there's lots of demand. 🤔
Mmm, weird indeed. I thought nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk had a similar proposal for docusaurus-like implementations at some point. Will check.
Definitely seems a simple one and is for sure in my top 10 of "need this asap".
Me personally I'm a threads hater... It's basically just a blog post split into > 20 different chunks. The reading experience on Twitter was terrible unless you used TwitLonger to turn it back into a continuous text again.
Nostr has long form content which obviates the need to do this in the first place. Having the thread as a single article in markdown with headlines and such is about 1000x more pleasant to read IMHO.
You can just have an option to read it, either way. 🤷♀️
The goal of threads is to allow people to interact with specific parts of a longer entry, and to encourage writers to think in concise ideas.
💯
Take away those limits and you remove the high signal great threads typically have.
Displaying them as a actual threads also offers the most efficient ways of interacting and sharing.
However you choose read them, if that's your main goal, is up to you (especially on an open protocol).
I can imagine someone would want to read it as an article, but respond to it as threads. That could be handled by a toggle.
I guess I could write a NIP PR for this. 🤔 Don't know if there is one for threads, already. Have to go look.
No need for a NIP for this.
It's up to each client to pick how and in what order they show kind1's.
Thread = an npub commenting on his own kind1's, basta.
It's a bit more complicated on a decentralized platform.
1) There needs to be a base K01-note and reply K01-notes, that are all published at once.
2) The reply notes need to stay in a specific order or be numbered (1/5), otherwise it gets confusing because clients reorder notes and there's no clear way to tell which note came first, except maybe timestamp.
3) they need to be identifiable as a cohesive thread, so that a change from thread-view to article-view doesn't accidentally pick up more replies from the same author in the same thread.
This could all just be done with a tag, or some standard keyword in the content that clients could choose to interpret or ignore.
Long-form threads would probably require an index. Be too messy, otherwise.
But, you're right. No need for a NIP for K01 threads, since it could just be ignored and displayed as note-with-self-replies.
Timestamp fixes all of this.
Clients can choose to display all replies from the same author within a certain timeframe as the main thread.
And I would even prioritise later replies from the same author too.
You would have to time the publishing, then. I think the time-stamp is seconds.
1. Time period can be quite long (days or even Infinite). Not sure what Twitter had but you could make threads longer days after the first post.
2. The thread creation tool is everytjing. 
This is one example I made way back. Typefully and Threads (meta app) also nail this.
lol : "you're a poet and you don't know it"