Welcome back to the Deep Dive, where we take complex documentation project notes
Download transcript (.srt)
0:00
0:04
0:06
0:09
0:10
0:11
0:12
0:16
0:21
0:22
0:23
0:26
0:29
0:32
0:33
0:37
0:38
0:42
0:46
0:47
0:51
0:55
0:58
1:01
1:02
1:06
1:09
1:13
1:14
1:15
1:16
1:21
1:23
1:24
1:25
1:27
1:28
1:29
1:33
1:38
1:38
1:40
1:42
1:44
1:48
1:49
1:50
1:51
1:55
1:59
2:01
2:04
2:05
2:06
2:07
2:08
2:13
2:14
2:18
2:20
2:25
2:26
2:28
2:31
2:32
2:33
2:39
2:40
2:41
2:46
2:48
2:49
2:52
2:56
2:57
2:59
3:00
3:01
3:04
3:07
3:08
3:11
3:12
3:18
3:19
3:25
3:26
3:29
3:32
3:33
3:37
3:42
3:43
3:48
3:48
3:50
3:51
3:53
3:57
4:02
4:04
4:05
4:06
4:07
4:10
4:12
4:13
4:17
4:18
4:19
4:24
4:25
4:26
4:29
4:31
4:32
4:34
4:36
4:42
4:44
4:45
4:49
4:51
4:53
4:57
4:57
4:58
4:59
5:00
5:01
5:02
5:04
5:07
5:10
5:13
5:15
5:16
5:17
5:22
5:22
5:23
5:28
5:28
5:30
5:33
5:34
5:38
5:41
5:42
5:43
5:44
5:49
5:50
5:52
5:53
5:54
5:55
6:00
6:00
6:02
6:03
6:04
6:07
6:09
6:10
6:14
6:15
6:19
6:20
6:21
6:23
6:29
6:29
6:34
6:36
6:42
6:43
6:46
6:49
6:53
6:53
6:57
6:57
6:59
7:02
7:03
7:06
7:07
7:11
7:14
7:15
7:16
7:18
7:20
7:25
7:29
7:31
7:34
7:39
7:39
7:40
7:44
7:44
7:45
7:48
7:49
7:50
7:51
7:53
7:58
8:02
8:03
8:04
8:05
8:06
8:11
8:11
8:15
8:16
8:17
8:18
8:24
8:29
8:31
8:34
8:35
8:39
8:45
8:48
8:49
8:53
8:56
8:57
8:58
9:00
9:03
9:04
9:09
9:10
9:11
9:13
9:17
9:18
9:21
9:22
9:25
9:26
9:28
9:33
9:34
9:39
9:44
9:47
9:52
9:52
9:56
9:57
10:00
10:01
10:03
10:07
10:08
10:10
10:13
10:14
10:17
10:20
10:21
10:26
10:26
10:29
10:31
10:35
10:36
10:40
10:40
10:44
10:46
10:49
10:51
10:55
10:56
10:58
11:02
11:05
11:10
11:11
11:13
11:15
11:18
11:22
11:22
11:24
11:25
11:26
11:31
11:32
11:36
11:39
11:44
11:45
11:49
11:50
11:54
11:54
11:55
11:56
11:57
11:58
12:02
12:02
12:06
12:07
12:12
12:17
12:18
12:20
12:23
12:24
12:28
12:29
12:31
12:37
12:41
12:42
12:48
12:48
12:51
12:55
12:56
13:01
13:02
13:04
13:08
13:09
13:11
13:15
13:15
and really
try to distill them into pure actionable knowledge.
For the learner.
Right.
Exactly.
And today, we are peering behind the curtain of modern digital communication.
We're exploring a real challenger to the status quo, a project called SAMA.
SAMA.
Yeah.
It stands for the Simple But Advanced Messaging Alternative Chat Server.
And if you've been tracking modern tech, you know the messaging backbone.
We all rely on is, well, it's due for an upgrade.
It definitely is.
So our mission today is to give you a fast, thorough, and most importantly, a
simple explanation
of what SAMA is, why it exists, and where it aims to fit in.
We want you to walk away understanding the strategic difference it's trying to make.
Right.
But before we jump in, a huge thank you to our supporter, Safe Server.
Safe Server handles the hosting for exactly this kind of innovative software.
And they're all about supporting your digital transformation.
Which is so important for these kinds of projects.
Absolutely.
So if you need reliable hosting for your next big idea, you can find more info at
www.safeserver.de.
And just to set the stage, our deep dive today, it's all based on the primary
source material.
Right.
We're going straight to the source.
The project's documentation, its GitHub repository, and the insights from the
creators themselves,
SAMA Communications.
And that context is so crucial.
I mean, you look at the apps we use every day.
They're beautiful.
They're modern.
But the underlying protocols, they can sometimes be decades behind.
So when something like SAMA comes along, it really signals this collective feeling
that
the old ways are straining under modern demands.
That's a great way to put it.
So our goal here is to figure out that contradiction right in the name.
We need to understand the simple part versus the advanced part.
Okay.
Let's unpack this.
Maybe let's start with the advanced part first.
What exactly is SAMA at its core, architecturally speaking?
So SAMA is a full open source chat server system.
It manages user accounts.
It handles message delivery, facilitates all the real time connections.
It's not just a library.
It's the whole engine.
The whole engine room.
Exactly.
And very importantly, it's distributed under the GPL 3.0 license.
Okay.
So for our listener, what does GPL 3.0 mean in simple terms?
It's really the ultimate commitment to openness.
It means the code base will always be open, transparent, and free for anyone to use
and
modify as long as they keep those same freedoms going.
Which is foundational if you want to become a new standard, right?
Absolutely.
Now let's talk about that engine.
The sources highlight a very specific technology choice that really backs up that
advanced
claim.
The server is powered by uwebsockets.js.
That's a choice that immediately tells a technical story, doesn't it?
It really does.
It's a story about optimization and pure speed.
Most chat servers built on Node.js, which is where the 100% JavaScript stack comes
in,
they'd use something like Express with socket.io.
Which are fine.
They're reliable.
They're reliable, but they carry a lot of memory overhead.
So why uwebsockets.js instead?
What's the trade-off?
It's designed from the ground up for maximum concurrency and a minimal memory
footprint,
while Express or socket.io might use hundreds of megs of memory for a few thousand
connections.
Uwebsockets.js can handle, say, 10,000 simultaneous connections on just a fraction
of that memory.
It's written to be lean and fast right at the operating system level.
So it's perfect for something like real-time messaging, where speed is everything.
Just ideal.
So the advanced part isn't necessarily a super complex feature set.
It's more of an absolute focus on performance and efficiency from the ground up.
Precisely.
They've chosen a lean, purpose-built engine, and the fact that it's 100% JavaScript
also
speaks to the simple part.
Oh, so?
Well, JavaScript is the language of the web.
It makes the codebase accessible to this huge global pool of developers.
It just facilitates easier contributions, easier audits, much broader adoption than
if it were written in a more niche language.
That makes sense.
Yeah.
Okay.
Let's look at traction, because a great engine is useless if no one's driving it.
And the sources give us some concrete numbers.
Yeah.
And what's fascinating is that the foundation is sound, and a community is clearly
forming
around it.
It's maintained by SAMA Communications on GitHub, and it already has 141 stars and
11
forks.
Which, for a new protocol alternative, that's not nothing.
That shows real early engagement.
It shows commitment.
This isn't just vaporware.
And the development schedule seems to back that up.
The latest release we saw was .35.0 from October 21, 2025.
That was their 19th total release.
19 releases.
In a relatively short time, that shows they are actively iterating.
They're building stability.
That continuous release schedule is the proof, right?
If you want people to migrate to your protocol, you have to show you're serious
about maintaining
it.
You have to.
And they are.
OK.
So they have the engine the community is watching.
But a fast engine doesn't matter if you're building a car nobody asked for.
And this is where it gets really interesting for me.
What pain point is SAMMA trying to solve?
The source material makes a very direct comparison, almost a challenge, to a
specific, long-established
protocol.
Yes.
The primary motivation here is to provide an alternative to the XMPP messaging
protocol.
XMPP.
The creators themselves note that XMPP is, and I'm quoting here, the only
widespread
standard these days.
So they're positioning SAMMA as the modern competitor.
XMPP is huge.
A lot of our listeners probably know it by its old name, Jabber.
It's been the backbone for open instant messaging for decades.
It's open.
It's flexible.
But what's the issue with it in 2025?
If you connect it to the bigger picture, the issue is really its history, its
structure.
XMPP is fundamentally based on XML.
Extensible Markup Language.
Exactly.
And XML is verbose.
It uses lots of tags, lots of structure to define data, and all that verbosity just
translates
into significant data overhead.
Okay.
Data overhead.
So what does that actually feel like for a user or for a server admin?
It translates directly to inefficiency.
I mean, think of it this way.
XMPP is like sending a formal letter every single time you send a chat message.
Okay.
The letter has the address, the header, the body, the signature, even if the body
is just
hello.
So all that extra data requires more bandwidth.
More bandwidth, higher latency, and most critically for mobile users, it just
drains battery life
faster because the device has to constantly process and parse that complex XML.
That is a fantastic analogy.
So where XMPP is heavy and verbose, Sama, using modern web sockets, is, well, the
implication
is that it's lean, probably using something closer to JSON.
Exactly, or maybe an even lighter binary format.
Sama's whole existence is driven by this need for a new protocol that's optimized
for speed
and reduced overhead, something modern enough for the millions of rapid lightweight
messages
that define chat today.
So their statement that Sama's protocol is different from others is really a
declaration
that they're abandoning XML for something much more efficient.
It is.
The motivation is protocol innovation, driven by performance.
It's not just a new app, it's a whole new foundation designed to make messaging
lighter
and faster.
They're trying to solve the problem of legacy bloat.
That's the key takeaway.
XMPP's strength, its flexibility, became its weakness in the mobile first era.
Sama is engineering a system for that exact environment.
So we know why they built it, we know the tech stack.
Now, how can a learner actually explore this?
If someone wants to see this new protocol in action, what does the Sama ecosystem
offer
them?
Well, this is critical because the developers have built out a whole stack to
legitimize
the protocol.
They haven't just released a server, they've released client applications so you
can use
it immediately.
Tell us about those clients.
There are two main clients linked in the docs.
First, a standard front-end web app available on GitHub for your browser.
And second, and this is a really smart strategic move, they have a Flutter app
client also
on GitHub.
Okay.
Why is Flutter a smart move here?
Well, Flutter is Google's UI toolkit, and it lets you build high-quality, natively
compiled
apps for mobile, web, and desktop from a single code base.
Right.
So you write it once, it runs everywhere.
Exactly.
By providing a Flutter client, Sama is immediately usable across Android and iOS.
It just doubles down on that commitment to modern standards and wide accessibility.
That dramatically lowers the barrier to entry.
And you don't even need to set up the server yourself to get started, do you?
Correct.
If someone just wants to test the full stack, they offer a public cloud demo.
You can test the entire Sama environment right now at https.app.samacloud.io.
So that's the easiest entry point for any beginner.
By far.
Now, a new protocol like this lives or dies by its documentation.
If developers can't easily integrate it, it just won't gain traction no matter how
fast
it is.
How robust is Sama's documentation?
It appears to be very thorough, which really supports that simple part of their
mission.
The main API reference is at https.samacloud.io, but what really stands out to me
is how they've
structured the functionality.
Go a little deeper on that structure.
Well, when you look at XMPP, key features like push notifications or end-to-end
encryption,
they often require these complex add-on specifications.
They're called XEPs.
XMPP extension protocols.
Right?
And it adds a ton of complexity for developers.
Sama, on the other hand, includes these modern necessities as built-in dedicated
APIs.
So you see APIs for things like users, conversations, messages, activities.
And critically, a robust push notifications API and an address book API.
So the simple part of the name, it's about the developer experience.
They're taking these core, complex functions and providing clean, modern endpoints
for
them instead of making devs cobble together older extensions.
That's it, exactly.
They're streamlining the implementation of features that are absolutely essential
for
any modern messaging app.
And beyond the API docs, they have articles on Medium, like Introducing Sama, that
give
you the whole philosophy behind it.
We always emphasize that knowledge is best when contributed and open source
projects
rely on that community input to evolve.
How accessible are the creators for feedback?
They're very explicit about it.
They welcome any thoughts, feedback, and they ask users to create a GitHub issue
for technical
support or just general ideas.
That's standard, good open source practice.
But sometimes you need a less formal channel, right, to just ask a quick question?
They have that too.
For general discussion and immediate help, they have their medium presence for the
big
ideas and, most importantly, a dedicated Discord server.
You can spot it by the little chat bubble emoji.
So they have the formal and the informal channels covered.
A mix, yeah.
Separate GitHub issues for the server, the web client, and the Flutter client, and
then
the Discord for community building.
It's a great setup to attract both core contributors and curious beginners.
This does bring us to a point of friction, though.
Why should a developer invest time in a project with 141 stars when XMPP has
decades of proven
infrastructure?
And that's the challenge for every disrupter, isn't it?
The answer has to be in the technical promise.
Legacy infrastructure requires constant effort to maintain, precisely because of
that XML
overhead and XEP complexity.
It's a bet on the future.
It is.
And while Sama is young, its use of uwebsockets.js and a modern protocol offers a
clear path
toward greater efficiency and lower operating costs in the long run.
It's a bet on future performance outweighing legacy familiarity.
The classic startup dilemma, trade established reliability for bleeding edge
efficiency.
And I think the commitment they're showing with 19 releases and all this
documentation,
it suggests they're building Sama to have a viable long-term protocol, not just a
quick
proof of concept.
Okay.
Let's bring it all together.
Let's do it.
So to synthesize this for you, Sama is the simple but advanced messaging
alternative.
It's a modern, high-performance, open-source chat server.
Built entirely in JavaScript.
Entirely in JavaScript, using that rapid, low-memory uWebSockets.js engine.
Its primary goal is to provide a streamlined, efficient alternative to the verbose
XML-based
XMPP protocol.
And they've lowered the barrier to entry with a working public demo, clients for
Web and
Flutter and detailed APIs that simplify things like push notifications.
That's the whole picture.
It's a perfect encapsulation.
And here is a final provocative thought for you, the listener, to mull over.
XMPP succeeded because it was open and extensible, but in an era where every
millisecond and
every byte of data matters, can an open standard truly thrive today if it doesn't
prioritize
maximum efficiency first?
Or is the complexity of legacy systems just too ingrained to displace?
That is the question.
Check out the demo at app.samacloud.io and maybe you'll find the answer for
yourself.
Thank you so much for joining us for this deep dive into Sama.
We want to reiterate our appreciation for SafeServer's support in digital
transformation and for
hosting this type of cutting edge software.
You can learn more about their services at www.safeserver.de.
Until next time, keep learning and keep digging deeper.
Until next time, keep learning and keep digging deeper.