Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had an amazing week.
🦥 No selling out today
I am genuinely considering selling feet pics, so if you work at a company with a marketing budget please forward this to your boss immediately or the feet come out.
Federated Learning
This is a really cool topic I recently learned about.
Have you ever felt like tech companies know way too much about you?
That’s because they do.
Every time you type something, search something, or breathe near your phone, someone’s training a model on it.
One approach that became popular in modern ML research is federated learning:
“What if the model could learn from data stored across many devices or organizations without first copying all of that raw data into one central training dataset?”
That’s the basic idea behind federated learning: training is coordinated across multiple clients that keep their local datasets where they already live.
Depending on the system, that can let a model learn from many phones, hospitals, banks, or other data owners without centrally collecting the raw training records.
That can reduce how much sensitive raw data is moved around—but it does not mean privacy is automatically solved. The updates themselves can still reveal information if the system is designed badly.
Why does this exist?
Privacy and data-governance concerns are major reasons to consider it, but federated learning can also help when data is naturally distributed, too large or expensive to centralize, or controlled by separate organizations.
Traditional machine learning usually works like this:
# Pretend this is fancy ML code (simplified obviously)
all_user_data = collect_from_everyone() # hmm, sketchy
model = train_model(all_user_data)And this worked great from a technical view…
But in the real world, there was problems:
Centralizing sensitive data creates a larger security and governance burden.
Organizations may face contractual, regulatory, or policy limits on moving raw data.
Hospitals, banks, phones, and other clients may naturally generate data in separate locations.
Uploading every raw example can be expensive or unnecessary.
Federated Learning (FL)
Instead of bringing data to the model, FL brings the model to the data:
# Federated learning sketch — deliberately simplified
model = initial_model()
for round in range(100):
selected_clients = choose_available_clients()
updates = []
for client in selected_clients:
# Client trains a local copy on local data
update = train_locally(model, client.local_data)
updates.append(update)
# Server combines client updates into a new global model
model = aggregate(updates)The raw examples can remain local while model parameters, gradients, or other updates are communicated. Exactly what leaves the client depends on the federated-learning protocol.
How It Actually Works
The server starts with a global model.
A subset of clients receives the current model. Real systems usually do not train on every possible client in every round.
# On your phone
my_texts = ["hey whats up", "running late", "lol"]
improved_model = train(base_model, my_texts)Clients train locally and produce updates.
The server aggregates updates. A common starting point is weighted averaging, but real federated optimization can be more sophisticated.
The process repeats. Clients can drop out, have different amounts of data, and produce updates from very different local distributions.
# Conceptual aggregation
server_model = aggregate(client_updates)Your raw texts may stay on your phone, but the server still receives information derived from local training. That distinction matters for privacy.
At scale, the system can improve a shared model from many participants without directly centralizing every participant’s raw dataset.
Real-World Federated Learning Examples
Google Gboard: Learns your typing habits and slang without uploading your texts
Apple Siri: Improves voice recognition while keeping your voice on your iPhone
Banking: Detects fraud across banks without banks sharing customer data
But Wait… Is It Really Private?
Federated does not automatically mean private. Gradients or model updates can sometimes reveal information about the training data, and malicious participants can also try to infer or poison the model.
Two important tools are often combined with federated learning, but they solve different problems:
Secure aggregation helps the server learn an aggregate of many client updates without seeing each individual update in plaintext.
Differential privacy limits how much the final output can reveal about any one participant, usually by clipping contributions and adding carefully calibrated noise.
# Conceptual differential-privacy sketch
update = train_on_local_data()
clipped = clip(update)
private_update = clipped + calibrated_noise()
send(private_update)Privacy is a system property, not a checkbox. The threat model, number of participants, aggregation protocol, privacy budget, logging, metadata, and who controls the server all matter.
The Challenges (Why isn’t every company using this?)
1. Your Phone Is Now a Data Center
FL happens on your device. It’s efficient, but it still uses battery and CPU.
# This runs ON YOUR DEVICE at 3am
model.train(your_data, epochs=10) # RIP battery2. Not Everyone Has the latest iPhone 1000 XR blazing pro max
Clients have different CPUs, batteries, bandwidth, and availability.
Some clients disappear halfway through a round.
Some users have thousands of examples while others have only a few.
Local datasets are often non-IID: one user’s data distribution can look very different from another’s.
3. Malicious Updates
# Evil user
fake_update = mess_up_model_on_purpose()
send(fake_update) # Try to poison the modelDefenses include robust aggregation, anomaly detection, clipping, authentication, and other protocol-specific controls, but poisoning and backdoor attacks remain active research problems.
4. Communication and Coordination Costs
Model updates can be large and rounds may require many participants.
Bandwidth, client availability, retries, compression, and synchronization all affect training speed.
Federated training can require many communication rounds even when local computation is cheap.
The Future Is Federated
Federated learning is especially interesting for settings where useful training data is naturally distributed and centralizing it is undesirable or impractical:
Healthcare organizations collaborating without pooling every raw patient record into one database
Financial institutions learning shared patterns while keeping transaction datasets under local control
On-device personalization where raw interaction data can remain on the device
Industrial or edge systems learning across many separate sites
Those are promising use cases, not automatic guarantees. Whether federated learning is actually the right design depends on privacy requirements, trust boundaries, data distribution, networking, compute, and model quality.
It is harder to operate than ordinary centralized training: clients disappear, data distributions differ, updates can be attacked, and communication is expensive.
Federated learning is one useful privacy- and governance-aware architecture, but it is not the only way to build private or responsible AI, and it still needs careful security and privacy engineering.
If you’re interested in learning more read this article:
If you want to keep learning
Machine learning explained — start with the fundamentals behind how models learn from data before distributing that training across devices.
Data cleaning explained — because privacy-preserving training still needs useful, consistent data.
AI agents explained — how developers combine LLMs with tools, memory, and agent loops.
How AI is changing programming — what AI coding tools are changing about developer workflows and skills.
5 system design resources — useful background for distributed systems, data, and architecture.
Thanks for the feedback!
Thanks to everyone who submitted!
Factorial of Factorials
Create a function that takes an integer n and returns the factorial of factorials. See below examples for a better understanding:
Examples
fact_of_fact(4)
output = 288
// 4! * 3! * 2! * 1! = 288
fact_of_fact(5)
output = 34560
fact_of_fact(6)
output = 24883200How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
