NIP-XX: Progress Event

[RydalWater]

Progress Events

The NIP covers the inclusion of Progress Events as implemented in Open Librarian. While the specific implementation is focused on tracking reading progress, the NIP is generic enough to be used in a whole range of other progress tracking scenarios (e.g. Fitness challenges, course progression for learning, personal goals etc..)

Thoughts/feedback/suggestions all welcome.

[alexgleason]

@RydalWater Have you seen Bookstr by @marykatefain ?

Many of the same concepts of Open Librarian are being used (TBR list, ratings, etc), but I don't know if they're the same event kinds or compatible. At a glance they look like they could become easily compatible.

I think it would make more sense to have a dedicated NIP for books on Nostr that describes all of it, similar to your readme for Open Librarian.

Also related: #879

[RydalWater]

@RydalWater Have you seen Bookstr by @marykatefain ?

Many of the same concepts of Open Librarian are being used (TBR list, ratings, etc), but I don't know if they're the same event kinds or compatible. At a glance they look like they could become easily compatible.

I think it would make more sense to have a dedicated NIP for books on Nostr that describes all of it, similar to your readme for Open Librarian.

Also related: #879

Yep it was the amazing work by @marykatefain that made me think I needed to write this down on paper. Figured it would be good for us to interop asap.

Happy to help pull it all together into something concise. For progress I do see applications outside of books but there is no reason not to start from smaller scope.

[marykatefain]

This is an interesting concept! I'm not sure I agree with the underlying premise that a book always goes through steps of reading in a linear progression. For example, many people like to reread books, but you wouldn't remove it from your "read" list just because it is also "Currently Reading".

I'm currently just using new Kinds, replaceable events (10073 - read, 10074 - currently reading, and 10075- TBR) based on NIP-73. I'd love to standardize this across reading apps!

That being said the progress concept could be used for other things beyond reading.

[RydalWater]

This is an interesting concept! I'm not sure I agree with the underlying premise that a book always goes through steps of reading in a linear progression. For example, many people like to reread books, but you wouldn't remove it from your "read" list just because it is also "Currently Reading".

I'm currently just using new Kinds, replaceable events (10073 - read, 10074 - currently reading, and 10075- TBR) based on NIP-73. I'd love to standardize this across reading apps!

That being said the progress concept could be used for other things beyond reading.

So for the book list I simply use the Kind 30003 bookmarks as described in NIP-51 (lists). They are constructed as separate lists for each shelf type (allowing for expansion into user defined shelves, should they wish). They take this form:

{
  ‘kind’ : 30003,
  ‘tags’ : [
    ‘d’           : <SHA-1 of (pubkey + list ID)>,
    ‘title’       : <list Title>,
    ‘description’ : <list description>,
    ‘i’           : <‘isbn:’ + isbn of book>,
    …
  ],
  ‘content’ : <‘Books & Literature (OpenLibrarian)’ + ‘:’ + # of hidden books + ‘:’ + NIP04 encrypted ‘i’ tags for isbns of hidden books>   
}

Lists

There is no reason the d tag couldn't just be the list ID alone, I just paired it with the pubkey to avoid collisions with other bookmark lists since the ID values I use include: CR, HR, TRW, TRS.

Once the application has retrieved all the ISBNs from either the contents field (for hidden books) or the main i tags we can go gather all the relevant progress objects, reviews etc.

Note the use of the number of books ":#:" in the content field allows for clients to log in as that person in read-only mode and to list out the 'hidden' book objects, without knowing what the ISBNs are of these books.

Progress

The progress object serves a few different purposes. Firstly it allows a user to track their current reading progress for a book. Secondly, once a book is complete the progress object (with start and end dates) allows for some simple statistics to be derived (mean page/day, books/year etc.) as well as helping set the foundation for book challenges. As you say it also has uses outside of books so this seemed a nice bonus if the structure was kept reasonably generic.

You raise a good point about how we may track repeat reading. There is nothing stopping someone moving a book onto their Currently Reading list again. Perhaps some simple counter tag could be added to the progress object which is incremented every time the book has been read. Allowing for the re-use of the progress object to track the new read, but while keeping the a history of previous reads.

Hashed d tags

I know you're not a fan of the d tags for reviews/progress being hashed, I agree that this doesn't provide true privacy which is why I didn't call them "private" or "secret" books. I'll add a disclaimer to my client as well to remind people that if they really don't want people to know about the book they should then consider not adding it.

Using the hash of the ISBN is the cleanest way to connect items pulled out of the lists without immediately doxing the 'hidden' books. For someone to break the hash isn't a trivial task as there are a lot of ISBNs they'd have to iterate through and if they go to all that trouble I'm sure most people wouldn't be too bothered.

Allowing for obscured books means users don't have to reveal all of their reading habits in one go if they don't want to. But as highlight it comes with tradeoffs. The goal was to aim for "good enough", rather than bitcoin level security.