Discussion: restructuring tags to support multiple hashes for content addressing

[lovvtide]

Note: The following is premised on the existence of a standalone event kind for file metadata. (See https://github.com/lovvtide/nostr-torrent/issues/2) Also note that kind 9 to denote a media event in the following examples has been replaced by kind 2001 (See See https://github.com/lovvtide/nostr-torrent/issues/1)

Currently

Here's an example of a media event in the current proposal:

{
    "created_at": 1679552209,
    "content": "",
    "kind": 2001,
    "tags": [
        [
            "i",
            "a19a70552cc801415a6071993c04b3ab21572438",
            "https://media.satellite.earth"
        ],
        [
            "m",
            "video/mp4"
        ],
        [
            "name",
            "Watts.mp4"
        ],
        [
            "size",
            "26685219"
        ]
    ],
    "pubkey": "ff27d01cb1e56fb58580306c7ba76bb037bf211c5b573c56e4e70ca858755af0",
    "id": "cb657467b824fe8b0f4a7d7db6380e30340b18c03ab14e56849d59c85435628a",
    "sig": "440e4e8c9616d2d90ddaeb15d1084d297b465638ad0cd1d3527951e7173cb25d50d55d396ff068d1de649bedd633ac82017351a3f5f4dc7e9a9c1013cb37ffa1"
}

In the above example, we have four tags:

• An indexed i tag that contains the torrent infohash of the file along with a recommended host for the client to download it
• An indexed m tag that contains the file's mime type
• A non-indexed name tag that contains the filename
• A non-indexed size tag that contains the file's length in bytes

Proposed Restructuring

It would be nice if the event could support multiple content-addressing schemes. Here's how that could work — basically each hash has its own tag, and the tag includes a marker to indicate what kind of hash it is, i.e. how the client should handle it.

{
    "created_at": 1679552101,
    "content": "",
    "kind": 2001,
    "tags": [
        [
            "x", 
            "a19a70552cc801415a6071993c04b3ab21572438",
            "https://media.satellite.earth/torrent",
            "torrent"
        ],
        [
            "x",
            "bafybeia7fsunya52qm2ov3wqtrv2andjjk3nqo273a3clpm76roypqgefq",
            "https://ipfs.io/ipfs",
            "ipfs"
        ],
        [
            "m",
            "video/mp4"
        ],
        [
            "name",
            "Watts.mp4"
        ],
        [
            "size",
            "26685219"
        ]
    ],
    "pubkey": "fbd992dbccdd4186f4ef25b7d72ea47387a59227493f8569b17963afae4e4d33",
    "id": "faea2a5dbe12c877c1201e91ec909e3161a1ba8714fdca4d3077f6d4b0780191",
    "sig": "10c0d634ea0b9ae085205c3951367da784268a0cdf4a18b969aba7c06b1a59abf96b7f5f4e2d3791389dff71ff5527c33e3405e8decad9b3e4419406124dc46a"
}

What's changed?

1) The i tag has been renamed to x to reflect that the tag doesn't necessarily refer to a torrent "infohash" but rather a "hash" more generally. 2) There are now two x tags, one with the torrent infohash of the file and another with the ipfs hash of the file. It should be noted that including an ipfs hash (or any other hash) is entirely optional and is just used as an example. The goal is to support optional additional content-addressing schemes to increase redundancy and therefore censorship resistance. There can be any number of different hashes of the same file, each with its own x tag and recommended host. 3) A marker referring to the content addressing scheme (i.e. torrent or ipfs) is included as the fourth element of each x tag so the client knows what to do with the value of the tag. (this ordering of values intentionally imitates the way that markers are used to discriminate between e tags as described by NIP-10). We can start with just torrent and ipfs but it would be a good idea to have a canonical list of markers in the NIP and continue updating that list if/when consensus forms around new content-addressing protocols.

[degenrocket]

Looks solid :+1:

I'd suggest to specify a recommended host after a hash kind since a recommended host should be optional.

{
    "created_at": 1679552101,
    "content": "",
    "kind": 2001,
    "tags": [
        [
            "x", 
            "a19a70552cc801415a6071993c04b3ab21572438",
            "torrent",
            "https://media.satellite.earth/torrent"
        ],
        [
            "x",
            "bafybeia7fsunya52qm2ov3wqtrv2andjjk3nqo273a3clpm76roypqgefq",
            "ipfs",
            "https://ipfs.io/ipfs"
        ],
        [
            "m",
            "video/mp4"
        ],
        [
            "name",
            "Watts.mp4"
        ],
        [
            "size",
            "26685219"
        ]
    ],
    "pubkey": "fbd992dbccdd4186f4ef25b7d72ea47387a59227493f8569b17963afae4e4d33",
    "id": "faea2a5dbe12c877c1201e91ec909e3161a1ba8714fdca4d3077f6d4b0780191",
    "sig": "10c0d634ea0b9ae085205c3951367da784268a0cdf4a18b969aba7c06b1a59abf96b7f5f4e2d3791389dff71ff5527c33e3405e8decad9b3e4419406124dc46a"
}

[lovvtide]

I'd suggest to specify a recommended host after a hash kind since a recommended host should be optional.

This was my first thought as well. The only reason I suggested making the order ["x", <hash>, <host>, <marker>] instead of ["x", <hash>, <marker>, <host>] was to parallel the way that markers are used to describe e tags according to NIP-10 (https://github.com/nostr-protocol/nips/blob/master/10.md), e.g. ["e", <event-id>, <relay-url>, "reply"]. I do agree that it would be more efficient to place the recommended host as the final element so that it could be optionally omitted, but I wonder, do you think it's worth it to tolerate having an empty string sometimes to remain consistent with this pattern?

[degenrocket]

do you think it's worth it to tolerate having an empty string sometimes to remain consistent with this pattern?

Let's raise that question after submitting a NIP and leave that up to community to decide.

[lovvtide]

Alright. When submitting the NIP let's go with host last as you suggest, and we can refer to this issue.