We should get back to discussing important things, such as markdown in kind 1 notes. Just basic bold, italics, underline, bullets, quotes, code blocks, etc. for formatting.
*ducks*
Discussion
Look at Nostur handling those italics like a champ 🔥😂
Nostur is top notch.
💯 It's become my primary app on iOS. Excellent features. Primal keeps shipping great updates too but the lack of NWC/external wallet support in Primal iOS leaves a major gap in functionality. The integrated wallet there is good but would be nice to have options. I hope they can add it back in at some point.
I don't know if they'll be able to do that on iOS, because of Apple's policies. On Android we have those options though.
after a long hiatus, I'm back.
What's the coolest tool or service that you're building right now? 👀
I'm building some microapps right now, which is keading up to rebuilding nostr.watch.
https://github.com/sandwichfarm/myrelay.page is the one from last week
Wow 🔥 will definitely test your app!
🦆
That'd be nice. I miss being able to quite easily.
YES #YESTR
Here's a simple and visually appealing representation of some Markdown formatting techniques you mentioned:
```markdown
**Bold Text:** This is an example of bold text.
_Italicized Text:_ This is an example of italicized text.
__Underlined Text:__ This is an example of underlined text.
- Unordered List:
- Sub-list item 1
- Sub-list item 2
1. Ordered List:
1. Sub-list item A
2. Sub-list item B
> Blockquote: This is an example of a blockquote.
```code
```javascript
// Code Block
function add(a, b) {
return a + b;
}
console.log(add(5, 3));
```
This is the generated image using the `
[
)]()
Testing in Nostur, not 100% certain my formatting is correct. Because the above is an image.
**Bold Text:**
_Italicised Text:_
__Underlined Text:__
- Unordered List:
- Subitem List
- Subitem List
1. Ordered List:
1. Subitem
2. Subitem
> Blockquote:
code
JavaScript
// Code Block
function add(a, b) {
return a + b;
}
Them's fightin' words sir 🤣
I miss markdown, but our CEO doesn't like it.
Isn’t that the beauty of Markdown though: that you can use it whether or not the client decides to render it prettily?
Richly-formatted text could have lots of Markdown syntax, so any clients that don't support Markdown automatically give a worse user experience.
# `@rjk`'s thoughts on Markdown in kind 1
Admittedly, I'm not the greatest test case, as I live in a world where I see a lot of raw Markdown in plain text files and am quite accustomed to it. IMHO, "worse" is still a *graceful degradation*, with clients that supporting it providing a *progressive enhancement*. I'll point out Gruber's original intent, although perhaps we've collectively moved on:
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
I agree, it's pretty readable as plain text *most of the time*. Links, tables, and the like get pretty messy, though.
Sure I can **use** it but it looks silly when it's not rendered properly.
what does the nip say about this in kind 1
It says markdown is not to be used, but some clients do it anyways. I don't want tables and other major things that can look messy. I just want bold, italics, and underline at minimum. Google+ had that and I've been missing it ever since Google+ shutdown.
Limited Markdown support like that would have to be defined in the Kind 1 spec.
Additional rich text formatting would be a perfect use case for a new event kind.
I don't think we need an entire new kind for it. Clients can choose to parse it and remove it or display it, like they do now.
Most interesting to me is that the markdown and HTML reference is only explicitly stated for kind 1.
Kind 0 in the same NIP may presumably have markdown or HTML or anything else needing parsed as long as its in the stringified JSON object. There are no restrictions on clients from parsing a kind 0 in this way.
Every other kind also allows HTML and Markdown and imposes no client restrictions
Rendered properly
I would be in favor. Yes please.
Indeed we should!
Just add a tag for content type and go nuts!