My head's clearly been stuck in the Publication contract for the last few days, since I've been implementing that.
There's a lot that I like about the Publication contract paradigm, but it's not derisked yet as a feature. Currently, the cost to register on Mirror with the Publication contract would be around $100 on Mainnet, which is a lot of money relative to some other options.
I can decrease the cost of this deployment by using a pattern whereby only the storage is deployed per user, and everything else delegates back to a single "implementation" contract. I will almost certainly do this! Uniswap does not do this for new token pairs, which makes it expensive to add new tokens.
But the feature isn't derisked yet; we need to start playing with it and seeing how it feels to use Mirror with a real Ethereum protocol behind it, rather than a database for storage. This will feel weird; some things won't be as fast, and then the suggestion by others could be to speed it up by caching on the backend. We can do that, but first it makes sense to lean into the web3 aspects of this feature and get people excited about all of the net-new economic actions that it enables.
In other news, we've been working on NFT integrations for the frontend. John Palmer, a designer in our network, wants to write a blog post and create an NFT from it. He also wants to try crowdsourcing the funding of this article/NFT. This is interesting. I proposed that we do it this way:
fund()that pulls a given amount of USDC from a user's account, and mints an equal number of tokens for that user.
This would mean that users are contributing USDC into the contract in exchange for fractional ownership of the NFT. Once the NFT has been sold, the total USDC will be greater than the number of outstanding tokens minted by the contract, and those who contributed will be able to withdraw their profits.
John and Denis seem quite excited about this idea. I think it's interesting in so far as it's a prototype for something that the Publication contract might be able to do in the future -- i.e. crowdfund something like an article, or an education course. If it weren't for that, I wouldn't want to consider this for a once-off event, since it'll likely take a considerable amount of effort to make sure that there isn't a security vulnerability in the contract (ah, DAO-hack anyone?)