bold and italics #58

New issue

Open

opened 2025-05-17 00:52:20 +12:00 by melvincarvalho · 1 comment

melvincarvalho commented

2025-05-17 00:52:20 +12:00

(Migrated from github.com)

Markdown is frowned upon in the NIPS. But I was wondering if nostr next could have bold and italics at least?

Perhaps even rendered lists?

Markdown is frowned upon in the NIPS. But I was wondering if nostr next could have bold and italics at least? Perhaps even rendered lists?

mikedilger commented

2025-05-17 09:57:55 +12:00

(Migrated from github.com)

I am not against markdown (in a well defined variant) in social media posts.

I think in nostr, fiatjaf wanted to preserve as much simplicity as possible and requiring all the clients to generate and display markdown moved nostr further away from "simple".

But IMHO, simplicity is killing nostr. It is so simple that we have lots of "simple" developers providing underwhelming software. I agree simplicity is important, but I differ on the degree. I want it less simple (binary, markdown, QUIC, DHT interactions, in some cases two ways of doing the same thing, etc) but still well defined and not complicated. That would yield fewer pieces of software, with perhaps each piece being very robust.

Also, 'nostr-next' is just a "bucket" where I throw things. It is not actually the next version of nostr. I have no authority to define the next version of nostr. But I guess if more people throw ideas into this bucket, maybe it will become a shelling point for a successor to nostr.

I am not against markdown (in a well defined variant) in social media posts. I think in nostr, fiatjaf wanted to preserve as much simplicity as possible and requiring all the clients to generate and display markdown moved nostr further away from "simple". But IMHO, simplicity is killing nostr. It is so simple that we have lots of "simple" developers providing underwhelming software. I agree simplicity is important, but I differ on the degree. I want it less simple (binary, markdown, QUIC, DHT interactions, in some cases two ways of doing the same thing, etc) but still well defined and not complicated. That would yield fewer pieces of software, with perhaps each piece being very robust. Also, 'nostr-next' is just a "bucket" where I throw things. It is not actually the next version of nostr. I have no authority to define the next version of nostr. But I guess if more people throw ideas into this bucket, maybe it will become a shelling point for a successor to nostr.