Flower 1.9.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Heng Pan, Javier, Mahdi Beitollahi, Robert Steiner, Taner Topal, Yan Gao, bapic, mohammadnaseri

What's new?

• Introduce built-in authentication (preview) (#2946, #3388, #2948, #2917, #3386, #3308, #3001, #3409, #2999, #2979, #3389, #3503, #3366, #3357)

  Flower 1.9 introduces the first build-in version of client node authentication. In previous releases, users often wrote glue code to connect Flower to external authentication systems. With this release, the SuperLink can authenticate SuperNodes using a built-in authentication system. A new how-to guide and a new code example help you to get started.

  This is the first preview release of the Flower-native authentication system. Many additional features are on the roadmap for upcoming Flower releases - stay tuned.

• Introduce end-to-end Docker support (#3483, #3266, #3390, #3283, #3285, #3391, #3403, #3458, #3533, #3453, #3486, #3290)

  Full Flower Next Docker support is here! With the release of Flower 1.9, Flower provides stable Docker images for the Flower SuperLink, the Flower SuperNode, and the Flower ServerApp. This set of images enables you to run all Flower components in Docker. Check out the new how-to guide to get stated.

• Re-architect Flower Next simulation engine (#3307, #3355, #3272, #3273, #3417, #3281, #3343, #3326)

  Flower Next simulations now use a new in-memory Driver that improves the reliability of simulations, especially in notebook environments. This is a significant step towards a complete overhaul of the Flower Next simulation architecture.

• Upgrade simulation engine (#3354, #3378, #3262, #3435, #3501, #3482, #3494)

  The Flower Next simulation engine comes with improved and configurable logging. The Ray-based simulation backend in Flower 1.9 was updated to use Ray 2.10.

• Introduce FedPFT baseline (#3268)

  FedPFT allows you to perform one-shot Federated Learning by leveraging widely available foundational models, dramatically reducing communication costs while delivering high performing models. This is work led by Mahdi Beitollahi from Huawei Noah's Ark Lab (Montreal, Canada). Read all the details in their paper: "Parametric Feature Transfer: One-shot Federated Learning with Foundation Models" (arxiv)

• Launch additional flwr new templates for Apple MLX, Hugging Face Transformers, scikit-learn and TensorFlow (#3291, #3139, #3284, #3251, #3376, #3287)

  The flwr CLI's flwr new command is starting to become everone's favorite way of creating new Flower projects. This release introduces additional flwr new templates for Apple MLX, Hugging Face Transformers, scikit-learn and TensorFlow. In addition to that, existing templates also received updates.

• Refine RecordSet API (#3209, #3331, #3334, #3335, #3375, #3368)

  RecordSet is part of the Flower Next low-level API preview release. In Flower 1.9, RecordSet received a number of usability improvements that make it easier to build RecordSet-based ServerApps and ClientApps.

• Beautify logging (#3379, #3430, #3461, #3360, #3433)

  Logs received a substantial update. Not only are logs now much nicer to look at, but they are also more configurable.

• Improve reliability (#3564, #3561, #3566, #3462, #3225, #3514, #3535, #3372)

  Flower 1.9 includes reliability improvements across many parts of the system. One example is a much improved SuperNode shutdown procedure.

• Update Swift and C++ SDKs (#3321, #2763)

  In the C++ SDK, communication-related code is now separate from main client logic. A new abstract class Communicator has been introduced alongside a gRPC implementation of it.

• Improve testing, tooling and CI/CD infrastructure (#3294, #3282, #3311, #2878, #3333, #3255, #3349, #3400, #3401, #3399, #3346, #3398, #3397, #3347, #3502, #3387, #3542, #3396, #3496, #3465, #3473, #3484, #3521, #3363, #3497, #3464, #3495, #3478, #3271)

  As always, the Flower tooling, testing, and CI/CD infrastructure has received many updates.

• Improve documentation (#3530, #3539, #3425, #3520, #3286, #3516, #3523, #3545, #3498, #3439, #3440, #3382, #3559, #3432, #3278, #3371, #3519, #3267, #3204, #3274)

  As always, the Fl...

Flower 1.8.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Gustavo Bertoli, Heng Pan, Ikko Eltociear Ashimine, Jack Cook, Javier, Raj Parekh, Robert Steiner, Sebastian van der Voort, Taner Topal, Yan Gao, mohammadnaseri, tabdar-khan

What's new?

• Introduce Flower Next high-level API (stable) (#3002, #2934, #2958, #3173, #3174, #2923, #2691, #3079, #2961, #2924, #3166, #3031, #3057, #3000, #3113, #2957, #3183, #3180, #3035, #3189, #3185, #3190, #3191, #3195, #3197)

  The Flower Next high-level API is stable! Flower Next is the future of Flower - all new features (like Flower Mods) will be built on top of it. You can start to migrate your existing projects to Flower Next by using ServerApp and ClientApp (check out quickstart-pytorch or quickstart-tensorflow, a detailed migration guide will follow shortly). Flower Next allows you to run multiple projects concurrently (we call this multi-run) and execute the same project in either simulation environments or deployment environments without having to change a single line of code. The best part? It's fully compatible with existing Flower projects that use Strategy, NumPyClient & co.

• Introduce Flower Next low-level API (preview) (#3062, #3034, #3069)

  In addition to the Flower Next high-level API that uses Strategy, NumPyClient & co, Flower 1.8 also comes with a preview version of the new Flower Next low-level API. The low-level API allows for granular control of every aspect of the learning process by sending/receiving individual messages to/from client nodes. The new ServerApp supports registering a custom main function that allows writing custom training loops for methods like async FL, cyclic training, or federated analytics. The new ClientApp supports registering train, evaluate and query functions that can access the raw message received from the ServerApp. New abstractions like RecordSet, Message and Context further enable sending multiple models, multiple sets of config values and metrics, stateful computations on the client node and implementations of custom SMPC protocols, to name just a few.

• Introduce Flower Mods (preview) (#3054, #2911, #3083)

  Flower Modifiers (we call them Mods) can intercept messages and analyze, edit or handle them directly. Mods can be used to develop pluggable modules that work across different projects. Flower 1.8 already includes mods to log the size of a message, the number of parameters sent over the network, differential privacy with fixed clipping and adaptive clipping, local differential privacy and secure aggregation protocols SecAgg and SecAgg+. The Flower Mods API is released as a preview, but researchers can already use it to experiment with arbirtrary SMPC protocols.

• Fine-tune LLMs with LLM FlowerTune (#3029, #3089, #3092, #3100, #3114, #3162, #3172)

  We are introducing LLM FlowerTune, an introductory example that demonstrates federated LLM fine-tuning of pre-trained Llama2 models on the Alpaca-GPT4 dataset. The example is built to be easily adapted to use different models and/or datasets. Read our blog post LLM FlowerTune: Federated LLM Fine-tuning with Flower for more details.

• Introduce built-in Differential Privacy (preview) (#2798, #2959, #3038, #3147, #2909, #2893, #2892, #3039, #3074)

  Built-in Differential Privacy is here! Flower supports both central and local differential privacy (DP). Central DP can be configured with either fixed or adaptive clipping. The clipping can happen either on the server-side or the client-side. Local DP does both clipping and noising on the client-side. A new documentation page explains Differential Privacy approaches and a new how-to guide describes how to use the new Differential Privacy components in Flower.

• Introduce built-in Secure Aggregation (preview) (#3120, #3110, #3108)

  Built-in Secure Aggregation is here! Flower now supports different secure aggregation protocols out-of-the-box. The best part? You can add secure aggregation to your Flower projects with only a few lines of code. In this initial release, we inlcude support for SecAgg and SecAgg+, but more protocols will be implemented shortly. We'll also add detailed docs that explain secure aggregation and how to use it in Flower. You can already check out the new code example that shows how to use Flower to easily combine Federated Learning, Differential Privacy and Secure Aggregation in the same project.

• Introduce flwr CLI (preview) (#2942, #3055, #3111, #3130, #3136, #3094, #3059, #3049, #3142)

  A new flwr CLI command allows creating new Flower projects (flwr new) and then running them using the Simulation Engine (flwr run).

• Introduce Flower Next Simulation Engine (#3024, #3061, #2997, #2783, #3184, #3075, #3047, #2998, #3009, #3008)

  The Flower Simulation Engine can now run Flower Next projects. For notebook environments, there's also a new run_simulation function that can run ServerApp and ClientApp.

• Handle SuperNode connection errors (#2969)

  A SuperNode will now try to reconnect indefinitely to the SuperLink in case of connection errors. The arguments --max-retries and --max-wait-time can now be passed to the flower-client-app command. --max-retries will define the number of tentatives the client should make before it gives up trying to reconnect to the SuperLink, and, --max-wait-time defines the time before the SuperNode gives up trying to reconnect to the SuperLink.

• General updates to Flower Baselines (#2904, #2482, #2985, #2968)

  There's a new FedStar baseline. Several other baselined have been updated as well.

• Improve documentation and translations (#3050, #3044, #3043, #2986, #3041, #3046, #3042, #2978, #2952, [#316...

Flower 1.7.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Aasheesh Singh, Adam Narozniak, Aml Hassan Esmil, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Edoardo Gabrielli, Gustavo Bertoli, HelinLin, Heng Pan, Javier, M S Chaitanya Kumar, Mohammad Naseri, Nikos Vlachakis, Pritam Neog, Robert Kuska, Robert Steiner, Taner Topal, Yahia Salaheldin Shaaban, Yan Gao, Yasar Abbas

What's new?

• Introduce stateful clients (experimental) (#2770, #2686, #2696, #2643, #2769)

  Subclasses of Client and NumPyClient can now store local state that remains on the client. Let's start with the highlight first: this new feature is compatible with both simulated clients (via start_simulation) and networked clients (via start_client). It's also the first preview of new abstractions like Context and RecordSet. Clients can access state of type RecordSet via state: RecordSet = self.context.state. Changes to this RecordSet are preserved across different rounds of execution to enable stateful computations in a unified way across simulation and deployment.

• Improve performance (#2293)

  Flower is faster than ever. All FedAvg-derived strategies now use in-place aggregation to reduce memory consumption. The Flower client serialization/deserialization has been rewritten from the ground up, which results in significant speedups, especially when the client-side training time is short.

• Support Federated Learning with Apple MLX and Flower (#2693)

  Flower has official support for federated learning using Appple MLX via the new quickstart-mlx code example.

• Introduce new XGBoost cyclic strategy (#2666, #2668)

  A new strategy called FedXgbCyclic supports a client-by-client style of training (often called cyclic). The xgboost-comprehensive code example shows how to use it in a full project. In addition to that, xgboost-comprehensive now also supports simulation mode. With this, Flower offers best-in-class XGBoost support.

• Support Python 3.11 (#2394)

  Framework tests now run on Python 3.8, 3.9, 3.10, and 3.11. This will ensure better support for users using more recent Python versions.

• Update gRPC and ProtoBuf dependencies (#2814)

  The grpcio and protobuf dependencies were updated to their latest versions for improved security and performance.

• Introduce Docker image for Flower server (#2700, #2688, #2705, #2695, #2747, #2746, #2680, #2682, #2701)

  The Flower server can now be run using an official Docker image. A new how-to guide explains how to run Flower using Docker. An official Flower client Docker image will follow.

• Introduce flower-via-docker-compose example (#2626)

• Introduce quickstart-sklearn-tabular example (#2719)

• Introduce custom-metrics example (#1958)

• Update code examples to use Flower Datasets (#2450, #2456, #2318, #2712)

  Several code examples were updated to use Flower Datasets.

• General updates to Flower Examples (#2381, #2805, #2782, #2806, #2829, #2825, #2816, #2726, #2659, #2655)

  Many Flower code examples received substantial updates.

• Update Flower Baselines

  • HFedXGBoost (#2226, #2771)
  • FedVSSL (#2412)
  • FedNova (#2179)
  • HeteroFL (#2439)
  • FedAvgM (#2246)
  • FedPara (#2722)

• Improve documentation (#2674, #2480, #2826, #2727, #2761, #2900)

• Improved testing and development infrastructure (#2797, #2676, #2644, #2656, #2848, #2675, #2735, #2767, #2732, #2744, #2681, #2699, #2745, #2734, #2731, #2652, #2720, #2721, #2717, #2864, #2694, #2709, #2658, #2796, #2692, #2657, #2813, #2661, #2398)

  The Flower testing and development infrastructure has received substantial updates. This makes Flower 1.7 the most tested release ever.

• Update dependencies (#2753, #2651, #2739, #2837, #2788, #2811, #2774, #2790, #2751, #2850, #2812, #2872, #2736, #2756, #2857, #2757, #2810, #2740, #2789)

• General improvements (#2803, #2847, #2877, #2690, #2889, #2874, #2819, #2689, #2457, #2870, #2669, #2876, #2885, #2858, #2867, #2351, #2886, #2860, #2828, #2869, #2875, #2733, #2488, #2646, #2879, #2821, [#2855](https://...

Flower 1.6.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Aashish Kolluri, Adam Narozniak, Alessio Mora, Barathwaja S, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Gabriel Mota, Heng Pan, Ivan Agarský, JS.KIM, Javier, Marius Schlegel, Navin Chandra, Nic Lane, Peterpan828, Qinbin Li, Shaz-hash, Steve Laskaridis, Taner Topal, William Lindskog, Yan Gao, cnxdeveloper, k3nfalt

What's new?

• Add experimental support for Python 3.12 (#2565)

• Add new XGBoost examples (#2612, #2554, #2617, #2618, #2619, #2567)

  We have added a new xgboost-quickstart example alongside a new xgboost-comprehensive example that goes more in-depth.

• Add Vertical FL example (#2598)

  We had many questions about Vertical Federated Learning using Flower, so we decided to add an simple example for it on the Titanic dataset alongside a tutorial (in the README).

• Support custom ClientManager in start_driver() (#2292)

• Update REST API to support create and delete nodes (#2283)

• Update the Android SDK (#2187)

  Add gRPC request-response capability to the Android SDK.

• Update the C++ SDK (#2537, #2528, #2523, #2522)

  Add gRPC request-response capability to the C++ SDK.

• Make HTTPS the new default (#2591, #2636)

  Flower is moving to HTTPS by default. The new flower-server requires passing --certificates, but users can enable --insecure to use HTTP for prototyping. The same applies to flower-client, which can either use user-provided credentials or gRPC-bundled certificates to connect to an HTTPS-enabled server or requires opt-out via passing --insecure to enable insecure HTTP connections.

  For backward compatibility, start_client() and start_numpy_client() will still start in insecure mode by default. In a future release, insecure connections will require user opt-in by passing insecure=True.

• Unify client API (#2303, #2390, #2493)

  Using the client_fn, Flower clients can interchangeably run as standalone processes (i.e. via start_client) or in simulation (i.e. via start_simulation) without requiring changes to how the client class is defined and instantiated. The to_client() function is introduced to convert a NumPyClient to a Client.

• Add new Bulyan strategy (#1817, #1891)

  The new Bulyan strategy implements Bulyan by El Mhamdi et al., 2018

• Add new XGB Bagging strategy (#2611)

• Update Flower Baselines

  • FedProx (#2210, #2286, #2509)

  • Baselines Docs (#2290, #2400)

  • FedMLB (#2340, #2507)

  • TAMUNA (#2254, #2508)

  • FedMeta #2438

  • FjORD #2431

  • MOON #2421

  • DepthFL #2295

  • FedPer #2266

  • FedWav2vec #2551

  • niid-Bench #2428

  • FedBN (#2608, #2615)

• General updates to Flower Examples (#2384,#2425, #2526, #2302, #2545)

• General updates to Flower Baselines (#2301, #2305, #2307, #2327, #2435, #2462, #2463, #2461, #2469, #2466, #2471, #2472, #2470)

• General updates to the simulation engine (#2331, #2447, #2448, #2294)

• General updates to Flower SDKs (#2288, #2429, #2555, #2543, #2544, #2597, #2623)

• General improvements (#2309, #2310, 2313, #2316, 2317, #2349, #2360, #2402, #2446, #2561, #2273, #2267, #2274, #2275, #2432, #2251, #2321, #1936, #2408, #2413, #2401, #2531, #2534, #2535, #2521, #2553, #2596)

  Flower received many improvements under the hood, too many to list here.

Incompatible changes

• Remove support for Python 3.7 (#2280, #2299, #2304, #2306, #2355, #2356)

  Python 3.7 support was deprecated in Flower 1.5, and this release removes support. Flower now requires Python 3.8.

• Remove experimental argument rest from start_client (#2324)

  The (still experimental) argument rest was removed from start_client and start_numpy_client. Use transport="rest" to opt into the experimental REST API instead.

Flower 1.5.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

achiverram28, Adam Narozniak, Anass Anhari, Charles Beauville, Dana-Farber, Daniel J. Beutel, Daniel Nata Nugraha, Edoardo Gabrielli, eunchung, Gustavo Bertoli, Heng Pan, Javier, Mahdi, Ruth Galindo, Steven Hé (Sīchàng), Taner Topal

What's new?

• Introduce new simulation engine (#1969, #2221, #2248)

  The new simulation engine has been rewritten from the ground up, yet it remains fully backwards compatible. It offers much improved stability and memory handling, especially when working with GPUs. Simulations transparently adapt to different settings to scale simulation in CPU-only, CPU+GPU, multi-GPU, or multi-node multi-GPU environments.

  Comprehensive documentation includes a new how-to run simulations guide, new simulation-pytorch and simulation-tensorflow notebooks, and a new YouTube tutorial series.

• Restructure Flower Docs (#1824, #1865, #1884, #1887, #1919, #1922, #1920, #1923, #1924, #1962, #2006, #2133, #2203, #2215, #2122, #2223, #2219, #2232, #2233, #2234, #2235, #2237, #2238, #2242, #2231, #2243, #2227)

  Much effort went into a completely restructured Flower docs experience. The documentation on flower.dev/docs is now divided into Flower Framework, Flower Baselines, Flower Android SDK, Flower iOS SDK, and code example projects.

• Introduce Flower Swift SDK (#1858, #1897)

  This is the first preview release of the Flower Swift SDK. Flower support on iOS is improving, and alongside the Swift SDK and code example, there is now also an iOS quickstart tutorial.

• Introduce Flower Android SDK (#2131)

  This is the first preview release of the Flower Kotlin SDK. Flower support on Android is improving, and alongside the Kotlin SDK and code example, there is now also an Android quickstart tutorial.

• Introduce new end-to-end testing infrastructure (#1842, #2071, #2072, #2068, #2067, #2069, #2073, #2070, #2074, #2082, #2084, #2093, #2109, #2095, #2140, #2137, #2165)

  A new testing infrastructure ensures that new changes stay compatible with existing framework integrations or strategies.

• Deprecate Python 3.7

  Since Python 3.7 reached its end of life (EOL) on 2023-06-27, support for Python 3.7 is now deprecated and will be removed in an upcoming release.

• Add new FedTrimmedAvg strategy (#1769, #1853)

  The new FedTrimmedAvg strategy implements Trimmed Mean by Dong Yin, 2018.

• Introduce start_driver (#1697)

  In addition to start_server and using the raw Driver API, there is a new start_driver function that allows for running start_server scripts as a Flower driver with only a single-line code change. Check out the mt-pytorch code example to see a working example using start_driver.

• Add parameter aggregation to mt-pytorch code example (#1785)

  The mt-pytorch example shows how to aggregate parameters when writing a driver script. The included driver.py and server.py have been aligned to demonstrate both the low-level way and the high-level way of building server-side logic.

• Migrate experimental REST API to Starlette (2171)

  The (experimental) REST API used to be implemented in FastAPI, but it has now been migrated to use Starlette directly.

  Please note: The REST request-response API is still experimental and will likely change significantly over time.

• Introduce experimental gRPC request-response API (#1867, #1901)

  In addition to the existing gRPC API (based on bidirectional streaming) and the experimental REST API, there is now a new gRPC API that uses a request-response model to communicate with client nodes.

  Please note: The gRPC request-response API is still experimental and will likely change significantly over time.

• Replace the experimental start_client(rest=True) with the new start_client(transport="rest") (#1880)

  The (experimental) start_client argument rest was deprecated in favour of a new argument transport. start_client(transport="rest") will yield the same behaviour as start_client(rest=True) did before. All code should migrate to the new argument transport. The deprecated argument rest will be removed in a future release.

• Add a new gRPC option (#2197)

  We now start a gRPC server with the grpc.keepalive_permit_without_calls option set to 0 by default. This prevents the clients from sending keepalive pings when there is no outstanding stream.

• Improve example notebooks (#2005)

  There's a new 30min Federated Learning PyTorch tutorial!

• Example updates (#1772, #1873, #1981, #1988, #1984, #1982, #2112, #2144, #2174, #2225, #2183)

  Many examples have received significant updates, including simplified advanced-tensorflow and advanced-pytorch examples, improved macOS compatibility of TensorFlow examples, and code examples for simulation. A major upgrade is that all code examples now have a requirements.txt (in addition to pyproject.toml).

• General improvements (#1872, #1866, #1884, #1837, #1477, #2171)

  Flower received many improvements under the hood, too many to list here.

Incompatible changes

None

Flower 1.4.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Alexander Viala Bellander, Charles Beauville, Chenyang Ma (Danny), Daniel J. Beutel, Edoardo, Gautam Jajoo, Iacob-Alexandru-Andrei, JDRanpariya, Jean Charle Yaacoub, Kunal Sarkhel, L. Jiang, Lennart Behme, Max Kapsecker, Michał, Nic Lane, Nikolaos Episkopos, Ragy, Saurav Maheshkar, Semo Yang, Steve Laskaridis, Steven Hé (Sīchàng), Taner Topal

What's new?

• Introduce support for XGBoost (FedXgbNnAvg strategy and example) (#1694, #1709, #1715, #1717, #1763, #1795)

  XGBoost is a tree-based ensemble machine learning algorithm that uses gradient boosting to improve model accuracy. We added a new FedXgbNnAvg strategy, and a code example that demonstrates the usage of this new strategy in an XGBoost project.

• Introduce iOS SDK (preview) (#1621, #1764)

  This is a major update for anyone wanting to implement Federated Learning on iOS mobile devices. We now have a swift iOS SDK present under src/swift/flwr that will facilitate greatly the app creating process. To showcase its use, the iOS example has also been updated!

• Introduce new "What is Federated Learning?" tutorial (#1657, #1721)

  A new entry-level tutorial in our documentation explains the basics of Fedetated Learning. It enables anyone who's unfamiliar with Federated Learning to start their journey with Flower. Forward it to anyone who's interested in Federated Learning!

• Introduce new Flower Baseline: FedProx MNIST (#1513, #1680, #1681, #1679)

  This new baseline replicates the MNIST+CNN task from the paper Federated Optimization in Heterogeneous Networks (Li et al., 2018). It uses the FedProx strategy, which aims at making convergence more robust in heterogenous settings.

• Introduce new Flower Baseline: FedAvg FEMNIST (#1655)

  This new baseline replicates an experiment evaluating the performance of the FedAvg algorithm on the FEMNIST dataset from the paper LEAF: A Benchmark for Federated Settings (Caldas et al., 2018).

• Introduce (experimental) REST API (#1594, #1690, #1695, #1712, #1802, #1770, #1733)

  A new REST API has been introduced as an alternative to the gRPC-based communication stack. In this initial version, the REST API only supports anonymous clients.

  Please note: The REST API is still experimental and will likely change significantly over time.

• Improve the (experimental) Driver API (#1663, #1666, #1667, #1664, #1675, #1676, #1693, #1662, #1794)

  The Driver API is still an experimental feature, but this release introduces some major upgrades. One of the main improvements is the introduction of an SQLite database to store server state on disk (instead of in-memory). Another improvement is that tasks (instructions or results) that have been delivered will now be deleted. This greatly improves the memory efficiency of a long-running Flower server.

• Fix spilling issues related to Ray during simulations (#1698)

  While running long simulationa, ray was sometimes spilling huge amounts of data that would make the training unable to continue. This is now fixed! 🎉

• Add new example using TabNet and Flower (#1725)

  TabNet is a powerful and flexible framework for training machine learning models on tabular data. We now have a federated example using Flower: https://github.com/adap/flower/tree/main/examples/tabnet.

• Add new how-to guide for monitoring simulations (#1649)

  We now have a documentation guide to help users monitor their performance during simulations.

• Add training metrics to History object during simulations (#1696)

  The fit_metrics_aggregation_fn can be used to aggregate training metrics, but previous releases did not save the results in the History object. This is now the case!

• General improvements (#1659, #1646, #1647, #1471, #1648, #1651, #1652, #1653, #1659, #1665, #1670, #1672, #1677, #1684, #1683, #1686, #1682, #1685, #1692, #1705, #1708, #1711, #1713, #1714, #1718, #1716, #1723, #1735, #1678, #1750, #1753, #1736, #1766, #1760, #1775, #1776, #1777, #1779, #1784, #1773, #1755, #1789, #1788, #1798, #1799, #1739, #1800, #1804, #1805)

  Flower received many improvements under the hood, too many to list here.

Incompatible changes

None

Flower 1.3.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Alexander Viala Bellander, Charles Beauville, Daniel J. Beutel, JDRanpariya, Lennart Behme, Taner Topal

What's new?

• Add support for workload_id and group_id in Driver API (#1595)

  The (experimental) Driver API now supports a workload_id that can be used to identify which workload a task belongs to. It also supports a new group_id that can be used, for example, to indicate the current training round. Both the workload_id and group_id enable client nodes to decide whether they want to handle a task or not.

• Make Driver API and Fleet API address configurable (#1637)

  The (experimental) long-running Flower server (Driver API and Fleet API) can now configure the server address of both Driver API (via --driver-api-address) and Fleet API (via --fleet-api-address) when starting:

  flower-server --driver-api-address "0.0.0.0:8081" --fleet-api-address "0.0.0.0:8086"

  Both IPv4 and IPv6 addresses are supported.

• Add new example of Federated Learning using fastai and Flower (#1598)

  A new code example (quickstart_fastai) demonstrates federated learning with fastai and Flower. You can find it here: quickstart_fastai.

• Make Android example compatible with flwr >= 1.0.0 and the latest versions of Android (#1603)

  The Android code example has received a substantial update: the project is compatible with Flower 1.0 and later, the UI received a full refresh, and the project is updated to be compatible with newer Android tooling.

• Add new FedProx strategy (#1619)

  This strategy is almost identical to FedAvg, but helps users replicate what is described in this paper. It essentially adds a parameter called proximal_mu to regularize the local models with respect to the global models.

• Add new metrics to telemetry events (#1640)

  An updated event structure allows, for example, the clustering of events within the same workload.

• Add new custom strategy tutorial section #1623

  The Flower tutorial now has a new section that covers implementing a custom strategy from scratch: Open in Colab

• Add new custom serialization tutorial section (#1622)

  The Flower tutorial now has a new section that covers custom serialization: Open in Colab

• General improvements (#1638, #1634, #1636, #1635, #1633, #1632, #1631, #1630, #1627, #1593, #1616, #1615, #1607, #1609, #1608, #1603, #1590, #1580, #1599, #1600, #1601, #1597, #1595, #1591, #1588, #1589, #1587, #1573, #1581, #1578, #1574, #1572, #1586)

  Flower received many improvements under the hood, too many to list here.

• Updated documentation (#1629, #1628, #1620, #1618, #1617, #1613, #1614)

  As usual, the documentation has improved quite a bit. It is another step in our effort to make the Flower documentation the best documentation of any project. Stay tuned and as always, feel free to provide feedback!

Incompatible changes

None

Flower 1.2.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Adam Narozniak, Charles Beauville, Daniel J. Beutel, Edoardo, L. Jiang, Ragy, Taner Topal, dannymcy

What's new?

• Introduce new Flower Baseline: FedAvg MNIST (#1497, #1552)

  Over the coming weeks, we will be releasing a number of new reference implementations useful especially to FL newcomers. They will typically revisit well known papers from the literature, and be suitable for integration in your own application or for experimentation, in order to deepen your knowledge of FL in general. Today's release is the first in this series. Read more.

• Improve GPU support in simulations (#1555)

  The Ray-based Virtual Client Engine (start_simulation) has been updated to improve GPU support. The update includes some of the hard-earned lessons from scaling simulations in GPU cluster environments. New defaults make running GPU-based simulations substantially more robust.

• Improve GPU support in Jupyter Notebook tutorials (#1527, #1558)

  Some users reported that Jupyter Notebooks have not always been easy to use on GPU instances. We listened and made improvements to all of our Jupyter notebooks! Check out the updated notebooks here:

  • An Introduction to Federated Learning
  • Strategies in Federated Learning
  • Building a Strategy
  • Client and NumPyClient

• Introduce optional telemetry (#1533, #1544, #1584)

  After a request for feedback from the community, the Flower open-source project introduces optional collection of anonymous usage metrics to make well-informed decisions to improve Flower. Doing this enables the Flower team to understand how Flower is used and what challenges users might face.

  Flower is a friendly framework for collaborative AI and data science. Staying true to this statement, Flower makes it easy to disable telemetry for users that do not want to share anonymous usage metrics. Read more..

• Introduce (experimental) Driver API (#1520, #1525, #1545, #1546, #1550, #1551, #1567)

  Flower now has a new (experimental) Driver API which will enable fully programmable, async, and multi-tenant Federated Learning and Federated Analytics applications. Phew, that's a lot! Going forward, the Driver API will be the abstraction that many upcoming features will be built on - and you can start building those things now, too.

  The Driver API also enables a new execution mode in which the server runs indefinitely. Multiple individual workloads can run concurrently and start and stop their execution independent of the server. This is especially useful for users who want to deploy Flower in production.

  To learn more, check out the mt-pytorch code example. We look forward to you feedback!

  Please note: The Driver API is still experimental and will likely change significantly over time.

• Add new Federated Analytics with Pandas example (#1469, #1535)

  A new code example (quickstart_pandas) demonstrates federated analytics with Pandas and Flower. You can find it here: quickstart_pandas.

• Add new strategies: Krum and MultiKrum (#1481)

  Edoardo, a computer science student at the Sapienza University of Rome, contributed a new Krum strategy that enables users to easily use Krum and MultiKrum in their workloads.

• Update C++ example to be compatible with Flower v1.2.0 (#1495)

  The C++ code example has received a substantial update to make it compatible with the latest version of Flower.

• General improvements (#1491, #1504, #1506, #1514, #1522, #1523, #1526, #1528, #1547, #1549, #1560, #1564, #1566)

Flower received many improvements under the hood, too many to list here.

• Updated documentation (#1494, #1496, #1500, #1503, #1505, #1524, #1518, #1519, #1515)

  As usual, the documentation has improved quite a bit. It is another step in our effort to make the Flower documentation the best documentation of any project. Stay tuned and as always, feel free to provide feedback!

  One highlight is the new first time contributor guide: if you've never contributed on GitHub before, this is the perfect place to start!

Incompatible changes

None

Flower 1.1.0

Thanks to our contributors

We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog order):

Akis Linardos, Christopher S, Daniel J. Beutel, George, Jan Schlicht, Mohammad Fares, Pedro Porto Buarque de Gusmão, Philipp Wiesner, Rob Luke, Taner Topal, VasundharaAgarwal, danielnugraha, edogab33

What's new?

• Introduce Differential Privacy wrappers (preview) (#1357, #1460)

  The first (experimental) preview of pluggable Differential Privacy wrappers enables easy configuration and usage of differential privacy (DP). The pluggable DP wrappers enable framework-agnostic and strategy-agnostic usage of both client-side DP and server-side DP. Head over to the Flower docs, a new explainer goes into more detail.

• New iOS CoreML code example (#1289)

  Flower goes iOS! A massive new code example shows how Flower clients can be built for iOS. The code example contains both Flower iOS SDK components that can be used for many tasks, and one task example running on CoreML.

• New FedMedian strategy (#1461)

  The new FedMedian strategy implements Federated Median (FedMedian) by Yin et al., 2018.

• Log Client exceptions in Virtual Client Engine (#1493)

  All Client exceptions happening in the VCE are now logged by default and not just exposed to the configured Strategy (via the failures argument).

• Improve Virtual Client Engine internals (#1401, #1453)

  Some internals of the Virtual Client Engine have been revamped. The VCE now uses Ray 2.0 under the hood, the value type of the client_resources dictionary changed to float to allow fractions of resources to be allocated.

• Support optional Client/NumPyClient methods in Virtual Client Engine

  The Virtual Client Engine now has full support for optional Client (and NumPyClient) methods.

• Provide type information to packages using flwr (#1377)

  The package flwr is now bundled with a py.typed file indicating that the package is typed. This enables typing support for projects or packages that use flwr by enabling them to improve their code using static type checkers like mypy.

• Updated code example (#1344, #1347)

  The code examples covering scikit-learn and PyTorch Lightning have been updated to work with the latest version of Flower.

• Updated documentation (#1355, #1558, #1379, #1380, #1381, #1332, #1391, #1403, #1364, #1409, #1419, #1444, #1448, #1417, #1449, #1465, #1467)

  There have been so many documentation updates that it doesn't even make sense to list them individually.

• Restructured documentation (#1387)

  The documentation has been restructured to make it easier to navigate. This is just the first step in a larger effort to make the Flower documentation the best documentation of any project ever. Stay tuned!

• Open in Colab button (#1389)

  The four parts of the Flower Federated Learning Tutorial now come with a new Open in Colab button. No need to install anything on your local machine, you can now use and learn about Flower in your browser, it's only a single click away.

• Improved tutorial (#1468, #1470, #1472, #1473, #1474, #1475)

  The Flower Federated Learning Tutorial has two brand-new parts covering custom strategies (still WIP) and the distinction between Client and NumPyClient. The existing parts one and two have also been improved (many small changes and fixes).

Incompatible changes

None

Flower 1.0.0

Highlights

• Stable Virtual Client Engine (accessible via start_simulation)
• All Client/NumPyClient methods are now optional
• Configurable get_parameters
• Tons of small API cleanups resulting in a more coherent developer experience

Thanks to our contributors

We would like to give our special thanks to all the contributors who made Flower 1.0 possible (in reverse GitHub Contributors order):

@rtaiello, @g-pichler, @rob-luke, @andreea-zaharia, @kinshukdua, @nfnt, @tatiana-s, @TParcollet, @vballoli, @negedng, @RISHIKESHAVAN, @hei411, @SebastianSpeitel, @AmitChaulwar, @Rubiel1, @FANTOME-PAN, @Rono-BC, @lbhm, @sishtiaq, @remde, @Jueun-Park, @architjen, @PratikGarai, @mrinaald, @zliel, @MeiruiJiang, @sandracl72, @gubertoli, @Vingt100, @MakGulati, @cozek, @jafermarq, @sisco0, @akhilmathurs, @CanTuerk, @mariaboerner1987, @pedropgusmao, @tanertopal, @danieljanes.

Incompatible changes

• All arguments must be passed as keyword arguments (#1338)

  Pass all arguments as keyword arguments, positional arguments are not longer supported. Code that uses positional arguments (e.g., start_client("127.0.0.1:8080", FlowerClient())) must add the keyword for each positional argument (e.g., start_client(server_address="127.0.0.1:8080", client=FlowerClient())).

• Introduce configuration object ServerConfig in start_server and start_simulation (#1317)

  Instead of a config dictionary {"num_rounds": 3, "round_timeout": 600.0}, start_server and start_simulation now expect a configuration object of type flwr.server.ServerConfig. ServerConfig takes the same arguments that as the previous config dict, but it makes writing type-safe code easier and the default parameters values more transparent.

• Rename built-in strategy parameters for clarity (#1334)

  The following built-in strategy parameters were renamed to improve readability and consistency with other API's:

  • fraction_eval --> fraction_evaluate
  • min_eval_clients --> min_evaluate_clients
  • eval_fn --> evaluate_fn

• Update default arguments of built-in strategies (#1278)

  All built-in strategies now use fraction_fit=1.0 and fraction_evaluate=1.0, which means they select all currently available clients for training and evaluation. Projects that relied on the previous default values can get the previous behaviour by initializing the strategy in the following way:

  strategy = FedAvg(fraction_fit=0.1, fraction_evaluate=0.1)

• Add server_round to Strategy.evaluate (#1334)

  The Strategy method evaluate now receives the current round of federated learning/evaluation as the first parameter.

• Add server_round and config parameters to evaluate_fn (#1334)

  The evaluate_fn passed to built-in strategies like FedAvg now takes three parameters: (1) The current round of federated learning/evaluation (server_round), (2) the model parameters to evaluate (parameters), and (3) a config dictionary (config).

• Rename rnd to server_round (#1321)

  Several Flower methods and functions (evaluate_fn, configure_fit, aggregate_fit, configure_evaluate, aggregate_evaluate) receive the current round of federated learning/evaluation as their first parameter. To improve reaability and avoid confusion with random, this parameter has been renamed from rnd to server_round.

• Move flwr.dataset to flwr_baselines (#1273)

  The experimental package flwr.dataset was migrated to Flower Baselines.

• Remove experimental strategies (#1280)

  Remove unmaintained experimental strategies (FastAndSlow, FedFSv0, FedFSv1).

• Rename Weights to NDArrays (#1258, #1259)

  flwr.common.Weights was renamed to flwr.common.NDArrays to better capture what this type is all about.

• Remove antiquated force_final_distributed_eval from start_server (#1258, #1259)

  The start_server parameter force_final_distributed_eval has long been a historic artefact, in this release it is finally gone for good.

• Make get_parameters configurable (#1242)

  The get_parameters method now accepts a configuration dictionary, just like get_properties, fit, and evaluate.

• Replace num_rounds in start_simulation with new config parameter (#1281)

  The start_simulation function now accepts a configuration dictionary config instead of the num_rounds integer. This improves the consistency between start_simulation and start_server and makes transitioning between the two easier.

New features

• Support Python 3.10 (#1320)

  The previous Flower release introduced experimental support for Python 3.10, this release declares Python 3.10 support as stable.

• Make all Client and NumPyClient methods optional (#1260, #1277)

  The Client/NumPyClient methods get_properties, get_parameters, fit, and evaluate are all optional. This enables writing clients that implement, for example, only fit, but no other method. No need to implement evaluate when using centralized evaluation!

• Enable passing a Server instance to start_simulation (#1281)

  Similar to start_server, start_simulation now accepts a full Server instance. This enables users to heavily customize the execution of eperiments and opens the door to running, for example, async FL using the Virtual Client Engine.

• Update code examples (#1291, #1286, #1282)

  Many code examples received small or even large maintenance updates, among them are

  • scikit-learn
  • simulation_pytorch
  • quickstart_pytorch
  • quickstart_simulation
  • quickstart_tensorflow
  • advanced_tensorflow

• Remove the obsolete simulation example (#1328)

  Removes the obsolete simulation example and renames quickstart_simulation to simulation_tensorflow so it fits withs the naming of simulation_pytorch

• Update documentation (#1223, #1209, #1251, #1257, #1267, #1268, #1300, #1304, #1305, #1307)

  One substantial documentation update fixes multiple smaller rendering issues, makes titles more succinct to improve navigation, removes a deprecated library, updates documentation dependencies, includes the flwr.common module in the API reference, includes support for markdown-based documentation, migrates the changelog from .rst to .md, and fixes a number of smaller details!

• Minor updates

  • Add round number to fit and evaluate log messages (#1266)
  • Add secure gRPC connection to the advanced_tensorflow code example (#847)
  • Update developer tooling (#1231, #1276, #1301, #1310)
  • Rename ProtoBuf messages to improve consistency (#1214, #1258, [#1259](https://github.com/a...