Moving the discussion about this PR https://github.com/nostr-protocol/nips/pull/220 to here.
Discussion
If this is implemented, does it mean I can write my blog nostr natively instead of linking to ghost or jekyll sites?
Answering #[0] at https://github.com/nostr-protocol/nips/pull/220#issuecomment-1416557909:
> i find all this nref things a bit confusing and anti pattern for nostr. I think the document should be able to referenced by note1d and it's hex protocol id, and we should be able to see the edits, so a list of versions
We already do not reference public keys by their metadata event id, when that would have been sensible, right? I think it is the same with parameterized replaceable events.
I agree it feels weird to refer to something that is not an event, and also that it would be ideal to have a history of all edits a document has ever had, and specially to have a reference to the point in the entity history on which you are commenting (i.e. I make a comment today about a thing, tomorrow it changes to its opposite, my comment has its meaning inverted, not cool) -- but for this to work we would have to rely on relays keeping a ton of possibly very large events and we don't want that.
I think the solution is for the comment to tag both the "ref" (i.e. combination of pubkey, kind and "d" tag) and the event id -- and while doing that, if possible, also push that exact event (i.e. the "ref" at that point in time) to a special archive relay that will not delete that event or overwrite it -- so others can then later fetch the event at the specific date.
I think this "ref" name is bad and it would be better to call it "entity" -- also in my PR above I am referring to these things using only "pubkey" and "identifier" ("d" tag), but I think they should also contain the "kind".
If we decide to all any "parameterized replaceable event" an "entity" instead, that will make everything simpler. And links could be beautiful with the "nent1..." prefix, tags become `["n", "
Answering https://github.com/nostr-protocol/nips/pull/220#issuecomment-1416566716:
I just chose YAML because it is common practice out there for blog software and static site generators out there to use Markdown with a YAML front-matter for metadata, mostly because it is very readable as plaintext I believe and easy to write by hand.
Considering that I think it makes no sense to use TOML, since it would be introducing yet a new dependency and nothing would be gained. I'm considering now that it makes no sense to have this be in YAML since no one will be writing these by hand ever anyway, so just using JSON will probably be a better solution.
And yet, now that you asked why not use that "subject" tag that already exists, I see that it is probably better to just use normal tags for everything and get rid of the front-matter completely. This simplifies parsing as you don't have to split the article string, then run it through a parser and whatnot.
So we should just use tags for everything, a tag `["title", "Lorem Ipsum"]`, other tags for other things that may appear, like `["summary", "..."]`. What else?
Why not use the "subject" tag? That tag only has meaning on `kind:1` events and we gain nothing by reusing it here. It would just confuse things.
A prototype writer client is live at https://write.nostr.com/, by #[0].
A reader client should be happening soon.
🤙🏾