Discussion: should a hash kind be specified in a recommended host URL

[degenrocket]

Since the original idea of using one infohash to identify a media file has been expanded to support multiple hashes (See #3), it's important to achieve consensus on the URL structure of a recommended host.

[
    "x", 
    "a19a70552cc801415a6071993c04b3ab21572438",
    "https://media.satellite.earth/torrent",
    "torrent"
],
[
    "x",
    "bafybeia7fsunya52qm2ov3wqtrv2andjjk3nqo273a3clpm76roypqgefq",
    "https://ipfs.io/ipfs",
    "ipfs"
],

Should a recommended host URL contain a hash kind or not?

Examples:

Hash kinds are specified. Option 1:

https://media.satellite.earth/torrent/a19a70552cc801415a6071993c04b3ab21572438

https://media.satellite.earth/ipfs/bafybeia7fsunya52qm2ov3wqtrv2andjjk3nqo273a3clpm76roypqgefq

Hash kinds are specified. Option 2:

https://media.satellite.earth/torrenta19a70552cc801415a6071993c04b3ab21572438

https://media.satellite.earth/ipfsbafybeia7fsunya52qm2ov3wqtrv2andjjk3nqo273a3clpm76roypqgefq

Hash kinds are not specified:

https://media.satellite.earth/a19a70552cc801415a6071993c04b3ab21572438

https://media.satellite.earth/bafybeia7fsunya52qm2ov3wqtrv2andjjk3nqo273a3clpm76roypqgefq

Pros of specifying a hash kind in the URL:

• ???

Cons of specifying a hash kind in the URL:

• A hash kind will have to be mandatory in a media tag (x) of a media event (kind 2001) and in a media tag (x) of a text note event (kind 1).

• The URL structure will change if the naming convention for hash algorithms will change, meaning that recommended hosts will have to serve media files with different URLs. For example, torrent can be changed to infohash or nostrhash.

https://media.satellite.earth/torrent/a19a70552cc801415a6071993c04b3ab21572438

https://media.satellite.earth/infohash/a19a70552cc801415a6071993c04b3ab21572438

https://media.satellite.earth/nostrhash/a19a70552cc801415a6071993c04b3ab21572438

[lovvtide]

Hash kind does not need to be specified in the pathname URL of the host. It's totally implementation-dependent. For Satellite's media endpoint, I think I will include /torrent and (if I end up supporting /ipfs) just so I can more easily parse the request on my server. There might be, for example, a host that looks like https://media.example/foo/bar/ and that's fine, because the client just appends the hash to the URL.

But maybe though it would be better to stop calling it a "host" and call it an "endpoint" ?

[degenrocket]

If we don't standardize the pathname URL structure of a host ("endpoint"?), then we will end up with a situation when hosts have different pathname URL implementations, which can cause certain issues.

For example, a recommended host can not only be added to a media event (kind 2001), but also be set on an account-wide level with a kind 0 event (see documentation).

Let's say a user created a media event (kind 2001) with a recommended host https://media.satellite.earth/torrent and a few months later stopped using satellite.earth and updated his profile with a kind 0 event by adding https://media.degenrocket.space as a default host.

If we don't standardize the pathname URL structure, then a client will have to make multiple requests to download a media file:

https://media.degenrocket.space/a19a70552cc801415a6071993c04b3ab21572438

https://media.degenrocket.space/torrent/a19a70552cc801415a6071993c04b3ab21572438

https://media.degenrocket.space/infohash/a19a70552cc801415a6071993c04b3ab21572438

https://media.degenrocket.space/foo/bar/a19a70552cc801415a6071993c04b3ab21572438

[lovvtide]

Why wouldn't the pathname be included in the account-wide hosts list?

[degenrocket]

Why wouldn't the pathname be included in the account-wide hosts list?

Because if we don't standardize the pathname URL, some hosts ("endpoints"?) will serve media files at the root URL https://media.example.com/hash, while other hosts will add the name of the hash (torrent, ipfs, etc.) to the pathname https://media.example.com/torrent/hash.

Thus, if user's default host uses the second approach, a user will have to specify each endpoint for every kind of supported hashes in the kind 0 event, e.g.:

https://media.example.com/torrent https://media.example.com/ipfs https://media.example.com/nostrhash https://media.example.com/some-other-hash

Then a client will have to find a default host (in this case it's probably an "endpoint") for a specific hash and use it to request a media file.

https://media.example.com/torrent/a19a70552cc801415a6071993c04b3ab21572438

[degenrocket]

But maybe though it would be better to stop calling it a "host" and call it an "endpoint" ?

Can the same "host" have multiple "endpoints"? For example,

https://media.example.com/torrent
https://media.example.com/ipfs
https://media.example.com/free
https://media.example.com/paid
https://media.example.com/free/torrent
https://media.example.com/paid/torrent

If we standardize the pathname URL structure for the media files (and later free, paid, etc. content), then a user will have to only specify a default host with a kind 0 event once, while the endpoints can be constructed by clients/relays by prepending/appending words like media, free, paid, torrent, other-hash-name, etc.

If we don't standardize pathnames, then users have to specify all endpoints instead of one account-wide host.

[lovvtide]

I see what you're saying. Good point. Ok then yeah we need to decide if

1. If there's going to be pathnames at all
2. If pathnames, what should they be

Pros of not having pathnames at all:

• Simplicity. Server just uses the hash (of whatever kind) as an agnostic key to serve the data from its object store

Pros of having a pathname that matches the hash kind:

• More options of how to implement a server and parse requests. For example, maybe you want to have an amazon bucket that handles all requests to /torrent/* but you want to support ipfs by serving it from a local gateway, in that case you can just create some middleware that routes/ipfs/* requests to somewhere else.

I'm actually leaning toward option 1. Simplicity. No pathnames. I can't think of a concrete scenario but I have an intuition that baking pathname prefixes into the spec might preclude certain kinds of implementations in the future. The less details the client and server have to keep track of, the better, Like there may be some app that only has a list of hashes.

I think the same logic applies to the /free /paid thing... It's a really cool idea but I think that if servers end up doing auth it's going to be using request headers (maybe with a signed event to prove who the request is coming from).

I say for now we keep it simple and serve at the root. What do you think?

[degenrocket]

Yes, I also think that simplicity is the right way to go, so hosts should serve media files at the root URL.

More options of how to implement a server and parse requests. For example, maybe you want to have an amazon bucket that handles all requests to /torrent/ but you want to support ipfs by serving it from a local gateway, in that case you can just create some middleware that routes/ipfs/ requests to somewhere else.

We can add an optional hash_kind key with values like any, torrent, ipfs, etc. to default hosts that a user can specify with a kind 0 event. That way a user will be able to specify different default hosts for different hash kinds.

• If a hash_kind is not specified, then a client will assume that a default host serves media files of any kind.

• In most cases, clients will set a hash_kind to any, so UX won't degrade. However, advanced users will be able to manually set hash_kind for each endpoint/host.

Examples:

{
    relays: [
        { url: <wss://whatever>, read: true, write: true },
        { url: <wss://whatever>, read: true, write: true },
        ...
    ],
    hosts_publisher: [
            { url: <media.domain.com>, timestamp: <integer>, hash_kind: <string> },
            { url: <media.domain.org>, timestamp: <integer>, hash_kind: <string> },
        ...
    ],
    hosts_viewer: [
            { url: <media.domain.com>, timestamp: <integer>, hash_kind: <string> },
            { url: <media.domain.org>, timestamp: <integer>, hash_kind: <string> },
        ...
    ]
}

Thoughts?

[lovvtide]

Might be a bit of an over-optimization at this point but I don't see why it would hurt

[ghost]

Hi all, please see this: github/bittorrent/btc