Forest 馃尣 Roadmap Discussion [Public] #2172
Replies: 4 comments 18 replies
-
FIL wallets/account management should be a separate, stand-alone binary and not by default part of the full-node client. ref #1517 |
Beta Was this translation helpful? Give feedback.
-
|
Why separate the FIL wallet handing? This can be one of the main features. If you can't even store, manage, send, receive FIL there won't be much of a value proposition for the Forest client aka no incentive to run it at all just to maintain consensus with the network. Unless, we are trying to keep the Forest core super light weight? Then have FIL wallet handing or any other feature as an add on. |
Beta Was this translation helpful? Give feedback.
-
|
Having account management in nodes is the (arguably) number one pain point. Here's some context: ethereum/go-ethereum#25948 Geth created an external signer (Clef) and we should have that straight from the beginning: https://geth.ethereum.org/docs/interface/managing-your-accounts I'm not saying we shouldn't have a wallet. I'm just trying to make sure it's not part of the forest node. It should be a separate binary:
Binary names are just exemplary. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, yes ok. I understand what you mean now. @lemmih thoughts on the above? |
Beta Was this translation helpful? Give feedback.
-
Would love to see someone building a FIL explorer MVP using Forest. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
It's not about differentiation, it's more about proving we are offering feature-complete services. A simple html-explorer fetching data from a forest node would be a lovely showcase. |
Beta Was this translation helpful? Give feedback.
-
|
Ya ok, I see. More like a demonstration of a use case from Forest API. |
Beta Was this translation helpful? Give feedback.
-
I would propose 6-weekly releases along with the Rust compiler, it would not require a dedicated process yet but having a tag every other month would be good. |
Beta Was this translation helpful? Give feedback.
-
|
@LesnyRumcajs What is the current automated coverage? Perhaps we can establish a plan to include a QA phase before every release? |
Beta Was this translation helpful? Give feedback.
-
|
@lerajk It's 34% for the unit tests, and it would go higher if we included the sync checks (they aren't 100% exhaustive, though; they check a few tipsets). What we are missing the most is coverage for RPC commands, combinations of various flags and node stability. Currently, we would know that a PR increases memory usage only if Forest starts crashing. So yeah, we could contrive a test plan to go through before each release. Again, no blockers, we only need to prioritize it and make it happen. There's also a positive aspect of having to do manual tests if they're not too cumbersome - every Forest dev would know by heart Forest commands and flags. Provided there's not a single person doing those checks every time, but we do it on a rotation basis. |
Beta Was this translation helpful? Give feedback.
-
|
@q9f is there a possibly to get help from ChainSafe QA team for the above for Forest? @LesnyRumcajs Let us create an issue for a test plan and coverage? Perhaps it is a good idea to stay away from manual tests, an automated plan is more manageable in the long run and we don't run into issues of knowledge gaps. |
Beta Was this translation helpful? Give feedback.
-
|
Coverage has always been a problem and I don't think the ChainSafe QA team will be much of a help here. I would rather encourage you to do it similar to the Lodestar team and hire a "Software Engineer in Testing." Let them start writing unit tests for literally everything and slowly work their way up to integration tests and eventually more complex end-to-end simulations. Also, manual testing is not necessarily a bad thing. Sometimes you have the most involved test-suite and at the end of the release realize you cannot "double click" your executable. I'd be happy to assist for a few release cycles. |
Beta Was this translation helpful? Give feedback.
-
|
Yes ok, will discuss and think about hiring a Software Engineer in Testing with the team. Test coverage will be a crucial criteria for a mainnet production node. |
Beta Was this translation helpful? Give feedback.
-
|
This is related to releases a bit. What we are missing is a stable node. At the moment, we don't have one - only some sync checks, which are working quite well, but they are not simulating a production node. If we want Forest to have a meaningful place in the network (also related to Network Statistics Milestone), we should provide at least one "real" node, constantly up. This would bring some benefits:
The node setup and maintenance should be as easy as in Saturn L1 https://github.com/filecoin-saturn/L1-node#set-up-a-node. The cost of this is a VPS on Digital Ocean, roughly $100 per month unless it turns out we need a beefier machine (which would be a remarkable finding; currently, we can't recommend anything objectively). Ultimately, this single node should bootstrap Forest into a healthy production stage. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, let's do this - run a permanent node in Digital Ocean. What blockers do we have now to execute the 猬嗭笍 |
Beta Was this translation helpful? Give feedback.
-
|
No blockers, only scoping and prioritizing it. And then putting someone to work on it. |
Beta Was this translation helpful? Give feedback.
-
|
@q9f can we get help from ChainSafe devops to run a Forest 馃尣 node on an ongoing basis for the above? @LesnyRumcajs gonna create an issue for this as well. |
Beta Was this translation helpful? Give feedback.
-
|
We are currently hiring for this, yes. (Blockchain Operations). |
Beta Was this translation helpful? Give feedback.
-
Discuss anything related to Forest 馃尣 roadmap
Beta Was this translation helpful? Give feedback.
All reactions