# Weeve Users + Auth Approach:

## MS1:
- Enable Disk Encryption (Data at Rest)
- This avoids Cloud Provider to read data
- User Schema MongoDB:
- ID (UUID)
- Email (Encrypted using - Field level encryption - Available in most languages (GO))
- Rest fields plain is prob ok
- Consider moving rest of the Model to MongoDB as well, since otherwise the server object will need to maintain two different storage interfaces (ugly).

Go Model Example:

type Role int
const (
	SuperAdmin    Role = iota + 1 // EnumIndex = 1
	Admin                         // EnumIndex = 2
	Host                          // EnumIndex = 3
	Attendee                      // EnumIndex = 4
)

// User represents the schema for the "Users" collection
type User struct {
	ID     primitive.ObjectID `bson:"_id,omitempty"`
	Email  string             `bson:"email,omitempty"`
	FName string              `bson:"f_name,omitempty"`
  LName string              `bson:"l_name,omitempty"`
  ProfileImageUrl, string   `bson:"profile_image_url,omitempty"`
  SocialUrl, string         `bson:"social_url,omitempty"`
	Roles   []Role            `bson:"roles,omitempty"`
}

Implementation steps:
- Create new model User under `models/`
- Create new mongodb driver interface under `storage/`. Follow similar setup as leveldb one.
- Instantiate new mongodb client connection at boootstrap.

API Access:
Here the challenge is on who has access to what and when.
Since this is coming before Authentication is in place, I would:
- Create API CRUD operations, but not expose them by default.
- The Create Profile API can be enabled, so UI can start playing around with it.
- The READ/UPDATE stay disabled for now (only manual manipulation in DB)
- When user joins, and he/she has a profile, return the profile data there, so UI can display accordingly (temporary until Auth is there)

Need more info on "account types" mention

## MS2:
- When user registers through the oAuth Provider, I do not think we need a magic link, since the ownership of that account is verified by the oauth provider already.
- All requests should go through the GO backend, there would be a series of redirections before the user can access the resources.
Here is an easy example of how to set it up in the backend using the auth middleware already in place: https://www.loginradius.com/blog/async/google-authentication-with-golang-and-goth/
or for linkedin https://github.com/golang/oauth2/blob/master/linkedin/linkedin.go
- Having as a separate service is ideal, but will come with more overhead due to redirections, securing the service api access etc. I would implement first within the go backend.

## MS3:
- Create new Event types only available/actionable by Host/Admin etc ...
- Pass new input channel to the execute function in SessionManager, and locks waits for anything in it to react. Similar to how errChan is used in the runSession function with a non-blocking select.

## MS4:
- Use AWS k8s self hosted and create the HELM templates defined in the apps gitlab repos.
- All resources should be there as manifests
- Modify gitlab to talk to the new k8s api server, and define new secrets/certs to perform deployments.

## MS5:
- In Go backend create Video Provider interfaces and correspondent implementations for each of the current well known ones (Jitsi Cmmunity & JaaS).
- An interface will define which functions are available globally (independently of the video provider, if possible)
- Then during session it will be resolved based on session configuration
- Follow Jaas docs + https://github.com/8x8/jaas_demo/tree/main/jaas-jwt-samples/go

## MS6:
Need more understanding