Raster (raster.art) find support: follow-ups after 1.6.0 — Raster media-type ask, partial-index drops, fallback-vs-primary

[moskovich]

Status

The core fix shipped in 1.6.0 (PR #76): ff-cli find now resolves raster.art/artwork/{slug} URLs and builds Raster-minted series into signable, verifiable DP-1 playlists without --skip-verify, bypassing the FF indexer when it can't carry the tokens. This issue tracks the remaining follow-ups that were intentionally left out of that change.

Background

Reported by Lucian while driving an Art Computer via the claw: a Raster URL wasn't recognized and the raw coordinate stalled at the FF indexer, forcing a manual scrape + one-item DP-1 + play --skip-verify workaround. Root causes and the implemented fix are in PR #76. What shipped:

• raster.art/artwork/{slug} URL parser → resolve via Raster artworkBySlug.
• Per-token media.contentUrl + media-type hint carried from token enumeration.
• FF-indexer bypass: build DP-1 items directly from Raster media (off-chain provenance) when the indexer returns nothing; indexer tried first so it keeps on-chain provenance where it works.
• Media-type hint (contentType || previewType) threaded into buildUrlItem so extensionless IPFS videos get correct DP-1 timing instead of playing as stills.

Follow-up 1 — Ask Raster for proper media type metadata

The timing fix leans on Raster's non-standard previewType enum because media.contentType is empty. Sampling several artworks: contentType is "" on every one, contentUrl is an extensionless IPFS gateway URL, and previewType is a <class>/<n> code (video/2, gif/3, image/2). Asks, priority order:

1. Populate media.contentType with a real IANA MIME (video/mp4, image/gif, text/html) — lets every consumer drop the previewType workaround.
2. Document/confirm the previewType enum — class-prefix set (video/audio/image/gif/html/…) and that it's stable, since we infer from it.
3. Serve a correct Content-Type header on contentUrl (and/or extensioned URLs) — backstop to refactor(nft-indexer): migrate to ff-indexer-v2 API with CAIP-2 format #1.
4. Confirm x-api-key (RASTER_API_KEY) enforcement plans — docs say required; endpoint currently answers without one. Provision before it flips.
5. Canonical media URL — contentUrl points at a third-party IPFS gateway (ipfs.verse.works); for wall playback, is there a pinned/CDN-backed URL or recommended gateway?

(An email draft for this is being sent separately.)

Follow-up 2 — Partial-index drops

The FF-indexer bypass triggers only when the indexer returns zero items. If it returns some tokens but drops the Raster-only ones, those are still silently dropped (matches pre-existing behavior — not a regression). A per-token bypass, or the "Raster-first" shape below, would close this.

Follow-up 3 — Decide: Raster as fallback vs. primary

Today Raster media is a fallback behind the FF indexer (preserves richer on-chain provenance where the indexer works). If we want Raster as the primary path for Raster-resolved series, the cleaner shape is to reconstruct on-chain provenance from the coords we already hold rather than per-token correlation — but that's a real dependency bet on Raster's uptime/coverage and worth deciding deliberately.

Acceptance (for the follow-ups)

• Once Raster populates contentType, drop the previewType workaround in buildUrlItem's caller.
• Decide and document the fallback-vs-primary direction; only then tackle partial-index drops.

[feralfile-bot]

Daily Pulse moved this card to rank 27 with priority P2.

Reason: Follow-up work below current P1 live gaps.

[feralfile-bot]

Daily Pulse moved this card to rank 27 with priority P2.

Reason: P2 integration follow-up below current P1 map/protocol work.

[feralfile-bot]

Automated triage updated this issue's project priority from P2 to P3.

Reason: Raster core support already shipped, leaving narrower follow-up cleanup.