Hieu Pham (Hiếu Phạm) 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

Series Data Mapping

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

Proposal — Minting an Interactive Software Artwork on Ethereum

Prepared for John Provencher

1. Artwork Contents

File	Un‑minified size	Role	Notes

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.

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

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

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:

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

	#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"