Part of the information that /history should be responsible for returning is "who issued this commit / data state change". Another ticket has been added to add the original txn and the txn's author to the commit files. This would leverage that information and return it to the user.
In scenarios where server accepts unsigned transactions, the "identity" of server itself will be recorded as the author
Note: server has config for setting a particular private key as the machine identity for the server. The public side of that key (probably its did:fluree:XXX / pubkey hash) would be the identity recorded for any unsigned transactions that are then signed by the server
Implementation Details
In v2 Fluree, author identity was only returned optionally (i.e. if the request had showAuth: true). I don't know that this has to be optionally included -- I would guess that, only if the lookup adds some computational work should we make its invocation optional
I know that using commit-details: true would, technically, also return the identity of the issuer inside the commit details JSON, but this data is of enough direct importance that this feature should not require users to have to comb through & parse JSON data, but rather return the issuer's identity as a top-level key (e.g. assert, retract, auth ... or something to that effect)
aaj3f
commented
7 months ago
Description
Part of the information that
/historyshould be responsible for returning is "who issued this commit / data state change". Another ticket has been added to add the original txn and the txn's author to the commit files. This would leverage that information and return it to the user.In scenarios where
serveraccepts unsigned transactions, the "identity" ofserveritself will be recorded as the authorImplementation Details
In v2 Fluree, author identity was only returned optionally (i.e. if the request had
showAuth: true). I don't know that this has to be optionally included -- I would guess that, only if the lookup adds some computational work should we make its invocation optionalI know that using
commit-details: truewould, technically, also return the identity of the issuer inside the commit details JSON, but this data is of enough direct importance that this feature should not require users to have to comb through & parse JSON data, but rather return the issuer's identity as a top-level key (e.g.assert,retract,auth... or something to that effect)