Project design documentations and future plans

[TheResplandor]

In order to make contributions more effective, I would like some clarification about the project's design and end goal.

Design

Is there a design doc or guideline? Any plans on making one?

There isnt too much code currently, but it seems like every backend implements its own interface completely independent of the others - is this planned or just happened on the go?
A completely free interface per backend will make it hard to create multi backend commands, such as "retrieve all samples from the last 48 hours".

Instinctively I would go for a more classic approach - Have an abstract backend class, each backend implements it, and when the cli runs it dynamically loads the backends like plugins. This leaves room for capabilities like filtering backends, running on all backends and easily adding custom backends/other kinds of plugins.
Though I am no architect and this approach may not fit this kind of project.

Future plans

1. Is the end goal for this project to be a cli tool for making it easier to automate malware samples retrieval?
2. Are there any different kinds of capabilities planned for the future other than just taking samples from other sources? I saw talks about creating our own samples with honeypots of some kind - wouldnt it be better to have that as a separate project, with daily-dose treating that as just another backend?

[rothoma2]

A few Clarifications.

We dont currently have a design doc for this Tool Specifically but I will try to clarify the End Goal of this Tool, and the Scope.
Perhaps in the future we can document better the scope for this one.

Problem Trying to Solve
Aggregator tool, for multiple Malware Threat Feed that provide Fresh Sample. This is a CLI tool that intends to have a comprehensive set of Malware Samples , to allow Simple, batch scheduled collection of Malware Samples.

Malware samples are required for multiple use cases such as the following

• Malware Analyst Training and Education.
• Model Development and Training.
• Model Evaluation and Retraining.

Context

This tool was developed by two previous members that are not so active anymore.
I agree this tool could use a Abstract Backend and Plugin Architecture.

We could gradually refactor it to move into a modular Plugin Architecture.