Discussion: Standardizing Request Data Format EIP-3722

[benjaminshafii]

Wondering if anyone has thought about supporting initiatives such as EIP-3722.

EIP-3722 was originally developed as a proposal to create a basis for social media contracts, but it shares some similarities with RequestHashStorage.sol

Pros

• Increase interoperability possibilities for request invoices
• Be part of an initiative promoting a more open financial system
• Simplify open-source contribution by building on top of a common standard

Cons

• It's a bit of a "misuse" of EIP-3722 since invoicing was not defined as a base use case
• Opportunity cost -> fewer resources on core features (more a long-term play)

[yomarion]

If I understand well, this would +/- work if we stored the data on-chain instead of on IPFS, correct? I am not really sure how it increases interoperability with off-chain data.

[benjaminshafii]

They use the same underlying technology -> Smart Contract on L2s using IPFS hash inside of Events.

And they face the same problem:

How can you create a truly interop layer on top of a very generic base layer.

The way Request solves this is by defining data format

EIP-3722 does not solve that problem. In the proposal, they define a sample format for a twitter-like platform.

I bring it up here because I've spoken to multiple projects that use similar underlying technology and, each time define their own standard on top (e.g. data format).

An interesting next step wouldn't be so much to implement EIP-3722 but could be to talk with existing implementers to maybe define another EIP to define things like:

• a repository of open format on Ethereum (where Request data format could be listed)
• common ways to validate data

Again, I think this is a big initiative and might not be the best use of immediate resources...

[yomarion]

Oh I see, thanks a lot for bringing that up and for the explanations! Indeed a big one but interesting.

[bertux]

thank you @hotkartoffel to have started this discussion. It seems to me Lens Protocol and Lenster are trying to create a basis for social media contracts. During some hackathons I'm interested to try using the Request data format in the metadata of a NFT tokenizing every Request object to see if it could fit on-chain on L2s or inexpensive side-chains. But at least the IPFS hash could be used in the metadata of an NFT to avoid filling every data on-chain. So only the generic data would be in metadata and it could be extended on IPFS by adding an IPFS hash when more information is needed. From what I see Ceramic Network is "a decentralized network for building applications with composable data on Web3" which could be helpful. For example running a Ceramic node is documented at https://docs.filebase.com/knowledge-base/web3-tutorials/ceramic/ceramic-how-to-host-a-ceramic-node-using-decentralized-storage

[MantisClone]

Closing as unplanned because the underlying EIP-3722 is stagnant.