I'm thinking through d tag conventions more, and we may have to revise our pattern somewhat.
The pattern `<title>-<author>-<version>` only really works for the root index of a whole book. Chapters/sections within that book won't have author and version attached to them by default. I see at least two options:
1. Carry author and version information down into the book's hierarchy, and attach it to every chapter and section index. This makes the ids of _everything_ longer (which increases URI length within our app), but it increases the likelihood of name uniqueness even of sections within a book.
2. Don't include author and version information in the d tag identifier of every chapter and section, but include that information in the tags. If we know the author and edition of the book within a chapter resides, for instance, we'll include it in the index event generated for that chapter.
2.5. If we take this latter approach, I'm interested in exploring adding additional fields to the d tag array. The question is whether the first identifier in that array is _always_ used to generate note identifiers for 30000-series events, or whether the whole d tag array is used. Perhaps we can include full author and version information in the d tag array, but not have it be mandatory for looking up an event. The details probably depend on relay indexing and search implementations, there.
Let me know which option you prefer, or if you have other alternatives.
buttercat1791 / Michael J
npub1wq…cqsyn
2024-09-13 13:18:54
in reply to nevent1q…0y8p
Author Public Key
npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsynPublished at
2024-09-13 13:18:54Event JSON
{
"id": "00c85183c6c2482ae8d8fa5c353b1141990f909542fde49e268504704a30249a",
"pubkey": "70122128273bdc07af9be7725fa5c4bc0fc146866bec38d44360dc4bc6cc18b9",
"created_at": 1726233534,
"kind": 1,
"tags": [
[
"e",
"3fbba0ec563849e0904f2d11a908ae89fa6c68e4e41a07ec75b665b532831c8e",
"wss://nostr.thesamecat.io",
"root"
],
[
"e",
"09e4a84be0c34715f73cc3d339c1ec0cf28afe082937e1a0e2ba7aa3ff1f3c41",
"wss://nostr.thesamecat.io",
"reply"
],
[
"r",
"2a6cbb5a1636735690493bcc8dcac147a174de45"
],
[
"a",
"30617:fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1:Alexandria"
],
[
"a",
"30617:dc4cd086cd7ce5b1832adf4fdd1211289880d2c7e295bcb0e684c01acee77c06:Alexandria"
],
[
"a",
"30617:70122128273bdc07af9be7725fa5c4bc0fc146866bec38d44360dc4bc6cc18b9:Alexandria"
],
[
"p",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1",
"wss://theforest.nostr1.com/"
]
],
"content": "I'm thinking through d tag conventions more, and we may have to revise our pattern somewhat.\n\nThe pattern `\u003ctitle\u003e-\u003cauthor\u003e-\u003cversion\u003e` only really works for the root index of a whole book. Chapters/sections within that book won't have author and version attached to them by default. I see at least two options:\n\n1. Carry author and version information down into the book's hierarchy, and attach it to every chapter and section index. This makes the ids of _everything_ longer (which increases URI length within our app), but it increases the likelihood of name uniqueness even of sections within a book.\n\n2. Don't include author and version information in the d tag identifier of every chapter and section, but include that information in the tags. If we know the author and edition of the book within a chapter resides, for instance, we'll include it in the index event generated for that chapter.\n\n2.5. If we take this latter approach, I'm interested in exploring adding additional fields to the d tag array. The question is whether the first identifier in that array is _always_ used to generate note identifiers for 30000-series events, or whether the whole d tag array is used. Perhaps we can include full author and version information in the d tag array, but not have it be mandatory for looking up an event. The details probably depend on relay indexing and search implementations, there.\n\nLet me know which option you prefer, or if you have other alternatives.",
"sig": "b8c650b8a6491a0b4a3096d70eb6811fe950c40e7a1b8c5b5fc01ac201e3e54fd4de299d5332ac12abaa69adf7e4fe09a9b3edf93f845d1a158a67ef1ee85fdc"
}