jollyjoker992

StarQuest Technical Proposal

Purpose: This document helps you (the artist/developer) implement the HTML/JS artwork so it can be embedded on Feral File and other DP‑1 compatible displays. It defines how query parameters are used, how clips are resolved from IPFS/FF CDN, and how to call the on‑chain contract function seriesArtworksOfOwner(uint256).

---

1. General Requirements

1.1 Query Parameters

jollyjoker992

Orbit-2 Curation: Registry + Feed (Worker) • Final Technical Design v1.0

Purpose: Define a complete, copy-ready architecture for Orbit-2’s endorsement (star) flow, bridging the Registry (trust ledger) and Feed (discovery) layers. Integrates webhook delivery, backfill sync, and Cloudflare materialization.

---

0) High-Level Architecture

TBD

jollyjoker992

Token Indexer — Acceptance Criteria (Orbit-2)

0) Scope & Non-Goals

In Scope (MVP):

• Light version of ff-indexer supporting Ethereum (ERC-721/1155) and Tezos (FA2).
• Derive token ownership and provenance exclusively from on-chain data.
• Use 3rd-party APIs (OpenSea, Objkt, ArtBlocks, etc.) only for metadata enrichment, never for ownership or provenance.
• Parse token metadata from on-chain URIs following:

jollyjoker992

DP-1 Feed — Deployment & Migration Notes

Scope: quick reference describing the current Cloudflare-based deployment and a practical path to self‑hosting.

1) Current Deployment Structure (Cloudflare)

Runtime & App

• Cloudflare Workers running the Hono-based API (TypeScript)
• Middleware stack: error handling, request logging, CORS, content-type validation, bearer‑token auth

jollyjoker992

Feral File — Unified Authentication Proposal

Version 3 · 2025‑07‑14 – for team review

Goal: One crypto primitive (Ed25519) for everything (JWT, playlist signatures), while letting wallets (EVM secp256k1, Tezos ed25519/P‑256) and classic passkeys (P‑256) coexist. Resource services must verify tokens offline; only Auth‑Server mints them.

---

1 · Identity anchors

jollyjoker992

Feral File · Unified Trust & Playlist‑Signing Flow

(Push‑to‑Mobile Ed25519 model, iOS 16 baseline)

---

1 · Purpose

Enable all mobile users who already authenticate with a passkey to sign any “playlist JSON” (or other DP‑1 content) with a 64‑byte Ed25519 signature — even when the action is triggered from the web UI — while keeping DP‑1’s “Ed25519‑only for human signatures” rule intact.

jollyjoker992

Proposal — Minting an Interactive Software Artwork on Ethereum

Prepared for John Provencher

---

1. Artwork Contents

File	Un‑minified size	Role	Notes

jollyjoker992

Feral File Artwork Library

tags: Feral File operation

Feral File Variables

For Feral File generative artworks, it injects pre-defined variables then the collector click to view the software artwork in in frame. This helps artists be able to make variants to their artworks. The variables are:

• blockchain - (bitmark | ethereum | tezos)
• contract - contract address if any. empty for bitmark

jollyjoker992

Problem Statement

• Artist Requirement: Artist wants to store their custom, unminified JS file (~40 KB) on-chain with ERC‑721 tokens, while keeping the rest of the front-end assets (HTML, CSS, other JS, media) off-chain (e.g., IPFS).
• Current Architecture: Each artwork series and its member tokens are managed by an ERC‑721 contract. Token metadata includes all source code and asset references.
• Limitation: The existing smart contract does not support arbitrary on-chain data storage beyond standard metadata fields, so embedding a 40 KB JS file directly on-chain is not currently possible without contract changes.

Proposed Solution

1. Series Data Mapping

jollyjoker992

#include <jni.h>
#include <cstdlib>
#include <cstring>
#include <cassert>
#include <cstdint>
#include <iostream>
#include <set>
#include <vector>
#include "../../../deps/bc-ur/src/bc-ur.hpp"