bpepple
Support Generating Reading Lists
Add a special community driven reading lists An idea that a site user can make a list from whatever issues he found appropriate under some theme of his choice
Example: "Marvel chronology 1976 - 1980" - contains issues "Spider-Man chronological reading list" - contains all spider-man related issues in chronological order
Nice feature to have - is "likes" or "favorites" for them, so you can sort out based on amount of likes
And to have an ability to download this as CBL file, so you can import it into Kavita or Komga
P.S. Currently there is github repo with CBL files for various stuff - https://github.com/DieselTech/CBL-ReadingLists/ But issue is - with any change on database itself, like change of series name, or any cover years update, this CBL simply stops matching, it's not valid after that. So it would be so good to have that stuff on database side, so database itself will be able to generate and regenerate that files for you.
I looked at CBL's awhile back, and it's got some serious flaws (no clear shema definition, it's fragility with names, etc) and so I'm not inclined to add an exporting to CBL feature, but I think a better solution is to provide the necessary information thru the API. That way it would be simple for a user to write a program to spit out the data in CBL format (or ideally a better format).
What information to include in the API call and parameters to filter by, would need to be defined, but that is something that shouldn't be too hard. I know Jo was looking into CBL's recently, so he may be able to help define the requirements.
I've thought about adding the ability to rate issues (#48), most likely using some like django-star-ratings, which might work for your wish feature aspect.
I looked at CBL's awhile back, and it's got some serious flaws (no clear shema definition, it's fragility with names, etc) and so I'm not inclined to add an exporting to CBL feature, but I think a better solution is to provide the necessary information thru the API. That way it would be simple for a user to write a program to spit out the data in CBL format (or ideally a better format).
What information to include in the API call and parameters to filter by, would need to be defined, but that is something that shouldn't be too hard. I know Jo was looking into CBL's recently, so he may be able to help define the requirements.
I've thought about adding the ability to rate issues (#48), most likely using some like django-star-ratings, which might work for your wish feature aspect.
Yes, my mention of CBL was just an example of applicability of that feature I think if there will be some API endpoint which will return "Reading list" in some format there would be no problem to generate whatever CBL or any file user might like 🤔
So, got some information on what the new CBL would require something like this from the Issue (list) model:
{
"id": 0,
"series": {
"id": 0,
"name": "string",
"volume": 32767,
"year_began": 32767,
"cv_id": 1234568,
},
"cover_date": "2024-11-17",
"cv_id": 2147483647,
}
We would most likely have a decent amount of parameter (ids, names, etc) for the different resources (character, teams, etc) in addition to filtering by cover dates, so the user could generate lists based on their criteria.
One thing the schema has that Metron doesn't (but might be a decent idea to implement) is associating story arcs. If I get some free time I might look into this a bit more.
The one problem I see is the that the json-cbl-standard requires a series id, which is a problem when using multiple sources due to inconsistencies between the different services. So there isn't a 1-to-1 linking between the services for series.
For example, Comic Vine has the series as X-Men: Black Sun but Metron and GCD has them as separate series (based on the issues indicia).
Now there are solutions for this, but none of them are that great:
- For services (Metron) that track the id's between services is to make sure the DB field is set-up to accept duplicate values for series. So, using the example given above, in Metron all the series would have the same CV_ID. Not great, but semi-workable for cases like above. Unfortunately, you've also got a problem where issues for a long running series that restart numbering, I'm thinking something like Amazing Spider-Man, where the original series was cancelled, then another series started and then partially thru the run they revert to original number. Depending on the service they could associate the issue to the original series, so again there's not a 1-to-1 linking between them. In that case, there isn't really a solution to resolve that.
- Modify the json-cbl-standard to make the series id optional. I'd be interested to know how consumers of the spec are using that information.
First of all - I don't think that Metron, if Metron will generate CBLs, should care about GCD or Comicvine It's nice to have, but I don't see for what, if there is not much ways to work around it
Also, Metron have different naming for couple of series (I remember matching some to CV manually), which also I see as a problem
First of all - I don't think that Metron, if Metron will generate CBLs, should care about GCD or Comicvine It's nice to have, but I don't see for what, if there is not much ways to work around it
Agreed. I just wonder what use the series id would be to the consumers of their json. Having the issue id should be sufficient for almost any use-case I can think of off the top of my head.
Also, Metron have different naming for couple of series (I remember matching some to CV manually), which also I see as a problem
ComicVine, by far of all the services, is the worst in regard to series naming. I'm mean just this last week they used X-O Manowar: Resurgence, instead of following the indicia data of "Resurgence: X-O Manowar".
Hi Brian,
Thank you for the feedback on the new CBL proposal, I really appreciate your comments on it here as well as your blog post.
On your blog you mention serving the list directly from the API.I think that would be great and would align to a long term vision where you add a repo to a reading application and then you can browse through the lists and import them directly in the reading application. Having only IDs in the list would make it possible to import the files as long as you have all the matching issues tagged with the metadata containing the ID in your existing library. Where this could become an issue is when you don’t have the issue in your library, the reading software would want to give a list of those missing issues (title, volume issue number). To fill this data you would have to make another series of API calls using each ID. Some of the lists can be quite long, which could turn the import (if using CV :) ), into an hours long process. If a reading app doesn’t support ID matching and only uses series/volume/issue matching, including that information in the list enables that software to still do matching.
I spent some time playing around with the TMDB list making feature that you referenced. The user inputs, title, description, a movie along with an optional comment for each movie and chooses a cover of one of the movies to show as a thumbnail. Once the list is rendered more information is shown, runtime, average rating and revenue. I think this is a good corollary to what we are doing. We do have title, description, comments in the standard. There is also a lot of other information as you said. I think it is something we can discuss to find the right level of what is in the list, versus what is picked up in the reading application by analyzing local metadata, versus what we pull from the API. I can picture when you have a list imported in the reading server you can see the date range, characters, writers, artists, etc for a given list.
In the above comments, you bring up a very good point which I personally had not considered before: For a given issue, each database can quite likely have a different series name, issue number and start year. I would propose that for each DB, we have entries for ID, series, issue and year. We would make only one required and for the others it can be IDs only. For example, you would include Metron ID, series, issue and year, and then just the CV ID and.or GCD ID (assuming you have it mapped). This would allow us to have the full information for at least one DB, and would allow the user to also find matches on other dbs, but it doesn’t require you to get the series, issue year for those databases. Let me know your thoughts on this. I believe this covers your examples on naming differences (as you mention we see a lot) as well as numbering issues (legacy numbering)
Thank you again for all your efforts! I look forward to creating something that can be used for many of the aspects of this great community.
Thanks, flips
On your blog you mention serving the list directly from the API.I think that would be great and would align to a long term vision where you add a repo to a reading application and then you can browse through the lists and import them directly in the reading application. Having only IDs in the list would make it possible to import the files as long as you have all the matching issues tagged with the metadata containing the ID in your existing library. Where this could become an issue is when you don’t have the issue in your library, the reading software would want to give a list of those missing issues (title, volume issue number). To fill this data you would have to make another series of API calls using each ID. Some of the lists can be quite long, which could turn the import (if using CV :) ), into an hours long process. If a reading app doesn’t support ID matching and only uses series/volume/issue matching, including that information in the list enables that software to still do matching.
Really my vision for future reading lists wouldn't have a repo like the current implementation, since in essence, it's just another (albeit limited) database, which doesn't make a ton of sense.
Ideally the reading list data would be generated/imported from one of the current database's (GCD or Metron). Any missing issues would be tracked in the comic server, and adjusted when said missing issue is imported.
I spent some time playing around with the TMDB list making feature that you referenced. The user inputs, title, description, a movie along with an optional comment for each movie and chooses a cover of one of the movies to show as a thumbnail. Once the list is rendered more information is shown, runtime, average rating and revenue. I think this is a good corollary to what we are doing. We do have title, description, comments in the standard. There is also a lot of other information as you said. I think it is something we can discuss to find the right level of what is in the list, versus what is picked up in the reading application by analyzing local metadata, versus what we pull from the API. I can picture when you have a list imported in the reading server you can see the date range, characters, writers, artists, etc for a given list.
My thoughts on how the database (GCD or Metron) creates new reading list would be similar to TMDB, users creates a reading list with necessary info (title, desc, etc), adds the necessary issues, and drop and drags them in the correct reading order (which I believe the current reading lists don't track), and saves. These reading lists would be accessible thru the API.
In the above comments, you bring up a very good point which I personally had not considered before: For a given issue, each database can quite likely have a different series name, issue number and start year. I would propose that for each DB, we have entries for ID, series, issue and year. We would make only one required and for the others it can be IDs only. For example, you would include Metron ID, series, issue and year, and then just the CV ID and.or GCD ID (assuming you have it mapped). This would allow us to have the full information for at least one DB, and would allow the user to also find matches on other dbs, but it doesn’t require you to get the series, issue year for those databases. Let me know your thoughts on this. I believe this covers your examples on naming differences (as you mention we see a lot) as well as numbering issues (legacy numbering)
Truthfully, I don't think having series detail is terribly useful, since I doubt any of the consumers (Kavita, Codex) would use it when importing the reading list.
A display name (like Batman v1 #1, depending on the DB server issue string) should be sufficient for identification purposes, since the issue id's would be used for matching be the comic servers, and like I mentioned earlier, any missing issues could be tracked by the comic server.
Now, getting existing reading lists into one of the DB's (GCD, Metron) would be fairly trivial, since based on the last time I looked, most of list contain the CVID, and since Metron tracks the CV ID & GCD ID, either GCD or Metron could use that to match issues in their systems.
Anyway, I'm still sketching out the basic requirements and need to consult with some of the comic server devs (Kavita, Codex) to make sure I'm not overlooking anything, and see if the GCD folks have any interest in reading lists at all.
Really my vision for future reading lists wouldn't have a repo like the current implementation, since in essence, it's just another (albeit limited) database, which doesn't make a ton of sense.
Ideally the reading list data would be generated/imported from one of the current database's (GCD or Metron). Any missing issues would be tracked in the comic server, and adjusted when said missing issue is imported.
Hi Brian, I think we are in pretty close agreement on the future vision. I used the repo example in a similar way like installing extensions in Kodi. You find the repo URL add that and then you are able to view the lists available from each db, in this case Metron, GCD, etc. The reading software would then pull in the lists and updates through the API so to the user it would look integrated. Alternatively the reader software would have those repos hard coded which would get to the same end result. My use of repo was just to make it more extensible to other areas that may not have robust db support like Manga, for example.
I spent some time playing around with the TMDB list making feature that you referenced. The user inputs, title, description, a movie along with an optional comment for each movie and chooses a cover of one of the movies to show as a thumbnail. Once the list is rendered more information is shown, runtime, average rating and revenue. I think this is a good corollary to what we are doing. We do have title, description, comments in the standard. There is also a lot of other information as you said. I think it is something we can discuss to find the right level of what is in the list, versus what is picked up in the reading application by analyzing local metadata, versus what we pull from the API. I can picture when you have a list imported in the reading server you can see the date range, characters, writers, artists, etc for a given list.
My thoughts on how the database (GCD or Metron) creates new reading list would be similar to TMDB, users creates a reading list with necessary info (title, desc, etc), adds the necessary issues, and drop and drags them in the correct reading order (which I believe the current reading lists don't track), and saves. These reading lists would be accessible thru the API.
Today's XML is ordered in a list which is defined when you make the list, that would definitely be required to keep as you state.
Today we are making lists from parsing sources, searching based on titles, and then manually fixes mis-matches. A typical workflow is a website that has a list of issues, copy out the text and then run the text through the scripts. There's also some parsing of sites to make that basic workflow more automated. Some of the lists are thousands of issues. We would have think through how that is done on a web page. I like your suggestion of filtering for characters etc. That isn't something we have today. Also, as you state the ability to push into the DB from an API would still allow other tools to be used to make the lists.
In the above comments, you bring up a very good point which I personally had not considered before: For a given issue, each database can quite likely have a different series name, issue number and start year. I would propose that for each DB, we have entries for ID, series, issue and year. We would make only one required and for the others it can be IDs only. For example, you would include Metron ID, series, issue and year, and then just the CV ID and.or GCD ID (assuming you have it mapped). This would allow us to have the full information for at least one DB, and would allow the user to also find matches on other dbs, but it doesn’t require you to get the series, issue year for those databases. Let me know your thoughts on this. I believe this covers your examples on naming differences (as you mention we see a lot) as well as numbering issues (legacy numbering)
Truthfully, I don't think having series detail is terribly useful, since I doubt any of the consumers (Kavita, Codex) would use it when importing the reading list.
I'm not real familiar with Codex. Kavita just recently added that feature. Komga does not look at IDs at all I believe. I remember having a conversation with gotson, the Komga dev, and he didn't think it was appropriate to use the IDs and it wasn't something he was interested in supporting. This was years ago and I think his main concern was lack of a documented standard, so it is quite possible once there is a widely agreed upon standard he would be willing to add support.
A display name (like
Batman v1 #1, depending on the DB server issue string) should be sufficient for identification purposes, since the issue id's would be used for matching be the comic servers, and like I mentioned earlier, any missing issues could be tracked by the comic server.Now, getting existing reading lists into one of the DB's (GCD, Metron) would be fairly trivial, since based on the last time I looked, most of list contain the CVID, and since Metron tracks the
CV ID&GCD ID, either GCD or Metron could use that to match issues in their systems.
Agreed.
Anyway, I'm still sketching out the basic requirements and need to consult with some of the comic server devs (Kavita, Codex) to make sure I'm not overlooking anything, and see if the GCD folks have any interest in reading lists at all.
This is great. Thank you again for the effort in this area.
Not to be pedantic, oh wait, Yes — being pedantic…
How ( why ) would you handle a particular issue that could be in several “Reading Lists”?
Everyone knows that SooperDooper Dude has his own reading list, but in issue #27, Daring Damsel has to rescue him so if you are building a reading list of her exploits that would be list number 2 and since, well, you are a completist you want the whole universe reading order, and then once the debate over whether or not the shadowed figure on page 19 in panel 4 is really the Dude’s evil twin, The Villainous Viceroy, waiting for his chance to kidnap, depower, depose, and replace the Dude… that could be another several reading lists right there…
How “expansive” will you allow this to get? Or Why would you limit this to ‘N’ number of lists?
What if there is no agreement as to whether or not the shadow is the double “V” .. Metron declares It is and adds the link to his reading order but the folks at CV and CGD say nope?
-=-=-=-=-=-=-=-=-=- Rich Leonard Sent via GMail and my phone
On Fri, Apr 11, 2025 at 12:47 PM flips22 @.***> wrote:
Really my vision for future reading lists wouldn't have a repo like the current implementation, since in essence, it's just another (albeit limited) database, which doesn't make a ton of sense.
Ideally the reading list data would be generated/imported from one of the current database's (GCD or Metron). Any missing issues would be tracked in the comic server, and adjusted when said missing issue is imported.
Hi Brian, I think we are in pretty close agreement on the future vision. I used the repo example in a similar way like installing extensions in Kodi. You find the repo URL add that and then you are able to view the lists available from each db, in this case Metron, GCD, etc. The reading software would then pull in the lists and updates through the API so to the user it would look integrated. Alternatively the reader software would have those repos hard coded which would get to the same end result. My use of repo was just to make it more extensible to other areas that may not have robust db support like Manga, for example.
I spent some time playing around with the TMDB list making feature that you referenced. The user inputs, title, description, a movie along with an optional comment for each movie and chooses a cover of one of the movies to show as a thumbnail. Once the list is rendered more information is shown, runtime, average rating and revenue. I think this is a good corollary to what we are doing. We do have title, description, comments in the standard. There is also a lot of other information as you said. I think it is something we can discuss to find the right level of what is in the list, versus what is picked up in the reading application by analyzing local metadata, versus what we pull from the API. I can picture when you have a list imported in the reading server you can see the date range, characters, writers, artists, etc for a given list.
My thoughts on how the database (GCD or Metron) creates new reading list would be similar to TMDB, users creates a reading list with necessary info (title, desc, etc), adds the necessary issues, and drop and drags them in the correct reading order (which I believe the current reading lists don't track), and saves. These reading lists would be accessible thru the API.
Today's XML is ordered in a list which is defined when you make the list, that would definitely be required to keep as you state.
Today we are making lists from parsing sources, searching based on titles, and then manually fixes mis-matches. A typical workflow is a website that has a list of issues, copy out the text and then run the text through the scripts. There's also some parsing of sites to make that basic workflow more automated. Some of the lists are thousands of issues. We would have think through how that is done on a web page. I like your suggestion of filtering for characters etc. That isn't something we have today. Also, as you state the ability to push into the DB from an API would still allow other tools to be used to make the lists.
In the above comments, you bring up a very good point which I personally had not considered before: For a given issue, each database can quite likely have a different series name, issue number and start year. I would propose that for each DB, we have entries for ID, series, issue and year. We would make only one required and for the others it can be IDs only. For example, you would include Metron ID, series, issue and year, and then just the CV ID and.or GCD ID (assuming you have it mapped). This would allow us to have the full information for at least one DB, and would allow the user to also find matches on other dbs, but it doesn’t require you to get the series, issue year for those databases. Let me know your thoughts on this. I believe this covers your examples on naming differences (as you mention we see a lot) as well as numbering issues (legacy numbering)
Truthfully, I don't think having series detail is terribly useful, since I doubt any of the consumers (Kavita, Codex) would use it when importing the reading list.
I'm not real familiar with Codex. Kavita just recently added that feature. Komga does not look at IDs at all I believe. I remember having a conversation with gotson, the Komga dev, and he didn't think it was appropriate to use the IDs and it wasn't something he was interested in supporting. This was years ago and I think his main concern was lack of a documented standard, so it is quite possible once there is a widely agreed upon standard he would be willing to add support.
A display name (like Batman v1 #1, depending on the DB server issue string) should be sufficient for identification purposes, since the issue id's would be used for matching be the comic servers, and like I mentioned earlier, any missing issues could be tracked by the comic server.
Now, getting existing reading lists into one of the DB's (GCD, Metron) would be fairly trivial, since based on the last time I looked, most of list contain the CVID, and since Metron tracks the CV ID & GCD ID, either GCD or Metron could use that to match issues in their systems.
Agreed.
Anyway, I'm still sketching out the basic requirements and need to consult with some of the comic server devs (Kavita, Codex) to make sure I'm not overlooking anything, and see if the GCD folks have any interest in reading lists at all.
This is great. Thank you again for the effort in this area.
— Reply to this email directly, view it on GitHub https://github.com/Metron-Project/metron/issues/302#issuecomment-2797887978, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDSO7JPTOOUSJ5VZINMYZT2ZAL6JAVCNFSM6AAAAABR4EERJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJXHA4DOOJXHA . You are receiving this because you are subscribed to this thread.Message ID: @.***> flips22 left a comment (Metron-Project/metron#302) https://github.com/Metron-Project/metron/issues/302#issuecomment-2797887978
Really my vision for future reading lists wouldn't have a repo like the current implementation, since in essence, it's just another (albeit limited) database, which doesn't make a ton of sense.
Ideally the reading list data would be generated/imported from one of the current database's (GCD or Metron). Any missing issues would be tracked in the comic server, and adjusted when said missing issue is imported.
Hi Brian, I think we are in pretty close agreement on the future vision. I used the repo example in a similar way like installing extensions in Kodi. You find the repo URL add that and then you are able to view the lists available from each db, in this case Metron, GCD, etc. The reading software would then pull in the lists and updates through the API so to the user it would look integrated. Alternatively the reader software would have those repos hard coded which would get to the same end result. My use of repo was just to make it more extensible to other areas that may not have robust db support like Manga, for example.
I spent some time playing around with the TMDB list making feature that you referenced. The user inputs, title, description, a movie along with an optional comment for each movie and chooses a cover of one of the movies to show as a thumbnail. Once the list is rendered more information is shown, runtime, average rating and revenue. I think this is a good corollary to what we are doing. We do have title, description, comments in the standard. There is also a lot of other information as you said. I think it is something we can discuss to find the right level of what is in the list, versus what is picked up in the reading application by analyzing local metadata, versus what we pull from the API. I can picture when you have a list imported in the reading server you can see the date range, characters, writers, artists, etc for a given list.
My thoughts on how the database (GCD or Metron) creates new reading list would be similar to TMDB, users creates a reading list with necessary info (title, desc, etc), adds the necessary issues, and drop and drags them in the correct reading order (which I believe the current reading lists don't track), and saves. These reading lists would be accessible thru the API.
Today's XML is ordered in a list which is defined when you make the list, that would definitely be required to keep as you state.
Today we are making lists from parsing sources, searching based on titles, and then manually fixes mis-matches. A typical workflow is a website that has a list of issues, copy out the text and then run the text through the scripts. There's also some parsing of sites to make that basic workflow more automated. Some of the lists are thousands of issues. We would have think through how that is done on a web page. I like your suggestion of filtering for characters etc. That isn't something we have today. Also, as you state the ability to push into the DB from an API would still allow other tools to be used to make the lists.
In the above comments, you bring up a very good point which I personally had not considered before: For a given issue, each database can quite likely have a different series name, issue number and start year. I would propose that for each DB, we have entries for ID, series, issue and year. We would make only one required and for the others it can be IDs only. For example, you would include Metron ID, series, issue and year, and then just the CV ID and.or GCD ID (assuming you have it mapped). This would allow us to have the full information for at least one DB, and would allow the user to also find matches on other dbs, but it doesn’t require you to get the series, issue year for those databases. Let me know your thoughts on this. I believe this covers your examples on naming differences (as you mention we see a lot) as well as numbering issues (legacy numbering)
Truthfully, I don't think having series detail is terribly useful, since I doubt any of the consumers (Kavita, Codex) would use it when importing the reading list.
I'm not real familiar with Codex. Kavita just recently added that feature. Komga does not look at IDs at all I believe. I remember having a conversation with gotson, the Komga dev, and he didn't think it was appropriate to use the IDs and it wasn't something he was interested in supporting. This was years ago and I think his main concern was lack of a documented standard, so it is quite possible once there is a widely agreed upon standard he would be willing to add support.
A display name (like Batman v1 #1, depending on the DB server issue string) should be sufficient for identification purposes, since the issue id's would be used for matching be the comic servers, and like I mentioned earlier, any missing issues could be tracked by the comic server.
Now, getting existing reading lists into one of the DB's (GCD, Metron) would be fairly trivial, since based on the last time I looked, most of list contain the CVID, and since Metron tracks the CV ID & GCD ID, either GCD or Metron could use that to match issues in their systems.
Agreed.
Anyway, I'm still sketching out the basic requirements and need to consult with some of the comic server devs (Kavita, Codex) to make sure I'm not overlooking anything, and see if the GCD folks have any interest in reading lists at all.
This is great. Thank you again for the effort in this area.
— Reply to this email directly, view it on GitHub https://github.com/Metron-Project/metron/issues/302#issuecomment-2797887978, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDSO7JPTOOUSJ5VZINMYZT2ZAL6JAVCNFSM6AAAAABR4EERJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJXHA4DOOJXHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
How ( why ) would you handle a particular issue that could be in several “Reading Lists”?
Today it is very common to have one issue in many lists.
Just take a reading list for an event. There will be varying opinions on which issues should be part of a list, so you could have two lists for the same event from different sources. We try to always credit back to the original source. The vast majority of our lists are purely exports of someone else's opinion, we don't claim (or want) to be experts in the content of the list itself.
There are also a wide variety of types of lists that would have the same issue. Master reading lists, an event, a creator run, character reading order, just to name a few off the top of my head.
I don't know if there would be a limit from the API side based on resources or something. I also don't know If the there would be curation, or if there would be community lists like leagueofcomicgeeks where you have Frank's Favorite Comics, etc. Currently we have some guidelines in place, but of course anyone can submit a list, and then it is up to Diesel or one of us to approve.
Just thinking it would be a cool feature to look at one issue and then see all the associated lists for that issue. Then you could branch off from one issue to multiple lists.
flips
Hope me hijacking this issue a bit is okay. I recently stumbled upon this issue by accident when I researched something regarding metron for my project. I'm actually working on a community driven app for reading orders/lists right now and have spent the past couple of weeks on that because I was not satisfied with most one-man-show reading order/list services and solutions.
The CBL repo mentioned in this issue is definitely something I will put on the roadmap, both importing and exporting.
Maybe the metron project and I could collaborate on this in some way instead of creating two separate solutions and metron devs spending time and energy that could be used to improve metron as a comic book database.
I just released the first alpha version of the source code and deployed the first alpha build for testing.
@Lofter1 No worries. This is a project that I most likely will not get to until next year at the earliest. I envision this being implemented to allow reading lists to be created (most likely at a global & user level) on the website, and providing a REST API endpoint for users to query / retrieve the reading lists.
@bpepple my current project pretty much does exactly that, maybe minus the user level reading lists. Right now everything is public. My biggest struggle is making the reading lists completely community driven and deciding whether I want it to have a git style (copy/"clone" reading list - make changes - create a "pull request") or whether I want it to be more like a wiki style, which comes with it's own caveats like should anyone be allowed to edit any (public) list?
Community driven reading lists sound easy as they seemingly are just like a list in a spreadsheet, but once you start to work on them they quickly become much more complicated than just a spreadsheet and certain design decisions need to be made that I would never have thought about beforehand.
The project code is in a public repository on my profile now and I even have set up a semi public testing deployment for which I'm currently searching for test users.