Permacast V3 Master Contract

[charmful0x]

About

This issue is about the new features, limits, and functionalities introduced in the third version of Permacast's Master contract.

New limits

These are the new limits (mostly string length extreme)

Podcast Metadata

metadata	min length	max length	notes/fixes
podcast name	2	500	added flexibility ~ 77 - 100 words
podcast description	10	15000	added flexibility ~ 2308 - 3000 words
email	0	320	none
author name	2	150	added flexibility
categories	1	300	added support for length equal to 1 (e.g. in Chinese)
language code	2	2	none

Episode Metadata

metadata	min length	max length	notes/fixes
episode name	3	500	added flexibility ~ 77 - 100 words
episode description	1	5000	added flexibility ~ 769 - 1000 words

Features

Reduce the signatures required to edit a podcast/episode

All of the podcast/episode object's metadata (name, description, etc.) can be updated by invoking a single function updatePodcastMetadata and updateEpisodeMetadata.

Factory Super Admins

The Factory Super Admins have the permission to create a podcast or an episode and update their metadata. They are added as super admins via the contract owner, and they can remove themselves from this position or be removed by the contract owner.

Podcasts Maintainers

Podcast Maintainers have a lower set of permissions, they can only upload episodes and edit them. Maintainers are added and removed by the contract owner.

Reduce non-necessary required inputs to invoke with some functions

The confusing id & index don't longer exist, To update a podcast only the pid is required, and to add/update an episode, only the eid is required.

Auto-protection from duplicated uploads

When the caller sends more than a transaction to create a podcast (or an episode) with the same name property within 5 blocks, only one transaction (first one that get mined) will pass through. Thus, it reduces the double uploads mistake.

Configurable RSS metadata

Podcast's metadata used to generated RSS feeds are now mutable

Note

The limits and features listed previously are "init", and can be changed according to the future issue's discussion.

[SiyuSiyuYang]

1. 5000 might still be tight for podcast description - adding reference links or using bilingual really expands the shownote length; I looked into our past shownotes, and longer shownotes can go up to 15k characters, which might be a blocker if somebody wants to sync their existing RSS to permacast.
2. What is the difference between super admin and podcast maintainers?

[charmful0x]

Hello @SiyuSiyuYang and thanks for the feedback!

1- That's not a problem, we will adjust the max-limit
2- super admins are 1 level below the contract owner, they can create podcastsand upload episodes (and edit them). While the maintainers can only edit and upload episodes (they cannot create podcasts). This method facilitates a secure and decentralized solution for podcasting moderation.

[SiyuSiyuYang]

@charmful0x Thanks for the clarification - makes a ton of sense :) Looking forward to the update!!

[charmful0x]

PS:

Technical limitation:

Regarding the new limits, all the podcast/episode metadata are passed to the contract through the interaction transaction's tags. And knowing that the maximum Tags size limit per TX is 2048 bytes, hence that means with the current limits, any interaction beyond the Arweave network limitation will fail.

How to prevent it?

Usually, only the description argument of a podcast or an episode has a large number of characters, thus the contract can have a max-safe limit for the description to be taken as-is (string) : description's length lower or equal to 1000.

If the description's length is greater than 1000 characters, the TX fails. To bypass this Arweave network limitation, a description with a length greater than 1000 characters should be passed as Arweave TXID of a text/plain or text/markdown MIME-type. When the description value is exactly a 43 characters string (with no whitespace), the contract assumes that it's a description above the max-safe limit and treats it as a data TX containing the description content.

Logic flow

if (description.length > 1000) {
  throw new ContractError();
}

if (description.length === 43) {
  // 1- validate if it has the syntax of a valid Arweave TXID
  // 2- try to GET the TX object and decode the TX's data
  // 3- check the content-type if it's supported
  // 4- decode the TX's data and append it to the state
}

// if length < 1000, take it as-is
podcast.description = input.description;

[xylophonez]

According to Apple, they impose the following:

• Title (episode and/or show): 255 char
• Desc (episode and/or show): 4,000 char

If we can stick to this, I think we're all fine.

@charmful0x your point about passing this off to a txid is great and sounds necessary. However, since (i think) 2048 bytes is 2048 char, can we not allow some version of:

2048 - episode.title?

Either way, let's go with this model!

[charmful0x]

thanks, @xylophonez !!

The commit above introduces this feature and bypasses the Arweave network tagging bytes size limitation.

But instead of passing the episode/podcast description as a separated data TX, it should be seeded with the contract's interaction transaction, which reduces the required signatures (hence TXs) to interact with the smart contract.

• Pros: almost no limitation with the input's string
• Cons: cannot interact via SmartWeave CLI when podcast.desc or episode.desc is included in the interaction

This feature can also be used with the podcast/episode name (aka title) handling. WDYT?

[charmful0x]

Factories Oracle - Proposal

About

The Factories Oracle is smartweave contract operated by the Permacast team. The purpose of this contract is to serve as an oracle of metadata limitations for the deployed factories.

A factory owner has the freedom of choice to make his factory up-to-date with the Factories Oracle contract whenever he decides to.

Technical Logic Flow

Oracle's feed

The feed of metadata that can be read via the Factories Oracle consists of:

• podcast's name length limits
• podcast's description length limits
• podcast's author name length limits
• episode's name length limits
• episode's description length limits
• language's char code type (currently ISO 639-1:2002)

Reading the oracle and updating a factory

V3 state contract required changes:

Make the metadata limitations dynamic by declaring it in the factory's state instead of having it hardcoded in the factory's source code:

{
  "podcasts": [],
  "superAdmins": [],
  "maintainers": [],
  "v2SourceCode": "KrMNSCljeT0sox8bengHf0Z8dxyE0vCTLEAOtkdrfjM",
  "hasMigrated": false,
  "ownerSwapped": false,
  // requested stated modification 
  "limitations": { 
    "episode_name": {
      "min": 3,
      "max": 500
    },
    "podcast_name": {
      "min": 2,
      "max": 500
    }
     ...etc
  }
}

V3 contract source code required changes:

To make this possible, a new function fetchOracle is required to update the limitations in a V3 factory state. Invoking this new function is permissioned and requires superAdmins privileges.

if (input.function === "fetchOracle") {
  /**
   * @dev read the oracle's state and update
   * the limitations object of the factory (contract's state)
   *
   * @return state
   *
   **/
  await _isSuperAdmin(true, caller);

  const OracleAddress = "...TBD...";
  const oracleState = await SmartWeave.contracts.readContractState(
    OracleAddress
  );

  // overwrite the factory's limitations object
  state.limitations = oracleState.limitations;

  return { state };
}

Benefits

This feature makes the deployed factories dynamic with any possible new factories release (Master Contract new source code release) that depends on the factory's metadata limitations.