View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007452||Taler||wallet-core||public||2022-11-14 02:58||2023-09-23 16:02|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Product Version||git (master)|
|Summary||0007452: extend GetExchangeTos wallet operation to be reuse for backup or auditor|
|Description||Wallet will be accepting ToS from other service, it will be useful to reuse the same logic.|
Currently I need something similar for backup providers.
|Tags||No tags attached.|
I actually do not think that these operations are sufficiently similar enough to abstract them out.
The exchange ToS is human-readable text with an Etag, while the sync ToS is structured JSON without any versioning.
What is the difference between the ToS that backup service provider and auditor uses?
Can we make a standard way of creating, serving, querying and displaying ToS for every service so we no need to build particular solutions for every service?
I think that the exchange implementation is good enough to be replicated, and we can reuse the same logic in the wallet (and ui)
The main problem here is that the ToS of different services (exchange vs. auditor vs. sync) do not share a lot of structure:
* auditor: do we even have ToS here yet?
* exchange: multi-language, multi-format human-readable document, ETag for version tracking
(also, we might want to stop storing the ToS document, and only store which ETag was accepted by the user, as there's not a real need to review the exchange ToS while offline)
* sync: JSON format to explain fees of the service, unversioned
In general it's not a good idea to create an abstraction over things that are too different.
||I'm confused by Florian's comment: the ToS of the different services use *exactly* the same code server-side, and should follow the same structure. Sure, the auditor doesn't yet have a ToS, but that's likely a matter of time. exchange, sync, merchant & anastasis, all use the same logic with ETag and support returning in format requested by the client. They are also all versioned, so the same abstraction makes sense client-side.|
|2022-11-14 02:58||sebasjm||New Issue|
|2022-11-14 02:58||sebasjm||Status||new => assigned|
|2022-11-14 02:58||sebasjm||Assigned To||=> Florian Dold|
|2023-01-10 18:37||Christian Grothoff||Target Version||0.9.1 => 0.9.2|
|2023-01-13 17:04||Christian Grothoff||Severity||minor => feature|
|2023-01-13 17:04||Christian Grothoff||Target Version||0.9.2 => 0.9.3|
|2023-03-28 20:28||Florian Dold||Assigned To||Florian Dold => sebasjm|
|2023-03-28 20:28||Florian Dold||Status||assigned => feedback|
|2023-03-28 20:28||Florian Dold||Note Added: 0019986|
|2023-03-28 20:29||Florian Dold||Target Version||0.9.3 => 0.9.4|
|2023-04-01 16:53||sebasjm||Note Added: 0020001|
|2023-04-01 16:53||sebasjm||Assigned To||sebasjm => Florian Dold|
|2023-04-03 19:19||Florian Dold||Note Added: 0020004|
|2023-04-03 19:19||Florian Dold||Assigned To||Florian Dold => sebasjm|
|2023-04-09 21:46||Christian Grothoff||Note Added: 0020042|
|2023-04-10 14:52||sebasjm||Status||feedback => assigned|
|2023-04-13 20:36||Florian Dold||Category||wallet (TS core) => wallet-core|
|2023-09-23 16:02||Christian Grothoff||Target Version||0.9.4 => post-1.0|