Build Your Own Adventure posts

[vitorpamplona]

Inspired by the Build Your Own Adventure books, this NIP tries to emulate the same behavior on Nostr.

It allows Clients to build button interfaces for the next options in each part of the story.

Read: here

Simple demo: https://video.nostr.build/3be38941d3123f8b72f13cac9ed46ae4f158edf52e4afdfdfbffc77abdd402c8.mp4

[alexgleason]

This is wacky. I like it.

It's weird you have to create the leaves before the branches.

[staab]

Fun idea

[pmrcunha]

Cool idea! I can see this being used for a lightweight online course client too.

[pablof7z]

lol, this is super cool!

[SilberWitch]

Hate to make this boring, but could we have something like this for articles, so that one person can define different paths people can take through their 30023s?

Like the old-style blog breadcrumbs, related articles, or series of articles?

I've just been writing "In my last post, on the same subject ", but it breaks the flow of the writing and IT sends people to a different article before they finished the current one.

So that the options are "previous" and "next", or something. Like so:
https://codex.wordpress.org/Next_and_Previous_Links

[Sebastix]

Hate to make this boring, but could we have something like this for articles, so that one person can define different paths people can take through their 30023s?

Like the old-style blog breadcrumbs, related articles, or series of articles?

I've just been writing "In my last post, on the same subject ", but it breaks the flow of the writing and IT sends people to a different article before they finished the current one.

So that the options are "previous" and "next", or something. Like so: https://codex.wordpress.org/Next_and_Previous_Links

Basicly the options tags (and the e tag when the event is not the root event) could be used on those event kinds (30023) too? Or make these kinds 296 and 297 more generic to be used with multiple (content) event kinds (kind 1 and 30023) and use the reference a tag with an empty content field?

[SilberWitch]

Yes, could we make "option" more widely-applicable, so that we don't need hyperlinks to navigate and clients can standardize the handling? Then, it's internal linkage, like with wikis.

[vitorpamplona]

There is a difference between the option tag here and next/previous on articles and kind1s. Here the content is always incomplete and you HAVE to see the options in order to get the full story. This is why it's a different kind. If we add these to Kind1 and kind 30023, those clients that don't support this NIP will show only a partial story that doesn't make any sense on it's own. It's fully out of context.

Now, maybe what you are asking is not for partial stories, but it's just the next and previous links to other posts. On kind 30023, people usually do that with markdown links or quotes at the bottom of the article. But we could add tags to make custom UIs in clients as well. We just need to be mindful that many clients are not going to implement it. So they should be optional UI feature instead of required as in 296 and 297.

I don't think we should overload kind 30023 and kind 1s with the partial content 296 and 297 would have.

[SilberWitch]

Okay, that makes sense. Especially for this use case.

I'd really like note navigation determined by the author, tho. 🙈One of the best features of Wordpress, was that the entries weren't orphans.
Would it be possible to have the options in a type of navigation label, for 30023s? Then, if the client didn't handle them, it could just ignore the label? I was thinking about this, for 30040s. An author could recommend other books, from his own book.
Maybe I'll write that up, separately, in my References spec, and stop derailing here.

But this is a fun one. Could use it to create wizards or dynamic quizzes, too. Like, those beauty quizzes where they ask you to choose your hair color (dark/light) and then, if you choose "dark", it asks you to select from black/dark-brown/med-brown and so on.

[vitorpamplona]

One of the issues I am having is how to structure the read state of this kind. I think people would want the read state to be synchronized between clients, especially for long books. The question is, do we just mark down where I am in the story (just save an event ID somewhere) or do we store the full stack of options and answers?

More importantly. Can/should that information be public or does it need to be encrypted?

[SilberWitch]

Encrypted 💯

[pmrcunha]

Storing the full stack of answers would allow you to, for example, display how many possible endings you've explored.
And if that's public you could even show how common the user's answers are.

Reminds me of the game Detroit: Become Human, which at the end of each level shows you a tree revealing that there are other decisions you could have made, and you replay to discover them all.