We're not "still" using Markdown, we're only getting started.
Markdown is only going to get more popular as AI agents usage grows.
HN user
We're not "still" using Markdown, we're only getting started.
Markdown is only going to get more popular as AI agents usage grows.
Flower Labs and Starcloud are sharing a major milestone: the successful execution of a decentralized AI workload using Flower on an operational Starcloud satellite.
ViT (Vision Transformer) fine-tuned on a Starcloud satellite in space (using the Flower framework) -- to the best of our knowledge, this is a world first: https://flower.ai/blog/2026-02-02-flower-labs-and-starcloud-...
Not having to install CUDA is a killer feature, looking forward to DGX OS
Given the code quality and rigid testing, SQLite is probably the last project that should be rewritten. It'd be great to see all other C code rewritten first!
We use Pyenv successfully for developing the Flower open-source project. We use a few simple Bash scripts to manage virtual environments with different Python versions via pyenv and the pyenv-virtualenv plugin.
The main scripts are `venv-create.sh`, `venv-delete.sh` and `bootstrap.sh`. `venv-reset.sh` pulls these three scripts together to make reinstalling your venv a single command.
Here's the link if anyone is interested: https://github.com/adap/flower/tree/main/dev
The big opportunity on the edge is access to more data. Especially with the rise of end-to-end encryption, applications will be able to use more (and more diverse) data on the edge to get better model performance. It's generally true that training on beefier infrastructure is easier, but in the long run, nothing can beat access to better data. And edge hardware has gotten a lot faster over the last few years.
I can confirm that we're seeing 2x to 3x faster (RPi 4 vs RPi 5) in some of our early tests
One of the Flower maintainers here. The code example is primarily meant as a demonstrator to show that it's possible to fine-tune these models in a federated way on devices as small as a Raspberry Pi 5.
The bigger takeaway is that we're close to being able to train/fine-tune models with much better performance by accessing vastly more data on the edge, in a federated way.
One of the Flower maintainers here, we're planning to follow up with a more in-depth performance comparison soon
Does GGML support training on the edge? We're especially interested in training support for Android+iOS
One of the creators of Flower here - I can only say that the team behind Flower appreciates the contributions of FedML to the field of federated learning. Their work helps to make federated learning more widely known, and they published significant advances in making federated learning more robust and scalable.
In fact, we are in the process of implementing LightSecAgg, and we'd welcome their feedback once we have a working version.
Indeed - looking forward to this
Thanks for adding this here! We added these DP wrappers, and we're working on something similar for Secure Aggregation, but I must admit that we have to document them better to make using them easier for everyone
Great to hear, thanks for sharing - modularity, scalability, and user friendliness are what we think a lot about :)
Thanks! We're huge fans of the work that PySyft is doing, and we're very supportive of the Flower PySyft integration.
There are some similarities, but also some differences. Flower's take is that it wants to support the entire FL workflow from experimental research to large-scale production deployments and operation. Some other FL frameworks fall either in the "research" or "production deployment" bucket, but few have good support for both.
Flower does a lot under the hood to support these different usage scenarios: it has both a networked engine (gRPC, experimental support for REST, and the possibility to "bring your own communication stack") and a simulation engine to support both real deployment on edge devices/server and simulation of large-scale federations on single machines or compute clusters.
This is - to the best of our knowledge - one of the drivers of our large and active community. The community is very collaborative and there are many downstream projects in the ecosystem that build on top of Flower (GitHub lists 748 dependent projects: https://github.com/adap/flower/network/dependents).
Hi there - the data never moves if you train a model using federated learning. It stays on user devices or in organizational silos. After the training, you have the model parameters of the model on the server, without the server having ever seen a single data example.
After the training, you can deploy the model in different ways. If you want to use it on device (or in one of the organizational silos), you can send the final model parameters there and deploy it locally. Or you just deploy the model on the server behind an API. It all depends on the use case.
Hope that helps, I'm happy to provide more details.
Thanks, we're excited too!
Flower tries to automate this as much as it can. In cases where multiple organizations are involved, the workload can run in a fully automated manner if that's fine for all organizations. If a review step is required, that can be integrated (either on the client side or on the server side) - the availability of reviewers will then become the bottleneck for end-to-end latency.
In the long run, we will evolve the permissioning system to allow workloads to be automatically executed if they fall within pre-approved boundaries, or require manual review if they don't. Pre-approved boundaries could, for example, be used to configure a particular combination of models and hyperparemter ranges that are ok to run without additional (manual) approvals.
Agreed that this is an interesting direction. The core Flower abstractions are "federated learning agnostic", which means that they can be used for different kinds of distributed/federated workloads, not just federated learning. We'll add examples for more approaches (like SMPC) in the future, we just don't have the bandwidth to do it immediately.
Thanks, glad you like it!
One approach to increase the transparency on the client side (and build trust with the organization where the Flower clien is deployed) is to integrate a review step that asks the someone to confirm the update that gets send back to the server.
On top of that, you should definitely use differential privacy. To quote Andrew Trask here: "friends don't let friends use FL without DP". Other approaches like Secure Aggregation can also help, depending on what kind of exposure your clients are concerned about.
My general take is that the best way to solve for transparency and trust is to tackle it on multiple layers of the stack.
One of the creators of Flower here, AMA!
Yes, it's remote! Thanks for the hint, we'll add it to the description
Thanks for sharing this - I'm the author of the blog post, feel free to reach out if I can help.