Proposal: store-my-text example app

[rvagg]

@ZenGround0 gifted this idea, but I really like it as an example app because of the simplicity of the frontend which gets rid some of the complexity of a typical example app (no need for frontend frameworks!). The UI is primarily email-driven, which also lends itself to complexities of background deal-making for small resources.

The path from this example app to a genuinely useful application is pretty clear too - if we nail the basics, it could turn into a full NFT-storage application without much effort.

[rvagg]

I need to add a disclaimer in here that the actual path to storing data in Filecoin isn't necessarily to take that all on directly, but it could involve third-party tools, like Powergate and even ThreadDB. I think my preferred approach is to aim for direct so we can get into the problem space and do some learning, but maybe we end up bailing because of all of the complexities of miner-selection, deal-making, etc. But it would be good to explore it as a learning experience I think.

[yusefnapora]

This sounds like a great example 👍

The UI is primarily email-driven

I could see "email to filecoin" becoming a useful product in its own right someday - the async nature of the deal flow is a really good fit for email status updates, and it could be a useful way to permanently archive conversations by forwarding them.

[ghost]

@rvagg

because of all of the complexities of miner-selection, deal-making, etc

I run a PL miner that you can use if all else fails, and I think I can help advise on deal-making as I have a lot of experience now going through the deal->store->retrieve workflow. Keep me looped in and I'll keep some notes on what things were hard to figure out or get working; that'll be good learning for the project in addition to good learning for the team.

[ghost]

1. Team learning is legitimate and necessary; it contributes to PMF because we have to understand the developer journey (esp for new devs) before we can improve it.

2. Product (me) can learn and use those findings to better identify the top problems facing new developers.

[ghost]

This one is important to do (does not have to be in rev 0). It's going to reveal a whole other set of blockchain pain points that developers will face, and we should face them too, to see how we can improve.

[dineshshenoy]

I like the flow! One tactical consideration is the acceptance criteria.

I would imagine that the initial version would be built on testnet/nerpa net/caliabration net which has different characteristics than mainnet.

This issue talks about some of the hiccups storing small data sizes on mainnet with sector sizes of 32+ GB.

[rvagg]

@dineshshenoy yeah, deal size is one of the big things that concern me about this, but I'm pretty keen for us to create an app that hits that hurdle so we can understand the shape of it. I'm fine with batching data prior to deal making - and the async user process lends itself to that - batching seems like a necessary feature of an app that builds on Filecoin and we have the IPLD skills to solve that elegantly. But if we have to batch simple text input until we get into the Gb range then, yeah, that's going to be a problem. Perhaps it simply means putting a pause on this project when we hit a show-stopper that we can't solve in reasonable time (and with reasonable example code) and move elsewhere while the underlying problems are addressed.
And to be clear - retrieval isn't part of this initial scope, that's recognised as a separate thing to tackle but would be a great extension to this to make a complete system.

[dineshshenoy]

Agreed - worth pursuing regardless. Just wanted you to be aware of the roadblock (and try to hit it) since you may not hit it on nerpa net.

[mikeal]

The ICE info is incomplete in the proposal. I doubt we’ll be able to 👍👎 without it.