FIP (Idea): Derivable cast metadata

[1a35e1]

Title: Derivable cast metadata (working title)
Type: Standards FIP

Author: @1a35e1

TL;DR

• Hash well known data in a way that makes it easy to index and retrieve.
• Does not interfere with channel spec
• Enables Give me all cast's that contain media X

Background

Casts, for the most part — are unstructured.

However there is a case to be made that communities who leverage casts to surface real world media, are contributing additional value to the public data of the network.

Example channels:

• https://warpcast.com/~/channel/cinema-stills (soft shill ;0)
• https://warpcast.com/~/channel/techno
• https://warpcast.com/~/channel/books

These channels (and many more) are good candidates where users take the time to make meaningful recommendations and would probably go the extra mile to add additional metadata to the cast. (If there was an incentive attached?)

Why?

• Casts that MATCH the same content create graphs that can then be further used to promote recommendations and unlock new modes of discovery.

This in my opinion:

• Adds scope for an incentive/monetisation experiment.
• Creates the potential for channels to finally realise the literature surrounding "Token Curated Registries"

After digging though:

• FIP-16: Longer Casts, - FIP-16: Longer Casts #182
• FIP: External cast data, - FIP: External cast data #171 — via @stephancill
• FIP: (convention) Cast metadata storage, FIP: (convention) Cast metadata storage #136 - via @prego

I do not believe they fit the needs to make a Token Curated Registries a reality and this prop may potentially be a necessary precursor to decentralising channels.

Please direct me to more relevant discussions if I have overlooked particular discussions.

Things to flesh out

[ ] How to add metadata to a cast?
[ ] Explore derivation schemes
[ ] How best to index the data
[ ] Secondary markets to guarantee authenticity of the data

Propose new message types?

Can existing casts be incentivised to have the "correct" metadata applied? and penalised when acting badly?

enum MessageType {
  MESSAGE_TYPE_CAST_METADATA_ADD = 13
  MESSAGE_TYPE_CAST_METADATA_REMOVE = 14
}

Explore derivation schemes

The goal here is, IF I know SOME identifier (ISBN, DOI) etc it should yield a hash that is append-able to a cast.

Potential tailwinds

• Custom cast clients optimised for curation
• Users will need an easy way to add metatdata.
• Hey! Client diversity?

UUID v5

UUIDv5 (Universally Unique Identifier version 5) generates unique identifiers based on a namespace and a specific name using SHA-1 hashing. This is useful for generating consistent UUIDs for the same input data.

Examples

const { v5: uuidv5 } = require('uuid');

// Predefined namespaces for movies, books, and songs
const MOVIES_NAMESPACE = 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11';
const BOOKS_NAMESPACE = 'b0eebc99-9c0b-4ef8-bb6d-6bb9bd380a12';
const SONGS_NAMESPACE = 'c0eebc99-9c0b-4ef8-bb6d-6bb9bd380a13';

// Example data
const movieTitle = 'Inception';
const bookTitle = '1984';
const songTitle = 'Bohemian Rhapsody';

// Generate UUIDv5 for each example
const movieUUID = uuidv5(movieTitle, MOVIES_NAMESPACE);
const bookUUID = uuidv5(bookTitle, BOOKS_NAMESPACE);
const songUUID = uuidv5(songTitle, SONGS_NAMESPACE);

console.log(`UUID for movie "${movieTitle}": ${movieUUID}`);
console.log(`UUID for book "${bookTitle}": ${bookUUID}`);
console.log(`UUID for song "${songTitle}": ${songUUID}`);

Key Points

• Consistency: The same name within the same namespace always generates the same UUID.
• Uniqueness: Different names or different namespaces produce different UUIDs.
• Hashing: Uses SHA-1 hash to generate the UUID, ensuring uniqueness without needing a central authority.

Inspiration, ERC-1967: Proxy Storage Slots

https://eips.ethereum.org/EIPS/eip-1967

• Traversing upgradeable contracts are a PIA
• Leveraging a storage slot is a brilliant way to perform a read to get the current implementation contract.

TL;DR

FYI: This is AI pseudocode

const { utils } = require("viem");

// => How many times has this contact been upgraded? Who cares? We just want the current implementation.
async function getImplementationAddress(provider, proxyAddress) {
    // Define the slot as per ERC-1967
    const IMPLEMENTATION_SLOT = utils.keccak256(
        utils.toUtf8Bytes("eip1967.proxy.implementation")
    );
    const implementationSlot = utils.BigNumber.from(IMPLEMENTATION_SLOT).sub(1).toHexString();
    // Read storage at the implementation slot
    const implementationHex = await provider.getStorageAt(proxyAddress, implementationSlot);

    // Convert to address
    const implementationAddress = utils.getAddress(implementationHex);
    return implementationAddress;
}

Impact

Structured data is the basis for Knowledge Graphs. This is a much larger topic but, hopefully this should be sufficient to prompt some discussion.

I came up with this idea building https://lighthouse.cx/, as I wanted a way to anchor and aggregate content from disparate sources.

This was further informed from previous experience deep diving into the key design of DynamoDB.

• Video, DynamoDB Deep Dive
• Amazon’s Highly Available Key-value Store

If implemented correctly; We can aggregate content from disparate sources across multiple domains and ecosystems.

[1a35e1]

Apologies if the idea is too rough.

Please let me know points that need clarification and I shall update accordingly.

[1a35e1]

"would be useful to understand how the external cast metadata doesn't suit your needs"

With permission from DC with stephancill

External cast data relies heavily on additional lookups and parsing.

So my current hesitation is that having to traverse an additional arbitrary data schema makes the retrieval complexity O(n) instead of O(1).

[varunsrin]

Thanks for fleshing this out - this is a cool idea, but we are always hesitant to add new features unless we're sure they will be used. Otherwise the protocol will just collect a lot of tech debt and become hard to use and maintain.

Could this be prototyped without a protocol change? If it gets traction and we understand a use case then we'd be more open to implementing it.

[1a35e1]

Hey @varunsrin sorry for the late reply. When I wrote this I was in the zone and just wanted to get the idea out there.

I have since spoken to a couple of people about it who have been following the protocol discussions more closely so I totally understand the downstream impact of adding experimental features to the core protocol.

Tagging @bpetes, @vleipnik, @vkuts and @jukeboxhero123 (with permission) who have been experimenting with an "L2" on top of the core protocol who may have a pathway forward.

That said is does raise the question of how FC — more broadly, can iterate quickly on the protocol level. Would having experimental flags be an option? That way production hubs can just discard "experimental" properties.

[varunsrin]

I generally think experimenting at the app layer makes the most sense.

If you can build a prototype app or get a feature into an existing app you can gauge whether people want it and if any changes to the design need to be made.

[1a35e1]

Will keep that in mind and update when relevant. TY.