Feedback wanted: lean PyTorch architecture for adversarial robustness plugins

Hi PyTorch community,

I’m working on an early-stage project called torchadv and wanted to ask for feedback before I build too much in the wrong direction.

I’m aware there are already strong projects in this space, including ART, Foolbox, torchattacks, and advertorch. In this project, I’m exploring a lean PyTorch-first architecture for adversarial robustness: batch-level attack/defense contracts, plugin registration/discovery, lifecycle metadata, and explicit implementation provenance.

The main design idea is to keep taxonomy in metadata and docs rather than coupling it tightly to the software architecture. Categories like Linf, L2, targeted/untargeted, evasion/defense, inference/training, and stable/incubating are important, but I’d like the core interfaces to stay small and operational.

Current pieces:

  • FGSM, aligned with CleverHans behavior
  • PGD, aligned with MadryLab’s LinfPGDAttack
  • adversarial training as a batch-level defense primitive
  • plugin registry for attacks and defenses
  • lifecycle metadata: incubating, stable, deprecated
  • separate reference and implementation_reference metadata

Repo: GitHub - f2cf2e10/torchadv at dev · GitHub

I’d love feedback on:

  • Is this separation between architecture and taxonomy useful?
  • Do batch-level contracts feel like the right abstraction for PyTorch users?
  • Would implementation provenance help when reviewing or trusting attack implementations?
  • What metadata would you expect every attack/defense plugin to expose?
  • What would make this worth contributing to or using in your own PyTorch projects?

The project is still experimental, so I’m mostly looking for design feedback and early direction.

Thanks!

1 Like