The next we're working is cleaning up the /session end points. The main issue being that we're currently mixing a new organization with an admin member with the session modules.
Session itself should just be login, logout and get session. Creating a new organization overlaps with this a little bit as an organization with a member needs to exist to be able to login to it in the first place.
The reality is that these are different modules where the functionality overlaps with each other. We need to create a new organization, we need to create a new member, and we need to login that member once these two have been created.
Which means that now that we're looking at it, the next step is to untangle these issues and make a clear set of modules going forward. One of the questions that comes from this is what role does the mnemonic play with the organization and members?
Originally my thinking was than an organization has a monotonic. Each member in that organization has an address generated from that mnemonic. Which means that the owner of an organization has access to all of the funds spread across the different members and their respective wallets.
Looking back at this part of the application, I was tempted to remove this link to simply have a GUID for the organization, and then generate a unique one-off address generated from randomness for each one of the members. Which would make the application a lot simplier. But it seems kind of short sided as far as implicatations go for how it would shape the application from here on out.
That can change can be applied, but it should be carefully considdered on what the implications are and if the functionality is desireable.
The same could be said for the current functionality, as a blown mnemonic would allow for all of the funds in the organization to be drained.
I think that right now the focus of the application should be to go with one and then stick with it. We can edit a specific aspect of the application once we have converted it to TypeScript and added checks in. Right now the only criteria with proceeding with specific functionality is that I slightly prefer it over another option.
Whether that is the correct option or not is a separate point of scrutiny to be applied from there.
That being said we can break down the functionality of how creating a new organization should work. As a request we get the information for the organization, and the member.
For the member to exist, the organization exists first. Which means that we create the organization, we then save the mnemonic. We create the first admin user. We then derive the private key for the user from the first index of the mnemonic. And then we automatically log the user in.
Right now we have mnemonics and private keys as separate tables from the member and organization respectively. This is likely a point to come back and address with making the database as simple as possible. But that's another story for another layer of encapsulation. For now we've updated the application to have the create organization, create member, and login/logout aspects in their own modules.
We're getting closer as far as refactoring end points into their own modules. It looks like the next step is to take another look at the invoice modules and see what we can clean up.
