Introducing IPAccount Namespace Storage and IViewModule for Enhanced Metadata Display

[kingster-will]

This PR introduces significant enhancements to the StoryProtocol, focusing on the IPAccount Namespace Storage and the introduction of a new module type, IViewModule, aimed at offering flexibility in displaying metadata. Additionally, it incorporates a fully permissionless registration function for IPAssets. The key highlights and changes are as follows:

IPAccount Namespace Storage

The implementation of IPAccount Namespace Storage is realized through the IPAccountStorage contract, which adheres to the IIPAccountStorage interface. This development facilitates structured and conflict-free data storage for IPAccounts by employing a namespaced storage pattern. The default namespace is determined by the msg.sender, ensuring that only the owning Module can write data into its respective namespace, while read operations remain unrestricted across namespaces.

IViewModule Introduction

A new module type, IViewModule, has been introduced to enhance the flexibility in displaying metadata. This module type allows for a more dynamic and customizable presentation of IPAssets, catering to the diverse needs of different applications and user interfaces.

Test Coverage

The newly added code, including the IPAccount Namespace Storage and the register function, has achieved 100% test code coverage, ensuring reliability and robustness.

This PR represents a pivotal step forward in the StoryProtocol's development, introducing advanced features that enhance functionality, flexibility, and accessibility.

[Ramarti]

Currently no module integrates with this AFAIK. What is the purpose of this contract, for community created modules to store data in the IPAccount? What is the advantage of doing that vs keeping their own state?

[LeoHChen]

one thing we discussed before is to just support string or base64 encoding, using KV pair, no need to support different type.

[LeoHChen]

Or use just one function to set, one to get;

ex,

setData(namespace, type, value)
getData(namespace, type, value)

[kingster-will]

Agreed.
Simplified multiple setters/getters to unified set/getBytes()
Also, retain set/getbytes32() for the gas efficiency when storing simple types like bool

[kingster-will]

Currently no module integrates with this AFAIK. What is the purpose of this contract, for community created modules to store data in the IPAccount? What is the advantage of doing that vs keeping their own state?

The primary objective is to establish an Open Programmable IP platform by offering a standardized method for Open data access and sharing across modules. This approach is detailed in the following document: Open Data Access Architecture: Embracing Programmable IP. While current modules do not yet integrate with this change, plans are in place to refactor them to integrate with the IPAccount namespace storage.