API Routes to implement

/stamps
- POST
- PUT
- GET
/stamps/{stamp_id}
- GET
- PATCH
- DELETE
/documents
- POST
- GET
/documents/{document_id}
- GET
- PATCH
- DELETE
/documents/{document_id}/stamps which is passed to /stamps with document_id set.
/events
- POST
- GET
/events/{event_id}
- GET
- PATCH
- DELETE
/events/{event_id}/document which is passed to /documents/{document_id}
/events/{event_id}/user which is passed to /users/{user_id}
/users
- POST
- GET
/users/{user_id}
- GET
- PATCH
- DELETE
/users/{user_id}/events which is passed to /events
/users/{user_id}/specimen which is passed to /specimens/{specimen_id}
/users/{user_id}/specimens which is passed to /specimens
/users/{user_id}/wallet with GET
/users/{user_id}/transactions which is passed to /transactions
/specimens
- GET
- POST
/specimens/{specimen_id}
- GET
- PATCH
- DELETE
/specimens/{specimen_id}/owner which is passed to /users/{user_id}
/transactions
- POST
- GET
/transactions/{transaction_id}
- GET
- PATCH
- DELETE
/transactions/{transaction_id}/user which is passed to /users/{user_id}

Notes

Consider making metadata a JSONB column for storage of arbitrary metadata which can be updated over API.
Consider suggesting storage of image name and type in the metadata column (for guidance on how to decode the image).
For the demo, uploaded document data can be from a TTK canvas widget just for fun maybe?
Could also straight up demo the client in godot but hmm
Or we could demo it from Twitch redeems etc.. but tbh canvas does make sense? With simulate buttons? Hmm. Or redeems could simulate.

Demo client plan

For one thing we need to make sure we have documentation and examples for all the common flows, including the routes and payloads and replies. We want to make a simple usage guide essentially, just a few pages, with each of the key requests and how we suggest they should be used (e.g. stateless event and specimen creation vs cached user_ids, updating documents via event, or specimen via user etc.)
It would be nice to write a bit of documentation for each route as well for a full API reference, although I think that is less required. Maybe it would even make it more confusing, not having everything in one place. Although I think it would make sense to properly index the routes in this wiki still, and add a few good examples to each route. Even a small library of examples.
For the actual demo, we have two parts. One is the bot side, which will actually be the framework that Discord-side UI is built on. Need to make sure this is fairly solid. We expect that alllen will actually build new tools using the framework I put in place here.
The other part is the client side which will be a throw-away client to just illustrate some of the flows I expect to be used, and how to actually interact with the API, e.g. authentication, stateless event/specimen creation, or non-stateless event/specimen creation, and editing (e.g. posting stamps).

I should make an explicit list of the flows I want to demonstrate and have available in the demo client.

Stateless event creation
Modification of an event (e.g. adding a stamp) after creation (and updating the document at the same time)
User-id caching
Stateless specimen creation
User fetching
User document fetching
Fetching events with particular seal/type
Uploading and downloading images of course

Is it worth making a python API client along the same lines as, say, the toggl HTTP client? Could be good for API testing. Just keep each route explicit. Very explicit.

Then we can just show off test functions instead of a 'fancy' UI, and we can make a simple twitch client to demonstrate hooking it into redeems. We can also use PIL to simulate approve and deny stamps with rotation and position.

He can possibly adapt the HTTP client I make to Godot as well, maybe, depending on how the class system works there. Or he can just bring along the routes that he needs.

Okay I think that makes sense. We have tasks.

Documentation

Add an authentication page to the docs
Write suggested usage/flow documentation for each of the common flows, i.e. how I suggest the API be used.
Move the route collections to their own docs pages and attach example requests and responses

Local client

Write an HTTPClient class with all of the routes implemented
Write image generation functions for creating each type of card and adding stamps to a card
Write a collection of demo methods which each demonstrate a single flow or task
Test these myself
Write a very basic twitch-capable bot which uses the client to react to a few test redeems.

Bot client

Make the profile connection nicer, e.g. persistent view with Button -> ephemeral view with link button which updates on auth (also have the ephemeral view available by command).
Make a simple DOM and some factory methods for the relevant objects (maybe just the events)
Make some basic admin commands to query the objects and see e.g. matching event cards
Make some basic user commands to view your own cards and see your specimen status and wallet
User profile migration code to update the datamodels

For the demo

Show how to setup and test these locally, both running the API and the bot (needs postgres setup)
Give ssh key to the server account
Give key to the pgAdmin instance on the server
Invite to postman
Run through the demo program, and the demo client.
Notes about sending images, sending stateless users.
Updating stamps and documents. Want to get to the point of getting and sending some basic data from overlay side if possible.
Viewing events on bot-side.
Viewing specimens on bot-side.
Emojis can be customised