bunch of design decisions related to the entire architecture of Stremio (notifications, calendar, library)

[Ivshti]

• decision: streams for youtube should just be embedded in video.streams (the results of the addon itself)
• API: consider filtering out jibberish in some way (other, type trailer, etc.)
  • also, pruning removed items that have not been touched for 2 years
  • decision: will use a planner function for v4.4 to stop syncing those items; and will prune them from our DB via a script; in stremio-core, it will be implemented as a simple filter in the LibAddon
• decide what to use for Continue watching; decision: a catalog from the Library add-on; but
  • those things would be difficult if the manifest had to be updated, but that's easy since it's just a manifest() function within the same app
  • since the catalog will return a different response type (libItems), it should be filtered out of CatalogFiltered and CatalogGrouped; the catalog will be of type any, which will be filtered out of CatalogFiltered
  • the catalog can be refreshed individually by triggering a AddonRequest when the lib is updated
  • all catalogs in the LibAddon will contain the user ID in their ID, to avoid race conditions or cache issues
  • the Library will use a custom Load action, which will request from the appropriate catalog
• calendar can be implemented via addons (library addon)
  • upcoming eps are a related problem
  • Detail model: upcoming vs released videos #17
  • Community add-ons should be able to add entries to the calendar  #24
  • Notifications model #79 Notifications model: upcoming videos #95
• stremio-core: consider merging Streams and Detail, cause Streams should show streams from .video.streams if any; also this is tightly coupled with open(); decision: will be separate
  • separate containers, Detail will just output the meta to render, and the selected_video; Load action: Detail(..., Option<video_id>); if selected_id is None, the libItem.state.video_id will be used
  • Streams will just load streams from addons
  • UI will use both Detail and Streams, and it will trigger Load(Streams(...)) if the selected_video does not have .streams; if it does, it will render that
  • TryOpen will take the full video to determine whether to request streams from addons or not
• rust-based shell? few binaries: app, server (maybe those should be in 1, with different modes) and autoupdater; the missing piece here is the web view; ultralight or servo are candidates
  • could happen and would be great, but it requires servo or ultralight becoming more mature
  • before that, we can implement the existing player protocol in C++ for MPV and Chromecast into the existing shell
• addon spec: decide what extra properties with required: true will be allowed in CatalogFiltered; e.g. genre is one such example
  • adding an extra required prop could be used to make a catalog not appear in Board
  • in light of this, figure out whether behaviorHints noBoard/noDiscover are needed; probably not
  • full spec describing stremio-recognized extra props (search, searchIndex, genre, skip, possibly location, etc.)
  • Solution: in CatalogFiltered, filter catalogs by .extra.iter().all(|e| !e.is_required || e.options.map_or(|o| !o.is_empty(), false)); or also || e.name == "onlyDiscover" if we want a santinel value that just flags a catalog as only visible in Discover

---

Added later on:

• there will be an API call to that returns toast notifications to be shown to the user, at certain lifecycle moments of the app (on open, every day, etc.); this will be used to inform the user of, for example, expired Trakt authentication, or a new stremio version: see relevant issue
• Addons catalog should use a special addons resource, that can be implemented by any add-on (therefore allowing one addon to add items to the catalog, i.e. repositories); cinemeta will implement it for official/third-party add-ons
  • this adds a few benefits
    • repositories
    • more flexible control from the server side, including what the catalogs are (e.g. we can remove "third party" in some jurisdictions)
    • pagination, cause we can just use skip
    • we should consider a ManifestPreview, and pulling the whole manifest when installing
    • re-use code between addons/discover pages (CatalogFiltered)
    • addon dependencies: can help the addon dependencies problem, by allowing an "Install all" button for whole catalogs (we can use behaviorHints for this)
  • Decide: should we display the UI selectors as Type > Catalog or Catalog > Type; first one is the same as Discover; second one can be done via any catalog type plus extra prop for the type
    • which one is better for UX?
  • Implementation: should we reuse CatalogFiltered
    • we add .addon_catalogs to the manifest, and make CatalogFiltered generic over T: CatalogAdapter which has T::catalogs(x: &Descriptor) and T::resource() (that return x.manifest.catalogs, "catalog" or x.manifest.addon_catalogs, "addon_catalog"); we will have to use try_into for the response, as models/items_group does
    • another thing we can do is add a resource_name to each catalog; that way instead of manifest.addon_catalogs, we'll have them in manifest.catalogs but we'll just filter by resource_name
    • alternatively, addon catalogs will be hidden behind a required property, and we will instantiate CatalogFiltered with some extra prop already passed; this seems hackier
  • Should we introduce ManifestPreview
    • pro: faster loading of catalogs
    • pro/con: modals will always have to load the manifest; if the addon is down you won't be able to install it

[Ivshti]

How to re-implement Calendar/Notifications to be add-on based

And as a result, not requiring additional backend work and more importantly, extendable

• The add-on system would gain "multi" catalogs that return CatalogDetailResp { metasDetailed: Vec<MetaDetail> }; they take a required extra prop ids, which is in the format ["tt0944947", ...]
• cinemeta/channels and potentially others (Community add-ons should be able to add entries to the calendar  #24) implement those, and implement "last-videos" catalog IDs which return a MetaDetail with videos being set to the last N videos; even if cinemeta is static, this can be done via a Cloudflare worker
• LibAddon would implement resource(s) that the Calendar and Notifications can use directly
  • for example, a new /videos/ resource, with extra prop whereIsNew which allows you to specify either new or non-new videos
  • alternatively, we can use the same CatalogDetailResp but without ids and instead with isNew - seems like the cleaner way to go
• the LibAddon would query all "last-videos" catalogs with ids set to the most watched series/channels of the user
• this will happen in an asynchronous tick (in action: UpdateLastVids, out action: LastVidsUpdated); this out action should trigger re-requests of the resources used for Calendar/Notifications
• if any of the addons errors or times out, we can fallback on our own cache (managed by the LibAddon)
• results of the resources for Calendar/Notifications can update even offline and without LastVidsUpdated happening: since every time we recalculate the results, some videos that were upcoming might have become available
• the way we mark notifications as seen is by keeping state.last_video_released for each LibItem; all of the videos where released is larger than state.last_video_released are considered new to the user
  • for new library items, this value won't be set, and we will use the libitem ctime instead
  • compat: we can update this property each time a datastorePut is done for a notif to maintain compatibility with older versions
  • caveat: compraed to the previous system, this obviously cannot keep state for each video individually; this shouldn't be a big issue, since users watch videos in succession and there's also watched (watchedBitfield)