Day 24

What I did: Finished migrating 2SSL documentation specs

Total time: 63.750

Comments:

This was a much bigger job than I expected because the documentation ended up having alot of extremely big holes that had to be dealt with right away along with issues in terms of terminology, storage, bootup, migration.

The biggest issue is the need to design storage that doesn't place restrictions on how a system is implemented yet provide enough universality between implementations that future installations can interact with archaic data and vice versa. In the case it's the second state, I designed a .future() and .isDisabled() requirement for all storage engines that do the following thins:

For .future() prevents the storage from being used and the second indicates if this has occurred. There isn't a way to roll back after it occurs. This is setup during the storage design so that if an application has said storage provider, that regardless of which version of the application starts that system it'll know if it shouldn't run or not.

I've also taken the NestJS concept of modules and designed the startup system to be a 5 or 6 stage start which is nice because each part can be plugged and chained using a factory pattern.

The biggest issues that I've found with the 2SSL documentation was that it ended up being morphed as my idea of what 2SSL should do was morphed.

It combined security, data transport and session management all into one confusing layer. I've tentatively broken it into three layers and completely stepping away from having it be a drop in invisible proxy between express sessions on both devices. I think the send/respond lockstep protocol is inherently rigid and while it must exist as a low level shouldn't leak into the higher level development.