Deck design

[kernelkind]

This issue should serve as a discussion regarding the design of a 'Deck'.

This is the current figma design for what a deck looks like.

We must have a firm grasp on this design choice so that developer time isn't wasted.

[kernelkind]

My conception of a 'deck' is: A Deck is an ordered collection of columns that are presented to the user in the main section of the app. On desktop, there can be many columns presented, but on mobile there can be only one presented at any given time.

A column is something that presents data with the deck configuration's public key, or a different public key provided when the user is creating the column.

The state of each deck is mapped to a single public key. Each column can have features that make use of an optionally provided private key. If the private key is not provided, those features cannot be used. For example, if the user has a deck saved with public key A, but they do not have the secret key that matches to A, they will not be able to 'like', repost, or comment.

The state of a deck, aka it's 'deck configuration' is a parameterized replaceable event nostr note.

If a user makes their deck public (no encryption), then you can load other people's decks https://github.com/damus-io/notedeck/issues/77#issuecomment-2118907966

Users of the app can switch between decks using the bottom left icon in the figma design. This removes the current deck from the screen and populates it with that public key's deck configuration

What are your thoughts on this conception? Open to everyone and especially @jb55 @robagreda @alltheseas

[jb55]

Sounds right to me! A good example of why this makes sense is with muting:

Imagine if you are using someone elses notifications you still want to use your own mute list. This is why I think column-scoped user accounts don't really make sense. The mute configuration should be associated with the user account and applies across your whole deck.