Optimize media file loading in IPFS

[anastasiabusygina]

• [x] use Bull as job queue
• [x] parse tweet details in tweetsQueue, populate another task queue with resource URLs
• [x] process resource URLs - download resources, upload them to IPFS, store CIDs
• [x] collect tweet component CIDs in metadata JSON files, upload them to IPFS
• [x] mark tweets as ready when everything related gets uploaded, make this known to the client

[anastasiabusygina]

• [ ] save all the data, including metadata directly to ipfs without storing it locally. Save large media files in the background (with a kind of worker or a job).
• [ ] still save data locally. no need to load it up to the ipfs forever, if someone changes their mind and doesn't send the transaction.
• [ ] If we upload a tweet-related media on the '/send/' request, no need to read any locally saved files, use content ids to fetch metadata from ipfs and create a metadata object required by NFTStorage. 3. The only media object to create at this moment is a watermarked image. It is required is we do not create a watermarked image at the preview stage before the user confirms submitMint transaction.

[poludnev]

Сейчас при получении от фронтенда реквеста POST /send c tweet id, puppeteer загружает страницу, делает скриншот и сохраняет в папку /data, данные твита и метаданные запроса обрабатываются таким же образом и сохраняются в папку /data. После подтверждения пользователем транзакции, из Chainlink узла в адаптер приходит реквест POST /adaper_response.json. Контроллер этого запроса

1. читает из папки /data по tweet id сохраненные в результате выполнения запроса /send файлы скриншота, данных твита и метаданных запроса.
2. формирует скриншот с вотермарком
3. из данных твита получает ссылки на медиафайлы: изображения, видео
4. сохраняет в nft-storage: скриншот, скриншот с вотермарком, медиафайлы.
5. получив cid загруженных файлов, формирует матадату для nft.
6. сохраняет в nft-storage метадату
7. получив cid метадаты формирует респонс в виде JSON:

   {
   "data": {
       "url": "<tweet id>",
       "sha256sum": "<хэшсумма строкового представления метадаты в BigInt>",
       "cid": "bafkreiey2x3hdvzdhd22nnltcpriax7gabqxo6eiivenjfbuvujtqcdkwi",
       "metadataCid": "bafkreihd3wyfzst55c3izqm5p5fboc3rnciradbr3h4ghg2inzo53zxvy4"
   }
   }

Проблема:

1. Дефолт-таймаут Chainlink узла составляет 15с. Да, его можно увеличить.
2. Но: если в медиафайлах твита есть большие изображения или видео, то их загрузка в ipfs может продлиться 2-3 минуты даже при условии, что мы сохраняем видеофайл в минимальном битрейте.
3. Нам так же необходимо хранить временные файлы в папке /data, а значит нужно контролировать их накопление и своевременное удаление.

Можем: Вариант 1. Сохранять все указанные файлы на стадии превью, по время обработки /send запроса:

• Сделанный в puppeteer скриншот отправляем на фронтенд для превью в одном респонсе с матадатой и данными твита:

  {
  "screenshotUrl" "base64:...",
  "metadata": {"...."},
  "tweetData": {"..."},
  }

  • Запрашиваем медиафайлы из твита: изображения, видео и т.д., генерируем их cid
  • Сохраняем cid в JSON файл в папке /data по tweetId (да, опять сохраняем что-то локально, но JSON весить значительно меньше изображений)
  • Фоном загружаем скриншоты и медиафайлы в ipfs после отправки респонса с превью на фронт.

• К моменту прихода на адаптер реквеста POST /adapter_response.json, медиафайл либо уже загрузятся, либо уже загрузится некоторая их часть, но у контроллера уже будут готовы записанные ранее cid.
• Контроллер прочитает cid из записанного в /data JSON-файла по tweet id, формирует метадату для NFT-storage и отправляет респонс.
• При этом контроллер может так же для страховки получить медиафайлы по ссылками из данных твита, чтобы снова сформировать cid и проверить, не изменился ли контент.

Преимущества:

• экономим время на обработку и сохранение медиафайлов твита, не нужно делать большой таймаут и заставлять пользователя ждать.

Недостаток:

• файлы в ipfs загружаются до транзакции пользователя. Пользователь может передумать и расхотеть делать скриншот, но файлы всё равно загрузятся.

Вариант 2: продолжаем сохранять скриншот, мету и данные твита в /data, cid медиафайлов получаем в контроллере /adapter_response.json, их загрузку в ipfs делаем фоновой. В таком случае, их доступность не будет гарантированной при просмотре пользователем результатов сминтенного nft.

[Elizavetta]

Let's select the first variant, so that we can sepearte loading of big number of files

[utgarda]

https://github.com/OptimalBits/bull/issues/1411