Rationalize global state

[jellegerbrandy]

So the state of the app that is being kept is something that we need to agree on.

Does the following make sense as a first sketch?

{
    video : { // this is the "current' video: the video the user is watching, or editing, or uploading, whatever
       id: 'foo', 
      ipfsHash: '0x.... ', // where the transcoded video can be found on ipfs
      title: '...', // plus som emore info about the video
      status: 'transcoding', // an indiction of the state that the video is in
      progress: 23, // a numer in the range 0,100 giving at what point the status is
    },
   user: {
      address: 0x12345, // ethereum address of the user,
     name: 'something or other',
      balances: {
            'pti': 1224,
            'eth': 0,
      } 
   }
}

[bent0b0x]

That seems like a very rational starting point to me

[mrocha94]

It's better to stay separated.

1. Uploader has some info that is not needed on video
2. Future uploader should be a list of videos (multi video uploader)
3. Low coupling (if there is a change on the player, we don't need to change the uploader)

[jellegerbrandy]

ok, also this is fine with me, as long as we pay attention

[jellegerbrandy]

Responding to @mrocha94 's comment: in the end I decided on a generic videos map, each item in the map contains all relevent info about that video. If it is int he uploading process, it will jus thave some extra keys with more info... I agree with your decoupling argumnet, but having keeping different list of videos that need to be synced has its own problems.