Implement Lens publication helpers

[victorges]

https://www.notion.so/livepeer/Lens-Integration-e756c036e6c741de97d8e9ef1c351e84#55aa2bb006f543559aaeb5f50dd64612

• Can be implemented as a separate module in the SDK if it makes sense, like lens. It will need to interact closely with the other existing minter module anyway, since that’s the (highest level) one with the current logic to upload an asset, process it, export to IPFS etc
• Expand for a suggestion for the minimum set of functions to be provided by the SDK:
  • videonft.lens.newPublicationMetadata(...?): Minimal function that receives input based on all the fields described above, and an existing asset.
    • Returns the full publication metadata that should be sent on the [exportToIpfs function](https://livepeer.github.io/video-nft/classes/minter.Api.html#exportToIPFS) of the SDK. This means all fields but the fields that depend on the CID of the asset on IPFS, which can only be known during the export task (and should be filled by task-runner itself, given the templating task 4 above)
  • videonft.lens.publish(...?): Helper function similar to [createNft](https://livepeer.github.io/video-nft/classes/minter.FullMinter.html#createNft), which receives a raw file and performs the E2E flow for creating an NFT in the Lens publication format (calls the function above as well).
    • This can be used to get started quickly, but likely won’t be the one used in a final application since it can take a long time to do the whole process. A final application might prefer to call the functions individually instead and show some feedback to the user about the process.
    • An alternative is for this to have a callback to report progress and then it can be used on final applications also showing some feedback to the user.
  • videonft.lens.playbackUrl(publication): Takes an existing publication and returns the playback URL for the corresponding asset. This could have an order of preference like: playback URL from a playbackId if present, otherwise the video URL from the content or attributes, otherwise just use the animation_url or even the external_url.
  • videonft.lens.playerUrl(publication): Takes an existing publication and returns the URL for the embeddable player. Can have a similar fallback mechanism like the playbackUrl above, and return a lvpr.tv URL for the up-to-date and optimized experience. SDK consumers can use this to easily create an iframe with a player for a given publication.

Definitions of Done

1. Can build a Lens-based application with a single function call to do the full e2e creation of a lens publication (without thumbnails)
2. Can provide a thumbnail (image) if you want, but need to handle exporting it to IPFS yourself and only send an ipfs:// URL and MIME type to the SDK.
3. Can call lower-level functions to control the flow of creating the publication, providing some feedback to the user in the process.
4. Can easily take a Lens publication and determine if it is a video from Livepeer
5. Can easily take a Lens video publication and display a video player for the contents on it
6. Can query for the created publications using the Lens API
7. SDK interacts well with Lens SDK

Dependencies

• NFT metadata templating task-runner#33
• Use new /api/playback/{playbackId} API player#2

[yondonfu]

An alternative is for this to have a callback to report progress and then it can be used on final applications also showing some feedback to the user.

FWIW I think it makes sense not to include a callback in this iteration and instead encourage (in docs) devs to use the individual SDK functions for each step of the flow - IMO that would be more straightforward from a programming POV than having to deal with callbacks.

[yondonfu]

A note on the publish method:

I think we'll need to decide between two options:

• Executing the create post typed data workflow inside publish
• Providing a code example of how to incorporate the video publication metadata from the SDK into the caller's own create post typed data workflow