As a general comment, I wonder if we want to call it something more specific than "DataDog"? "DataDog Malicious Packages DataSet" is unwieldy, but I'm concerned that there might be some future thing that pulls from DataDog proper and the name is already taken. I don't have any great ideas and this may not be a concern worth worrying about right now, but I wanted to raise it.

As a general comment, I wonder if we want to call it something more specific than "DataDog"? "DataDog Malicious Packages DataSet" is unwieldy, but I'm concerned that there might be some future thing that pulls from DataDog proper and the name is already taken. I don't have any great ideas and this may not be a concern worth worrying about right now, but I wanted to raise it.

yeah, that is a solid point, if DataDog eventually spin out other datasets, I can see how that might cause some confusion. The data itself mostly comes fromGuardDog but I think not exclusively. Maybe we can go with something likedatadog-malware-dataset ordatadog-mspd but mspd is not a known acronym. The alternative isdatadog-malicious-software-packages-dataset but like you said that is a bit unwieldy.
Thedatadog-malware-dataset one sounds like the best compromise to me between clarity and brevity.

Thanks@robert-cronin! Sorry for the delay. We will review this soon!

Thanks@robert-cronin! Sorry for the delay. We will review this soon!

No problems, thanks@pxp928!

This is a super cool addition. I wasn't aware of this dataset but this was a really cool implementation and its such a good example on how to add another data source easily (or at least you made it look easy! - any feedback on how to make this easier would be super great as well, or any particular frictions you had). Thanks so much for yet another great contribution! 🙌

Thanks@lumjjb ! I really appreciate your encouraging words 😃 In terms of frictions, I think there are some options for improving the scalability of adding new data sources be they collectors or certifiers. Perhaps one idea is to define a common interface that any collector or certifier must implement and then have a registrar similar to how the backend works today in the spirit of dedpulication. There are also some common logic items in the certifiers/collectors like initialising nats/calling ingestion flow/ emitters etc. Not sure how much of that will be changing in v2.0 but it might be worth looking into

Hello@lumjjb! Your suggestions have been implemented and all outstanding changes addressed. If you have any other suggestions, let me know.