You think "complexity" is "proliferating standards and granular tags". I think that is the easy part. Complexity to me is made by force-sharing and re-using incompatible but similar specs just to avoid duplication. That's the real complexity. Forcing existing kinds/content types that were not made for it into a given user experience. That's the real complexity. The number of NIPs is only a complex thing if your goal is to code all of them. If your goal is to just do one really well, then there is nothing complex about it. And most apps just need to do a few of them.
Discussion
You're right, my use of simplicity/complexity is backwards according to Rich Hickey. What I meant was that proliferating standards make room for complexity within a single spec. Using a single spec for multiple closely related UX's forces the spec to not be opinionated.
My point is that "doing something well" is subjective. Two clients might want to do the "same" thing, but differently. This requires agreeing on a kernel data format and diverging in how those clients infer meaning from what is explicit in it. Like, instead of prescribing that every thread has to exist on a board, just let threads be their own thing — they can be organized by nip 51 list, topic, nip 29 group, relay, author, whatever. I don't think we should be over-prescriptive in specs, because ironically it introduces complexity as different clients try to bend the spec to what they want to accomplish. This results in combinatorial complexity. While if the spec is very minimal, yes there are limits to the functionality, but those are well understood and can be managed.
I think open-ended specs have let to the worst UX and most terrible use of Nostr. Kind1 is a good example. We never really defined it. And it took 2 years to create a kind just for replies so that we stop using Kind 1 in everything with lots of variations on what clients support and what users expectation should be.
To me interoperability is defined at the user level. Not only at the technical level. If I switch "video playing Nostr clients", I should not expect things to work and be interoperable. But if I switch a Shorts client by another Shorts client, then all Short videos better be there. The need for interoperability includes the semantical meaning associated with the type of content, not only it's functional underlinings.
Many data structures that are the same are not supposed to be interoperable at all. And I think we confuse that a lot on the NIP repo (myself included)
Kind 1 is ugly, but it's also the kind that has the most users by far. This is the value proposition of nostr. I'd take ugliness with interoperability over feature-completeness without interoperability any day.
> The need for interoperability includes the semantical meaning associated with the type of content, not only it's functional underlinings.
That's exactly my point. It's not about keeping specs DRY, that's insanity (in code as well as in specs). It's about optimizing for interoperability by focusing on semantics, rather than functionality.
I think that is the issue with 7D. It's too dry.
It's not DRY, because there's nothing to repeat. DRY is about code re-use. 7D is just a stub. I anticipate new tags, events, etc.
Sure, but if so what's the end goal for the 7D? If people already coded it, and the end goal changes, that might be a very difficult issue.
That's why I like vertical NIPs more. You set up the goal and layout the basics and within that use case framework everything can change as the implementers progress.
I don't think 7D can do BB boards and Slack/Discords at the same time. It just doesn't make much sense. The discussions on a BB are not chats and are also not threads. They are almost like Mailing list discussions (heavier content/message), but not quite.
Having something already implemented is a good thing. It forces a minimal kernel, with progressive enhancement. If that's impossible to accomplish the next time, sure, create a new standard. But ideally NIPs are extremely easy to support, with lots of optional stuff.
> I don't think 7D can do BB boards and Slack/Discords at the same time.
I still think you're letting existing products dictate what we're building. It's ok to invent new content types. What exists is a very small cross-section of what makes sense, and in many ways the wrong one (which is why we're here in the first place).
> The discussions on a BB are not chats and are also not threads. They are almost like Mailing list discussions (heavier content/message), but not quite.
I'm not sure what you mean by threads here, but I basically agree. BB-type "threads" were what I was aiming at with 7D. My goal is to have a non-chat place within communities where more substantial conversation can happen, not a twitter-post-type thing. I really think your spec is the same thing, just more developed, and of course with markdown support. But unless tables or your specific way of organizing content are essential for forum posts (I don't think they are) I don't think there's any incompatibility.
In the end, I think different BB forums will need different markdown supports. Coders will even need highlighted code blocks. A Scientific forum will need support for latex equations and maybe even full latex instead of Markdown.
So, even the kind I proposed will be broken down into other kinds later, when the need arises.
Similarly, I am sure there will be an AsciiDoc kind for BB systems as well as a BBCode kind in time.
Those are all going to be sub kinds into the same NIP for different BB systems that should not really see each other's data.
> On the existing products..
I like to talk about existing products exactly because it highlights how different things can be. And they already have product/market fit. So, it's less assumption, more reallife data. But of course, I support new products as well. They just need to prove they are what people want before spending too much time in it.
The point of going for Asciidoc was to not have to bootstrap all this with 50 flavors of markdown.
I already have code block highlights in my renderer.
It's not that hard to have a satisfying standard for 80% of common use cases.
Beyond that I mostly need Communities to recommend apps that handle that standard well regarding their niche topic/goal.
Yeah, I don't see a future where we are AsciiDoc-only. Or any other format for that matter.
Different apps need different things. There is just no way around it.
That doesn't mean all apps must support everything though.
Each interoperable group of apps should pick the format that best suits them.
Design it first guys.
And start with the very basics.
I'm only designing + building for:
:thread: threads
:article: articles (priority to modular)
:wiki: wikis
:chat: chat
Until you have customers actually using your communities beyond chat and finding these textual content types lack something, it sounds very naive to start imagining all these extra kinds.