Document "An API" for communication between server/client

[whit-colm]

We need a preliminary API spec which we can point to (and iterate on) so that the frontend and backend teams can go about their merry way. As long as each side can implement the API correctly, they can trust the other side to do the same. Thereby we avoid having to have each person's fingers in every single pie.

Once we have this, we can set up the most basic server-client communication and go from there (UI, database, whatever).

To discuss:

• [ ] How will the server and client communicate on a protocol level?
• [ ] What all information will need to be communicated between the client and server? (users, messages, and threads are obvious; but what about a user's active threads? what about initial login? what information is necessary that isn't immediately obvious?)
• [ ] What bullet points am I forgetting to include?

It may be pertinant to wait until after #2 is complete so that we can more easily imagine what client-server conversations may look like.

[whit-colm]

I set up a wiki page for this, but of course it's empty until we can come up with an API.

I'm shooting for the reference page to roughly-sorta-resemble a kubernetes API reference example.

[whit-colm]

Discussed in class:

1. We will draft an initial API with @whit-colm, @BeoWhitefang, @bryanbxc, @GageGaspar, and @tread-2 on Thursday, 15 Feb 2024 at 17:00 EST (22:00 UTC) via Discord with @Mina-Yuakeem providing notes on minutes later that night. Meeting link;
2. The draft drawn up will be finalized by a smaller committee of @whit-colm, @tread-2, and @nabinatiwari on the day after (17:00 EST/22:00 UTC) via Discord. Meeting link

With the API finalized, it will be available on the above mentioned Wiki page, which will be a reference for all teams in implementation. Changes can happen, but I would like a GH issue opened on the matter so we can track it.

[whit-colm]

Use a RESTful API to actually communicate any data between server and client; but open the world's widdlest itty bitty websocket that, when a client receives a signal, refreshes the webpage in the background, thus giving the illusion of "live"-ness without us figuring out gRPC or whatever.

[whit-colm]

Closed with #6