Test of 30041 display.
nostr:note1m9jdd9w9qxwa8gfda6n3sku7nf6mjnxylhaaa8wpnvdz85xajrasrrpj2a
Discussion
No strudel yet ❌
Where can I see this now?
Highlighter
Just saw yes 🙏
Wanted to check how 30041 displays, as that's where the content is.
Njump just shows json
This means we can print books with 30040s and then create an article (or maybe a wiki page?) containing the same 30041s and Freerse, Coracle and Highlighter would probably display a readable version of the articles and Highlighter and Indextr (the one from nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf ) would display the proper 30040s as collections.
Damus can also display readable articles.
Yeah, #Nostrudel is at least willing to show something, which better than nothing, but not that great.
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr
Don't stress our favorite unicycler too much 😉.
Very much good enough for now 👌
Displaying at least something like this is best practice. Just leaving it blank or hiding it is unhelpful.
Oh, yeah, he's on vacation. Sorry!
no idea still yet where the funding will come from but i'm of the opinion it's a great base for cranking out a really slick fork... especially now it actually supports nip-42 - would be great if it's possible to simply add more control interfaces without interfering with the existing codebase...
i'm a total noob at typescript tho
Slick + More Control Interfaces 😂 😂 😂
Wet dreams of Nostr devs.
I'm here for it.
#nostrdesign in a 🥜 shell.
30041s are really important because they keep the subcontent out of the main feed.
Otherwise, every single Bible verse will have to be a wiki page or article page or note. There are almost 32k verses.
I think of it this way:
The 30040 is the binder and the 30041s are the individual papers in it, sorted in a particular order, all pertaining to some topic.
You could have 500 papers in that binder, or 5, but the binder always takes up the same amount of room on the shelf.
What is a 30041 event? I don't see any apps that support opening it
It is now supported by Indextr (still self-hosted, but soon to come on our website) and by Highlighter.com
Here is an example of both 30040 (metadata) and 30041 (sub-article or chapter).
wouldn't "section" be a better name?
the 30040 kind can be stacked in a tree right? so you can have like Genesis, Exodus, etc and then in each Chapter I, Chapter II, etc and in those probably better to then just use a simple header to indicate position
They can be stacked, yes, and the 30041 is where they actual content is.
It could be section, but i like the general idea. Novels may have sections, but one may want to fine grain it even more. The purpose for denoting sections ( through whatever method) is that the author explicitely is stating "this text belongs here, not over there". Makes a nice training set on "semantically closed" concepts.
The format is definitely most ammenable to "sections" though, given the title tag requirement.
On #Freerse, it displays like an article (ignore the HHHH bug, that's on wiki pages, too, just a Freerse bug)
Highlighter displays it correctly, as inline text.
Just need to make it look more seamless, but I think #[4] already has that solved in his test environment. Judging by the demo video he made.
Primal doesn't render the note correctly.
They're very strict about event types and I have no contact to their development team.
Amethyst goes blind.
Okay, I just broadcasted it. Does a refresh help?
Nope, I suspect it's not trying to load that kind.
I confirm it doesn't work on amethyst
Guess we'll just have to always link to Highlighter or Indextr. Or maybe nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z will eventually add it.
Is there a NIP describing it?
Here's the spec. nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft wants to change the stringified content to tags, I think. nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf agreed to it, yesterday, but they haven't had time to update it. I'll fork it and correct it, after lunch, if they don't get to it, first.
I think there should be a way (a tag?) to find the root node, i.e. the Book. Currently a book and a chapter can not be distinguished when searching for 30040 events. Or am I mistaken?
Use case: I want to display all books on nostr.
I agree with using tags for the metadata.
Book = 30040
Chapter = 30041
Gets trickier, when you have nested 30040s, tho, like
Book = 30040
Section 1 = 30040
Chapter in section 1 = 30041
That's what I meant. How to find the books then.
Yes, the 30040s are then a second, parallel linked list. The lower ones need an "e" tag, so that we can tell the top ones by their lack of that tag.
What do you think nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft and nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf and nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn ?
i think search starts out identifying all the 30040s and searchable through their titles/authors. A high level contextual view, or how we generally look through books.
The interesting concept comes at the analysis/search level between individual zettles. Been thinking about a word embedding kind. Tags could "model" and the id of the referenced event with the coordinates in the note.
General dvms would have a field day with existing embeddings AND you can plot/organize through their embeddings forbthe users to find connections. Select individual zettles that are exactly what you are interested in.
We're given books and papers with an implicit task of finding the gold in the text. Here we have the coordinates of all raw materials. You find the zettle that you care about and read the surrounding context or insert it into the context of your ideas.
The same zettel can stand on its own, be used as a reference, or clicked on and viewed within the context of the original document. Very powerful modularity, yes.
But the question still stands that there's a sort of list and app designers would want to know where the top-level entry is. (Might be multiple top-levels.)
Like, if I publish a book, how can I ensure that the chapters aren't listed parallel to the book?
When you publish, the parser will have to create some top level 30040. If that's only what we want to see, we could have a tag in there to at least denote the highest level.
If someone else embedded that top-level 30040, then I guess we'd have to Display both as top-level.
Like, someone could print the New Testament and Old Testament as individual books, and someone else could join them into a Bible and add Luther's commentary.
That should be fine, because they are distinct articles on their own. I think a single user would be less likely to publish their incrementally growing book one in a way that clutters the feed, or the design can incentivize that behavior. Def would like to avoid the "nostr plays" type of cluttering.
Viral publications could unravel something like this:
1)user posts 🔥 article
2) many users share - nothing different
3) many users edit, fork and integrate the existing article.
But because these kinds are slower moving than kind1, i don't expect it to be a huge problem considering what is already being delt with.
Even better is when specialized clients connected to themed relays/communities use this. Members of that community can decide on best practices for posting and writing.
nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf my point was that the 30040's have two uses. On the top level they are used as a book. On the second and deeper levels they are used as sections.
Imagine there are thousands of books and tens of thousands of sections (all 30040 events). How do I query for the list of books? IMHO there is a tag needed to identify the top level books.
Here's the video of the Highlighter demo.
As you can see, it creates a linked list of notes with a metadata header and only the header shows up in anyone's feed, so you can have really long lists (like a scientific article with sections or a book with chapters). This can then be exported as an ePub or PDF or etc. With a table of contents and a title.
You can also mix your own sections with other people's sections, so that people can zap the original author, or comment on that section and the original author receives feedback.
That sort of thing. It adds hierarchy and creates collections of notes.
Would basically turn Amethyst into an e-reader, like Kindle, but with the files on relays.
#Coracle looks good. 👍
I hope they also minimize long entries in the main feed, or people will have to scroll past an entire book. 😂
Okay, just checked. If you out the 30041s into an article, you have to open the article to see them, so there isn't one long text in your main feed.
It then just lists the individual note ID, which you can open by clicking.