collection_types field with list of all claim/stream-types contained in the collection

[jessopb]

Edit: This has to be done at lookup time in case streams associated with claims change.

It would be handy to enforce collection_type s such as 'mixed', 'channels', 'playables', 'photos', etc. because 1) then they can be displayed and filtered by type, 2) a 'channel list' can be made to only include channels, etc. and 3) so that less logic is required to route a collection to its proper display, 4) we don't have to get and inspect every claim to be sure what the type intention was (initially, we load the first (5) claim items). 5) it's impossible to know whether the intent is for a mixed list.

Alternative to having a type field: Collections are anything-goes. Collections created on one device force a guess as to the intentions when pulled to another device OR the entire list must be inspected claim by claim.

[jessopb]

Team suggested that sdk should derive current type from all claims before sending collection with collection_type so that app knows what's in it without ~resolving~ fetching all the claims by claimIds. This would be acceptable.

Create UX: Originally I imagined that when creating a list for a specific content type, they would make a choice. Perhaps not? App can make the same assessment of collection type for local unpublished / edited lists.

Update UX: When user goes to add a file to an existing list, they should initially only see matching types unless "show all" or such.

Types: All existing stream-types plus some combo types such as playable and mixed, and channel types. audio, video, audio/video, mixed, images, models, docs, etc.

Display UX: App reads collection type to load the appropriate display mode.

[lyoshenka]

a few questions:

1. could you list all the types you'd want to include in the first version? what does "playable" and "mixed" mean?
2. what's the behavior if collection_type is not set?
3. im guessing the sdk will be responsible for updating the collection type when content is added or removed? will that be a pain if a collection has 1000 claims and we have to resolve them all?
4. what can we do to protect API users from assuming that the collection_type is accurate and not just the sdk's best guess?

[jessopb]

My original idea was that users specify the type, sdk stores the type and enforces all additions, but I'm persuaded that that's bad ux.

Possibly all of the above questions dissolve except the hub burden if the collection claim simply returns collection_claim_types = [...stream_types, ...claim_types].

I can't answer the hub burden question.