NUT06: Add Mint TOS to mint info #205

2024-12-24T00:30:21Z

thesimplekid commented

2024-12-24 00:30:21 +00:00

(Migrated from github.com)

No description provided.

prusnak (Migrated from github.com) reviewed

2024-12-24 12:25:09 +00:00

prusnak (Migrated from github.com) left a comment

ToS is usually a veeery long document. I think it would be better to replace the tos field with tos_url and provide link to the document instead so the info response is not so big.

As a bonus the document can be easily formatted - let's say in HTML or PDF format.

ToS is usually a veeery long document. I think it would be better to replace the tos field with tos_url and provide link to the document instead so the info response is not so big. As a bonus the document can be easily formatted - let's say in HTML or PDF format.

06.md

					
				@ -44,6 +44,7 @@ With the mint's response being of the form `GetInfoResponse`:

				    "http://mint8gv0sq5ul602uxt2fe0t80e3c2bi9fy0cxedp69v1vat6ruj81wv.onion"

  "tos_url": "https://mint.host/tos",

```suggestion "tos_url": "https://mint.host/tos", ```

06.md

					
				@ -96,6 +97,7 @@ With the mint's response being of the form `GetInfoResponse`:

				- (optional) `icon_url` is the URL pointing to an image to be used as an icon for the mint. Recommended to be squared in shape.

- (optional) `tos_url` is the URL pointing to the Terms of Service of the mint.

```suggestion - (optional) `tos_url` is the URL pointing to the Terms of Service of the mint. ```

thesimplekid commented

2024-12-24 14:00:41 +00:00

(Migrated from github.com)

ToS is usually a veeery long document. I think it would be better to replace the tos field with tos_url and provide link to the document instead so the info response is not so big.

As a bonus the document can be easily formatted - let's say in HTML or PDF format.

You bring up a good point that including it directly in the info response would increase its size and as this is something that a wallet should fetch often we should avoid this. However, linking to a document without defining a structure or file type would make it very difficult for a client to render and show to an end user. I think the TOS should be just a text string to avoid making it difficult for a wallet to show when the mint is added.

> ToS is usually a veeery long document. I think it would be better to replace the tos field with tos_url and provide link to the document instead so the info response is not so big. > > As a bonus the document can be easily formatted - let's say in HTML or PDF format. You bring up a good point that including it directly in the info response would increase its size and as this is something that a wallet should fetch often we should avoid this. However, linking to a document without defining a structure or file type would make it very difficult for a client to render and show to an end user. I think the TOS should be just a text string to avoid making it difficult for a wallet to show when the mint is added.

prusnak commented

2024-12-24 14:21:40 +00:00

(Migrated from github.com)

difficult for a wallet to show when the mint is added.

Maybe we should strongly recommend that ToS are in a format easily rendered by a browser/app such as plain-text, Markdown, PDF or HTML?

document without defining a structure

I don't think we can come up with any reasonable structure. Laws in different countries are different.

Btw, I just checked and the current cashu.me (i know that's a wallet not a mint) ToS are currently around 11 KB and they are pretty minimal.

> difficult for a wallet to show when the mint is added. Maybe we should strongly recommend that ToS are in a format easily rendered by a browser/app such as plain-text, Markdown, PDF or HTML? > document without defining a structure I don't think we can come up with any reasonable structure. Laws in different countries are different. Btw, I just checked and the current cashu.me (i know that's a wallet not a mint) ToS are currently around 11 KB and they are pretty minimal.

prusnak commented

2024-12-24 14:26:36 +00:00

(Migrated from github.com)

as plain-text, Markdown, PDF or HTML?

