Using channels for bookshelf management

[manton]

In the IndieWeb pop-up session about libraries and books we talked about formats for publishing bookshelves (what we're reading or want to read) but not much about new APIs. I was thinking that we could possibly piggyback on Micropub's "channels" support (#40) to allow a client to manage bookshelves in a standard way.

For example, the Micro.blog companion app Epilogue can search for books and add them to bookshelves, and then post about them as a separate step via Micropub. The management of bookshelves is done with a Micro.blog API based on JSON Feed. It's documented here: https://help.micro.blog/t/json-api-books/545

Instead of that API, we could use Micropub and a special channel called "books". We could also borrow from the JSON that IndieBookClub is already using, like this:

POST /micropub

{
  "type": [ "h-entry" ],
  "properties": {
    "mp-channel": "books",
    "read-status": [ "reading" ],
    "read-of": [
      {
        "type": [" h-cite" ],
        "properties": {
          "name": [ "The Tombs of Atuan" ],
          "author": [ "Ursula K. Le Guin" ],
          "uid": [" isbn:9780689845369" ]
        }
      }
    ]
  }
}

And then to get a list of books:

GET /micropub?q=source&mp-channel=books

Any thoughts on using Micropub this way? It's a little different than the "posts" and "pages" channels because "books" are not necessarily public on the web as blog posts. It could be a private list of books, and then to publish you make a separate Micropub request just like any blog post.

[vikanezrimaya]

Currently I use channel instead of mp-channel and it is an array instead of a string, to allow a post to be featured in multiple channels. As Kittybox channels are intended to have visibility options, one could use private to hide the channel from public view if one wishes. Implementing bookshelf support using channels, consequently, would not require any code changes to Kittybox's backend, only the frontend, to accomodate for new properties such as "read-of" and "read-status".

Nice use of h-cite for "read-of", by the way. I like it. Maybe linking to a remote MF2 document should be explicitly mentioned too? Also using an ISBN for a UID - shouldn't uid be, well, a URL? My frontend could, however, transform an ISBN into a URL given a website to search up books by ISBN.

[manton]

@kisik21 I was thinking about what you said with channels being an array... I don't support that, but I don't really see any problem with a server supporting it as an array or a single item. It is also consistent with @aaronpk's original proposal in #40 that posts can be in "one or more" channels.

Personally I'm using channels heavily now and would love for that extension to be more stable.

As for uid… I borrowed that example directly from what IndieBookClub is already doing. If it's a URL instead, what would the URL look like?

[manton]

Also @kisik21: any objection to supporting mp-channel instead of or in addition to channel? I think the Micropub convention is to prepend mp- for those things, and it would be great if the clients I'm working on were compatible with your server too.

[vikanezrimaya]

@manton no problem, supporting it turned out to be just a few lines of code in my normalizing. It'll still get transformed to channel, but any "mp-channel" properties should take effect in addition to "channel". It's not applied to editing for now, but this will be fixed. I might need to revamp my editing anyway to properly support posting to channels after the fact.

[vikanezrimaya]

@manton additionally, mp-channel could also be a singular string instead of an array for compatibility reasons, but it will still get transformed into a channel array and/or appended to its existing content.

[vikanezrimaya]

Additional question: maybe instead of a hardcoded channel value, we could designate a channel as a default bookshelf using output of ?q=channels?

[jalcine]

My server supports either singular or a list of strings for any value provided to the server so this should work okay for me.

…

On Fri, Feb 25, 2022, at 21:06, Vika wrote: @manton additionally, `mp-channel` could also be a singular string instead of an array for compatibility reasons, but it will still get transformed into a `channel` array and/or appended to its existing content.

[jalcine]

I'm in favor of avoiding a hard-coded name for bookshelf management. Mainly because I do want to encourage multiple forms of bookshelves (one for comics/manga, another for historical books/research and another for fiction). I currently have it just named 'Books' right now on my site but I'm planning to backfeed books into particular location

[manton]

I guess there are 2 ways to handle it:

• Have a standard channel "books", and then optionally have platform-specific names for different bookshelves. In Micro.blog, there can be any number but the defaults are things like "Currently reading", "Want to read", etc.
• Have multiple channels like "books-reading", "books-want-to-read", "books-comics", etc.

I think I prefer the first option. Thoughts? My main goal here is to make it possible to create book-focused Micropub clients that can add books which are independent of posts. We can layer other functionality on top of that.

[jalcine]

Is the need for the hard-coding mainly for experience? I do see the benefit of doing so (fewer steps for users when they're setting up their shelves, less plumbing visible to them). After thinking on it more, I think it's okay if it is, it's truly up to the client to discern which channel to find said books in. I don't think I'll be doing so in my site, but I can def keep this in mind while working on my client that channels like this might have things like read posts in them or the like.

[jalcine]

To expand on this, would it work for micro.blog if people had an option to pick which channel maps to a particular shelf? This kind of points to something I was hinting as an implementation detail in Koype, channels can have MF2 and be queried from q=source. This allows me to give them more definition (like, my TIL page can look different because of the slug and content it has—I can even change the title). That also opens it up to any kind of custom values we'd like to have in there. Would something like this work for micro.blog to have some sort of “special” property to add or even better, check if the last five or so children of a channel looks like it would be relevant to a bookshelf (a bunch of h-reviews/h-entry+u-read-of posts that map to links to known book websites like Goodreads, OpenLibrary or Bookshop).

I say mainly to prevent coupling the concept of books to channels too tightly—I think the looseness of it now is what made it so appealing for me to implement as a means of content organization.

(Originally published at: https://jacky.wtf/2022/4/ue/uevCQXvQFBuYwmmzFqZy2sOn)

[manton]

I'm not sure. There are definitely a couple ways we could approach this. The ultimate goal (for me) is to be able to build an app like Epilogue that can manage bookshelves stored in servers other than Micro.blog. It would need to "just work" with a server even if no books were stored there yet, or even if there were no channels being used.

I personally don't view Micropub channels as a super-flexible way to group posts, e.g. I don't plan to allow the user to create arbitrary channels. This is a little different than how most people are using Microsub channels.

Not sure if this helps answer your question. I think we need more people to jump into this discussion.

[jalcine]

It does, and I agree. Going to ask around in upcoming HWCs about this and in chat.

(Originally published at: https://jacky.wtf/2022/4/73/73YMlp1ap7sAb7-wzdbGk-w6)