Rendering markdown is an anti-feature, kind 1s should be plaintext

Reply to this note

Please Login to reply.

Discussion

So, help me understand...?๐Ÿ™๐Ÿป๐Ÿ˜ƒ

Is the idea to segregate longer form, formatted articles to separate venues?๐Ÿคจ๐Ÿค”

Partly, kind 30023 is intended for long-form. The other is that adding formats to kind 1 increases the barrier to entry to new clients. Plain text makes it easier to develop on nostr.

TY.๐Ÿ™๐Ÿป๐Ÿ˜ƒ๐Ÿ’œ๐Ÿ’–๐Ÿ˜„๐Ÿ‘

How is it an anti-feature?

I would think you can just transmit the plaintext and just leave it up to the client to render the markdown?

I think I can understand if the concern is related to any of the following:

- bandwidth

- added client complexity

- it's not the intended use of the protocol

Yeah, client complexity. There's always been talk about defining some subset of markdown that qualifies as plaintext, but it's never been done. Markdown links and images, (not to mention tables and html) don't really qualify.

long live .txt

I probably shouldn't opine given I don't fully understand the protocol. However, after thinking about it I don't think it's necessarily a good idea to add something like that to the spec.

Please correct me, but I thought that there was a range of kinds that can be used at the discrestion of the client?

If so, a client could have markdown and use event kinds that are unique to that application.

Yep, I think that would be totally fine