Thinking more about this and HTML is probably too dangerous because it can contain some code to deanonymize user when opened :-(

> as plain-text, Markdown, PDF or HTML? Thinking more about this and HTML is probably too dangerous because it can contain some code to deanonymize user when opened :-(

callebtc commented

2024-12-25 20:19:21 +00:00

(Migrated from github.com)

I would vote for URL. Wallets can render it as a web page.

👍 1

ok300 commented

2025-02-15 09:55:14 +00:00

(Migrated from github.com)

I agree the TOS URL is better than including the TOS in MintInfo.

I have two proposals:

First, the spec should limit the linked filetype to plaintext.

this avoids confusion for wallets about how to render it
this avoids possible attack or deanonimization vectors (HTML, JS, PDF, etc)
this doesn't add extra dependency burdens on the wallet around rendering (markdown library, etc)
this is a tried and tested format for policy and TOS-like documents (most GH projects have a plaintext LICENSE file, IETF RFCs are in planitext, most installers render TOS as plaintext)

Second, why not instead add a /tos endpoint to the mint? This could return a plaintext file and replace the need for tos or tos_url fields in MintInfo.

this gives mint implementations more control (can offer a default TOS)
this makes it simpler for mint operators to add or change the TOS (likely only editing a file on the mint installation, vs. finding a place to host the TOS file, or if self-hosted: correctly configuring the reverse proxy to point to it)
this removes further attack or deanonimization vectors (e.g. when the TOS is hosted on a 3rd party and the wallet simply accesses it; 3rd party can add headers, cookies, JS, or log requests)

I agree the TOS URL is better than including the TOS in `MintInfo`. I have two proposals: First, the spec should limit the linked filetype to plaintext. - this avoids confusion for wallets about how to render it - this avoids possible attack or deanonimization vectors (HTML, JS, PDF, etc) - this doesn't add extra dependency burdens on the wallet around rendering (markdown library, etc) - this is a tried and tested format for policy and TOS-like documents (most GH projects have a plaintext `LICENSE` file, IETF RFCs are in planitext, most installers render TOS as plaintext) Second, why not instead add a `/tos` endpoint to the mint? This could return a plaintext file and replace the need for `tos` or `tos_url` fields in `MintInfo`. - this gives mint implementations more control (can offer a default TOS) - this makes it simpler for mint operators to add or change the TOS (likely only editing a file on the mint installation, vs. finding a place to host the TOS file, or if self-hosted: correctly configuring the reverse proxy to point to it) - this removes further attack or deanonimization vectors (e.g. when the TOS is hosted on a 3rd party and the wallet simply accesses it; 3rd party can add headers, cookies, JS, or log requests)

prusnak commented

2025-02-19 15:20:00 +00:00

(Migrated from github.com)

Second, why not instead add a /tos endpoint to the mint?

I guess this really depends who do we want to optimize for:

a) individuals running the mint - where there is no web, only mint - for these it is easier to just drop tos.txt on the mint server and be done with it

b) companies running the mint - running the mint, running the web server and probably also having some legal team - where it might be beneficial to have a way how to update the tos without having to bother the mint admin to change the tos (as legal team can just ask the webadmin to refresh the tos on the webserver, not the mint server)

I am fine with optimizing for a) but I wanted to show there is also a b)

> Second, why not instead add a `/tos` endpoint to the mint? I guess this really depends who do we want to optimize for: a) individuals running the mint - where there is no web, only mint - for these it is easier to just drop tos.txt on the mint server and be done with it b) companies running the mint - running the mint, running the web server and probably also having some legal team - where it might be beneficial to have a way how to update the tos without having to bother the mint admin to change the tos (as legal team can just ask the webadmin to refresh the tos on the webserver, not the mint server) I am fine with optimizing for a) but I wanted to show there is also a b)

callebtc commented

2025-02-20 11:52:12 +00:00

(Migrated from github.com)

IMO, nobody should have to download a PDF file to read the TOS. The TOS should be provided as a web link. It could be a HTML file, it could be a file on github, or anything that can be rendered in a browser. Even if it's an individual of group (a), if they put all the effort into writing a ToS, I'm sure they can find a way to host it somewhere.

Let's just use a URL.

IMO, nobody should have to download a PDF file to read the TOS. The TOS should be provided as a web link. It could be a HTML file, it could be a file on github, or anything that can be rendered in a browser. Even if it's an individual of group (a), if they put all the effort into writing a ToS, I'm sure they can find a way to host it somewhere. Let's just use a URL.

callebtc (Migrated from github.com) reviewed

2025-02-20 11:52:58 +00:00

06.md

					
				@ -44,6 +44,7 @@ With the mint's response being of the form `GetInfoResponse`:

				    "http://mint8gv0sq5ul602uxt2fe0t80e3c2bi9fy0cxedp69v1vat6ruj81wv.onion"

PDF is scary, can we just call it a normal URL?

https://mint.host/tos

PDF is scary, can we just call it a normal URL? `https://mint.host/tos`

ok300 commented

2025-02-20 18:26:45 +00:00

(Migrated from github.com)

I guess this really depends who do we want to optimize for

My proposals were aimed to optimize for the privacy and risk minimization of mint users, at minimal cost to the mint.

HTML, using a link that points anywhere on the web -- optimizes for the reverse: mint ease of setup, at the cost of mint user privacy leaks, deanonimization risks.

> I guess this really depends who do we want to optimize for My proposals were aimed to optimize for the privacy and risk minimization of mint users, at minimal cost to the mint. HTML, using a link that points anywhere on the web -- optimizes for the reverse: mint ease of setup, at the cost of mint user privacy leaks, deanonimization risks.

prusnak (Migrated from github.com) approved these changes

2025-02-23 11:31:09 +00:00

a1denvalu3 commented

2025-03-06 13:12:06 +00:00

(Migrated from github.com)

ACK

a1denvalu3 (Migrated from github.com) approved these changes

2025-03-06 13:12:22 +00:00

callebtc (Migrated from github.com) approved these changes

2025-03-06 19:32:57 +00:00

Sign in to join this conversation.

No reviewers

prusnak

a1denvalu3

callebtc

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

forgejo-admin/nuts!205

				@ -44,6 +44,7 @@ With the mint's response being of the form `GetInfoResponse`:
				`"http://mint8gv0sq5ul602uxt2fe0t80e3c2bi9fy0cxedp69v1vat6ruj81wv.onion"`

				@ -96,6 +97,7 @@ With the mint's response being of the form `GetInfoResponse`:
				- (optional) `icon_url` is the URL pointing to an image to be used as an icon for the mint. Recommended to be squared in shape.

Rows
Columns