// For efficiency's sake, structs intended for use with the FemtoStar Protocol must be strictly-aligned without padding, with little-endian byte ordering.
// This avoids wasting network capacity on padding, and avoids the performance impact of reordering on most modern platforms (most importantly x86 and RISC-V)
// while ensuring compatibility with strict-alignment architectures. Take note: This is NOT typical network-order!
// Additionally, note that most structs do not explicitly include what target they are for (even the target descriptor!). Keeping what is for what target is
// not a core part of fstoken, and is the responsibility of the software using fstoken (e.g. ctm or an implementation of fsp). This keeps tokens light in
// situations where which target is relevant is unambiguous (e.g. in the session setup with a satellite, where the satellite is always the same target).
// A target_descriptor is a stored description of a target, which can be used to request, verify, and sometimes sign tokens for it.
// A request descriptor is a structure held privately by the requester until they receive a signature for their request - it is then used to generate a token
typedefstruct{
#pragma scalar_storage_order little-endian
byteblinding_factor[32];
bytetoken_id[IDBYTES_MAX];
}fstoken_request_descriptor;
// A request is a structure sent by the requester to the signer, to be signed and a signature returned. It need not be kept private.
typedefstruct{
#pragma scalar_storage_order little-endian
byteid_blind[48];
}fstoken_request;
// I'm unsure if these "single-item structs" make any sense - signatures in blst are independent of system or scalar_storage_order endianness anyway