There's not really a nip specific to blog posts. A blogging app that has tools like the long form apps would be cool. But without a specific kind, it would just be another long form app.
Discussion
What would be the distinction between long-form and a blog? Isn't a blog just a specific type of long-form content? That being the case, why would the existing note kind not suffice?
Because my blog entry isn't an article. It's a blog entry. They're very similar but different use cases for formatted text. Why aren't books just long form notes?
Articles and blogs are far more similar to one another than articles and books, for one thing. For another, you can just write long form articles as blog posts and they will 100% function as a blog. You can even have them presented exactly that way using npub.pro.
Now, if you want to write both blogs and articles under the same npub, and have them presented separately, you would need to have two separate kinds, or else just make two separate npub.pro sites, and manually import the blog notes to one and the articles to the other.
So because they are similar, they are the same? Say I want to make a client that shows people and their blogs. Not people and their articles and blogs. How would I do that?
Your second paragraph is my point. Blogs and articles should be two different kinds. Sorry to come off brash.
I think I see the point now. Not so much for the sake of having your own blog, which is pretty easy to do with the current long-form kind, but for the sake of having a client that only shows blogs from various users, and doesn't show articles at all.
That would probably require a separate kind, though I would be hard pressed to determine what makes that kind definitionally different than the existing kind, except that people are supposed to put blog content into it rather than articles.
There would still be nothing stopping someone from writing an article using the new kind that is intended for blogs, and then you have articles showing up in your blog client again.
I would require a new kind. But I think it's warranted.
That's exactly my point. Users can write formatted kind 1 even though no clients render the markdown for kind 1. Yet people don't write articles as kind 1s. Because articles exist. If blogs existed, I didn't think there would be many people using them for articles.
Regardless, users look for blogs or articles. Never is someone looking for a website that shows them both together. Right now, that's what all long form clients do.
I wouldn't be quite so optimistic about folks immediately gravitating to a blog-specific version of long-form notes.
There are obvious reasons why users would prefer to have a note kind other than kind 1 for long-form content. Kind 1 is defined as plaintext, for one. There is no expectation that clients will render any markdown syntax found in kind 1, though at least one does. Rather, the expectation based on the spec in NIP-10 defines them as simple plaintext notes. There is no place for a title, either. Nor are kind 1 notes intended to be replaceable events, supporting editing. For all of these reasons, kind 30023 has obvious advantages for those who want to post long-form content over just using kind 1, with the only drawback being that the long-form notes typically do not appear in the same feed as kind 1 notes, but then again, many people see this as an advantage, since they don't want their feed of kind 1 notes interrupted by long blogs or articles.
The above would not be the case if we differentiated long-form content into separate kinds for articles and blogs. Not unless you are proposing some features that would be available for blog kinds that are not currently available for long-form. Is there anything that would attract people to using this new event kind for blogs that isn't already present for kind 30023? What features do blogs need to have available to them that aren't already available in kind 30023 such that users would move over to using the new event kind instead, the same way that they naturally want to use the features available in kind 30023 instead of being stuck with the limited features of kind 1?
Would the spec for blog posts essentially just be a copy/paste of NIP-23, but with different kind numbers, or would there actually be different features to attract bloggers to using that event kind instead?
Now, there is something to be said about a particularly good client focused on a specific type of content having the ability to popularize an event kind that doesn't really add any new features compared with already available kinds. For instance, Olas has popularized kind 20 despite the fact that almost all kind 1 clients will render images posted as URLs in kind 1 notes. There's not really much that you can do with an image in a kind 20 note that you can't already do with images in kind 1 notes, and arguably they have less flexability than kind 1 and are not typicly displayed in the same feed with kind 1 notes, reducing the number of users who are likely to see the post. Yet, a lot of people now prefer kind 20 for posting photos, because Olas is a beautiful client for browsing photos by themselves.
Yet, I think this is an exception that actually proves the rule. Users like to browse images separately from text notes. They are familiar with that experience from using Instagram, which Olas is very intentionally emulating. However, when it comes to long-form content, the existing equivalents are Medium and Substack for long-form displayed in a feed from various authors, or Wordpress for long-form that is from a single author. In all of these cases, you can encounter content that would be better described as an article, and other content that would be better described as a blog, and other content that is hard to define as precisely one or the other. There is no clear dilineation like there is with images. Everyone can immediately appreciate a feed filled with nothing but images, and maybe a caption along with it vs a feed that is mostly text notes with the occasional image or other content thrown in. That's not quite so easy to separate with long-form written content, where there are articles, blogs, blogticles, artilogs and everything in-between.
See my other suggestion. Don't need a new kind. A new tag would suffice and not break anyone previous and old events could be replaced if wanted.
A new tag could definitely work! One with a few different options for the type of long-form content contained in the note.
I would even suggest more options available than just articles and blogs. Some ideas I have off the top of my head would be:
News
Article
Blog
Review
Fiction
Recipe (I've noticed zap.cooking is using kind 30023 notes for their recipes.)
Recipes might be better served as a separate event kind, as a matter of fact. Zap.cooking has shoe-horned them into long-form, but having some extra fields that would be useful for the recipe format would be ideal.
There's probably other categories of long-form content that I haven't thought of that would be good to have as well.
npub.pro
You can use any long form editor to create posts, then set your site to only display articles 🤙
Yes, but it would be better if blogs and articles were seperate things.
But a blog is a list of articles. I'm not sure I understand.
No a blog is a list of blog entries. Blog entries are not articles. Your diary is not an article. They are two different things. Just like a book and an article are not the same thing, even though they are both long form rich text.
npub.pro sites can be customized. Set it to only publish kind 1 notes with the hashtag #blog. Boom 🤙
Yea but then you have to remember to hashtag all your content appropriately.
This is less work than WordPress IMHO 😂
Im not concerned with alternatives I want nostr to be concise and be the best option for all users. Just because blogs work as articles doesn't mean the job is done and we should leave it that way.
Then I would get in touch with nostr:nprofile1qqsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsfqhde8 the creator of npub.pro, nsec.app & nostr.band. it's entirely possible a blog kind could be added if there is demand, then you just need an editor for them. Probably not that hard to modify current long form article editors, since the content is virtually identical.
Or even a change to the current nip to put a tag on the event that specifies the kind of long form content would achieve a similar effect, not break previous notes and allow old blog entries to be replaced with the new blog tag. That's the best way forward imo.
Should there be any different fields/tags in blog events (except for different kind number)? A different way to display them, different client UI?
Client UI for creation stories be relatively the same. A switch to pick between big and article would be great. (Adds a tag to the event, indicating a blog.) Then you can filter feed by all articles or just blogs.