I think saving or not saving should be done only from the relay point of view, so clients should be mindful of which relays they are using if they want to save the entire history or not. Regardless of that, for the immediate reader of an article they should be using a relay that only returns the latest _item_, not the entire history, as that would be terrible if the article is big enough and has had many edits.
Discussion
totally against making it a standard to store all the version history in such a protocol level. it is not only that "as a writer, I don't care about the edit history so most storing will be a waste" but also, more importantly, a relay should choose its desired to store all the version history it knows. it should be decided in the relay business level, somebody could make it a service like "articles archive" or something. it is out of spec in such a discussion
However, I do wonder if we have some kind of way to know the `updated_at` time besides `created_at` for articles. Rendering such time info will let readers know this article has been updated. I know WeChat has impl such a pattern in its blogging platform (which is also the largest blogging platform in China)
In this NIP `created_at` will be equivalent to `updated_at`. The actual `created_at` would have to be in an extra metadata field, which is fine by me.
I agree.