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.

Reply to this note

Please Login to reply.

Discussion

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.

I don't disagree long term.

I'm just not bootstrapping long form with 50 standards.

Asciidoc does it all for me, for now.

From there its market demand that will lead the way.

Long form was already bootstrapped with Markdown on NIP-23

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.