Re: [Taler] Exchange Terms of Service

[Sebastian Javier Marchano]

I agree with your expectations, maybe something to fix before the 9.2 release.

1.- wallet core should request text/markdown

2.- add documentation about missing section

3.- exchange should check and fail fast if ToS has the wrong format

4.- wallet-ui should keep fist section open of ToS

Also, more importantly and not yet implemented, users should be able to access the ToS any time offline even if the exchange has updated the ToS.

If the exchange has updated the ToS, should the user be able to access old and new ToS? Since it may have coins based on previous rules.

--
Sebastian

On Fri, 6 Jan 2023 at 13:56, Florian Jung via Taler <taler@gnu.org> wrote:

Addition below

On 1/6/23 17:50, Florian Jung via Taler wrote:

Hi,

When configuring my exchange, I found that the Android Wallet app has certain requirements regarding the terms of service that I have not found in the documentation:

1. It requests the .txt file (which has text/plain MIME type, not text/markdown), even though it expects it to be formatted as valid markdown. If a .md file exists in the TERMS_DIR, it is ignored.
2. Not only needs the file be formatted as valid markdown: It also must have at least one top-level-heading. Otherwise, an unhelpful error message is thrown: "ToS does not follow the correct format".

Is there a specific rationale why it requests the wrong MIME type, when RFC7763 exists?

Also, collapsing the headings makes the ToS harder to read in cases where the exchange operator actually tries to keep them short. Maybe a better collapsing heuristic could help here, such as:

• Collapse all sections only when the total ToS length exceeds 3-4 screenful of text.
• Always expand the first section and collapse the rest.

Additionally, I would like to discuss how to deal with section-less documents:

• Allow them by treating them as one large never-collapsed section.
• Continue to disallow them, but then adapt the documentation[1] accordingly and improve the error message to actually tell what the problem is. In this case, probably the exchange itself should emit an error when starting and most probably, fail to start until it is fixed. (Fail early, fail fast.)

My preferred solution would probably be a hybrid of "never collapse the first section" and "don't collapse anything if the document is only 3-4 screenful", plus clearly stating in documentation that ToS needs sections, failing the exchange startup if violated.

What do you think?

Cheers,

Florian

Ah, seems like there's a design document[2] actually stating the ToS requirements. This info lacks visibility and should be part of the exchange operator manual [1].

[1] https://docs.taler.net/taler-exchange-manual.html#terms-of-service

[2] https://docs.taler.net/design-documents/003-tos-rendering.html