Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support fetching playback URL for asset imported from dStorage gateway using dStorage ID #1362

Closed
yondonfu opened this issue Oct 24, 2022 · 0 comments · Fixed by #1370
Closed
Assignees

Comments

@yondonfu
Copy link
Member

yondonfu commented Oct 24, 2022

What's the problem? (required) Describe the problem or need in exactly 1
sentence. Ex. "I'm unable to [...]", or "I am confused by [...]"

A user cannot import an asset from a dStorage gateway and then use the dStorage ID [1] to lookup the playback URL using the /playback API.

This problem prevents a user with existing videos pinned in a IPFS gateway to continue using the same CIDs to lookup Studio playback URLs.

[1] dStorage ID refers to the identifier for the asset in the dStorage gateway. For IPFS gateways, the dStorage ID is the asset ID. For Arweave gateways, the dStorage ID is the tx ID.

What's the current behavior? (required) A clear and concise description of
the current behavior of the DApp or package (or lack thereof).

At the moment, the /playback API will try to lookup the playback URL for a CID or playbackID. However, if the user imports an asset from a dStorage gateway, the dStorage ID (i.e. CID for IPFS gateway) cannot be used to lookup the playback URL for the asset because Studio is not aware of the dStorage ID of the asset. For IPFS, a user can export the asset in Studio to IPFS which will allow the user to use the CID of the exported asset for playback, but this CID can be different from the original CID from the IPFS gateway because the original gateway and the export gateway might use a different chunk size/algo which would result in different CIDs.

Describe a possible solution you've considered (optional) A clear and
concise description of what you want to happen.

Option 1

Add an import field to the asset entity:

import: {
    url: ... // URL that asset was imported from
    type: "ipfs", // ipfs, arweave, null if unknown dStorage provider
    id: ... // cid for IPFS, tx ID for Arweave, null if unknown dStorage provider
}

When handling an upload with URL (aka import), check if the URL is for a known dStorage provider (i.e. IPFS gateway, Arweave gateway) and populate the import fields accordingly for the asset.

Update the playback URL lookup logic to check the import field for the ID that is provided.

Option 2

When handling an upload with URL (aka import), check if the URL is for a known dStorage provider (i.e. IPFS gateway, Arweave gateway) and populate the the tags object (this is the naming as of this PR) with something like:

{
    "ipfs": {
        "id": ...
    },
    "arweave": {
        "id": ...
    }
}

The "ipfs" field would be used if the URL is an IPFS gateway. The "arweave" field would be used if the URL is an Arweave gateway.

Update the playback URL lookup logic to check the tags object for the ID provided.

At the moment, I think option 1 would be preferable because:

  1. Avoids over-loading usage of the tags field which I believe is meant for user specified tags
  2. Tracking the import information of an asset seems generally useful (where did this asset come from - import or direct upload?)
  3. It would be easier to add an index to the import fields to speed up lookups if needed

The solution for this issue should work for both assets imported from IPFS and Arweave gateways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant