hpr-knowledge-base/hpr_transcripts/hpr3509.txt

Episode: 3509
Title: HPR3509: Linux Inlaws S01E46: The Matrix Project (Without Neo)
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3509/hpr3509.mp3
Transcribed: 2025-10-25 00:47:17

---

This is Haka Public Radio Episode 359 for first day the 13th of January 2022.
Today's show is entitled, Live XinLos S01446, The Matrix Project, without Leo Dot, and is part of the series Live XinLos, it is hosted by Monochrome, and is about 72 minutes long, and carries an explicit flag.
The summary is The Matrix Project, without Leo.
This is Linux in Laws, a podcast on topics around free and open source software, and is hosted contraband, communism, the revolution in general, and whatever fence is your tickle.
Please note that this and other episodes may contain strong language, offensive humor, and other certainly not politically correct language you have been warned.
Our parents insisted on this disclaimer. Happy Mom!
Thus, the content is not suitable for consumption in the workplace, especially when played back in an open plan office or similar environments.
Any minors under the age of 35 or any pets, including fluffy little killer bunnies, you trust the guide dog, a lesson speed, and QT rexes or other associated dinosaurs.
This is Linux in Laws, Season 1, Episode 47.
Martin, how are things?
Oh, things are fine, and then maybe have a special guest tonight?
Indeed, but before we go into this phase, Martin, why don't we bitch a little bit about the weather and break it as we usually do?
Well, why don't we bitch a little bit, but what's happening in Germany for a change?
We can! We can! Just go for it!
What's happening in Germany, tell me?
You see Martin, I don't get out much, so I wouldn't know.
So you live there?
Or is that some...
Yes, but this is not able to carry your apartment anymore.
Indeed, it's called COVID.
You may know yourself, Martin, I don't know.
We're all good over here, yeah, all sorted.
Okay, Brexit or not? Excellent.
Yep, yep.
Okay, and with our further, you are now that the bitching part is over, or has been dealt with?
I'm more than happy to introduce Neil Johnson.
Hello!
Good evening, but Martin, why don't I really shut up now and do you take it from here?
Well, I think we need to let Neil introduce himself, really?
Hello, well, I'm Neil.
I'm here representing the Matrix.org project, which is an open network to secure decentralized communication.
And really what we're trying to do is create this open standard for instant messaging.
Or sort of, we have a broader vision, but right now that's really where we're at.
And the whole sort of, I guess, key into this is if you think about, you know, maybe the apps that you have on your phone today, and maybe you have five, six different messaging apps.
And they're all board gardens and they can't interoperate.
And so you have to remember who you talk to with, you know, you speak to this person with signal and this person on, I don't know, SMS even or telegram or whatever it will be.
And it's, okay, it's a bit of a, it's a bit of a bummer, maybe to have to remember all of that, but there's something really important underneath all of this, which is if you're, say you're using WhatsApp.
And you decide that you don't like some of the changes to terms of service of that, of that service.
You can't really leave or you can, but if you do, you leave your social graph behind.
And that's, that's not a great situation to be in.
And we think a matrix that'd be much better if it was a bit like email, where it's an open standard.
So if you don't like your provider, you can just move.
And in fact, if you own your own domain, you can just move completely transparently and no one even knows, but whatever the case, you can still carry on sending email and you can move from, from Gmail to hotmail to self hosted or, you know, whatever you want to do.
And with, with matrix, we kind of want to take the same kind of approach by applying it to messaging and, you know, taking a kind of more, you know, more modern approach to this because emails obviously 50 years old and fantastic technology had a huge impact in the world.
But what we're trying to do at matrix is I have the same sort of impact, but you know, maybe for the next 50 years and so.
And what that means today is.
We have this open standard. We have lots and lots of different implementations of the server technology and clients.
Everything is entering encrypted. There's no single point of control is entirely decentralized.
And there's an open federation. Anyone can.
And can spin up their own matrix server. No one can stop you.
All the code is patchy too licensed. So you can just run wild with this.
And that's really what we've been doing.
The in terms of actual people using this technology, it's quite a wide range. It's at one end, particularly in sort of open source communities world.
So we've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
We've got a lot of data.
I mean, could get a lot of data.
I mean, could get a lot of data.
Kind of interesting about that.
Kind of interesting about that is,
kind of interesting about that is,
kind of interesting about that is,
kind of interesting about that is,
kind of interesting about that is,
kind of interesting about that is,
kind of interesting about that is,
kind of interesting about that is,
kind of decent diets on architecture.
is actually really really good fit
is actually really really good fit for
is actually really good fit for creating a very,
d front organizations that have a lot of structures
an organizations that have a lot of structures in a lot of silos.
within one of styles.
makeup of products that we care,
experiment organization that we care,
scenarios that we care,
在iving our own.
That is keeping pace.
aware that we care,
No, before we go into the nitty-gritty details of the project,
maybe we can talk about a little bit about yourself.
Oh, sure.
Looking at your LinkedIn page,
I see that you're heading from Cambridge.
Why don't you tell us a little bit about
New Johns and where he comes from and what
actually took him to the project?
Um, okay, sure.
So, I mean, my background is as a, as an engineer.
And, you know, it was always, you know,
I think a lot of people in that discipline,
you know, you just always fascinated with taking things apart
and hopefully putting them back together again
in a way that they largely work how they sort of used to.
And so, that was where my studies took me
and I was spending a lot of time around,
probably more about signal processing than anything else.
That was kind of my, my passion.
But I ended up working in a communications company.
This was sort of about 20 years ago now and it was this,
this cool technology called SMS and it was a sort of
not quite early days of SMS, but definitely
early enough where you could, you could still build
some quite interesting businesses around it.
And the reason I mentioned that company was,
I met a whole bunch of people who I would later
work with on the Matrix project.
So, we were always talking about communications
and we were always talking about open standards
and one particular part of the company
that I wasn't so involved with,
they were building a lot of communication apps
for various different telecommunication companies.
And the problem was, they were building out an app
for this one and for this one and for this one
and they just thought it was awful
that they weren't actually talking to one another.
Because these were over the top services,
these weren't SMS chat apps.
And from all of this,
came this idea of why on earth is they're not,
is they're not an open standard for communications.
And so that was kind of sort of my,
my sort of route within this.
And the Matrix project,
it's got a wonderful community.
But in the very early days of Matrix,
we formed a company,
now called Element,
which was really just designed to hire the core team
from Matrix.
So we could continue to build out the protocol.
Now, I was sort of
off doing different things by that point
and working on all sorts of other
weird and wonderful technologies.
But then I rejoined Element
and joined the rest of the gang.
And it was kind of a bit of a reunion
in that sense, a lot of familiar faces.
But we still had this same core passion of
the way that people communicate is
it's so important and so personal.
And we just think we need to make this as user centric
as we possibly can.
And that means choice and it means freedom.
And we just didn't think anybody was really
doing that or doing that in a way
that was going to really cut, cut, cut
in and become mainstream.
There were some projects on
and still still running
to try and solve similar issues kind of problems.
So that's a little bit of sort of
how I came to get involved in this sort of stuff.
It's also a super cool
problem from a technical perspective.
How do you build any of these services
in a decentralized way where there's no
central point of control and order?
There's some fascinating stuff there.
So I'm a member of the matrix core team,
but I also work for Element,
this company that was originally there
to hire the matrix core team.
Our community has grown massively and massively
and now we have plenty of different companies
contributing to it and an even larger group of
open-source enthusiasts just helping us
make this better and better every day.
But yeah, that's my day job.
It's also kind of my hobby, so it's a nice mix.
Okay, let's go.
I mean, we've run it ourselves to communicate
with our own installation, as you mentioned.
It's something that is very easy to do and set up.
And I don't want to touch upon the sort of
the federated element, right?
That's something that okay,
matrix as a foundation is a very strong
in the what's called the manifesto,
that it's not a centralized communication system.
And however, in our instance,
I'm running a completely isolated version of matrix
with the users that I control and so on.
So there is an option to do that as well,
right, if you choose to do so.
But it's maybe for the users that do use
the what's happens in the other,
let's say communication technologies out there.
What is the real reason for going for a decentralized approach?
Is that something that is really based on
not having a control?
Is it kind of, you know,
are we thinking about a communist principle here?
We'd like to sort of add to that a little bit.
I mean, I'd say that there's a very strong
political undercurrent with matrix.
I don't think that I've ever heard anyone talk about it
in those sorts of terms.
I think the idea of making this decentralized was really about resilience.
And it being very, very difficult
to keep a network sort of truly open
when you have points of centralization,
because someone has to control those.
I mean, we even find that even with the network being decentralized as it is,
you know, where there are nodes that are significantly bigger
than other nodes on the network,
even that can have a kind of distorting effect.
And so, for instance, the matrix.org node
that we try and maintain and run.
That's for the good of the community,
but at the same time, like over time,
we'd massively prefer it,
that it wasn't the biggest node on the network,
and it was just one of the sort of visually in others.
So it's really this sort of idea of kind of choice and freedom,
for your technology social needs.
And if somebody wants to do this in a closed federation,
then that's absolutely fine.
And where we want to get to, at some point in the future,
is that the value of being part of that open federation
is such that most people would want to go that way.
But there's also some different use cases
in this technology, and no specific reason
why you have to join that federation.
Okay, interesting.
Now, I thought it was so your original reason was really about the.
Did he, having a non-central communications point
to for resilience rather than, let's say,
the political reasons or order?
The opposite.
I mean, I think there is a political angle in as much as
it's very hard to envisage how this sort of system could remain
truly open if you have points of centralization within it.
So if you genuinely, if your goal is to be an open standard
that anybody could join, then this decentralization piece is really important to that.
Because the moment you don't have that and you have reliance on a much smaller group of parties,
then that group, of course, has a lot of control over how the,
how that technology might develop over time or might move over time.
So I think there is a sort of political element in that regard.
But I wouldn't say that the matrix project is sort of aligned with a specific broader political movement.
Not even a little bit of communism in there.
Surely disappointed.
Joking.
No, near a fair question.
When I take a look at the, just tacking on this, on this, on this, on this,
on this Federation approach, a little bit longer,
about two thirds are reckoned of the community events in Germany including
coming to a new struggle, Frostcon and other open source, an open source community events
now have switched over to metrics as their main means of communication before, during and after
the event. Thanks to COVID, these events have been switched to an online mode for the last one
and a half years. The coming to a new struggle taking place this year probably being the best example.
What I really liked about the whole thing is, and you got this bottom with the comparison to
email, when you take a close look at it, email is really a federated system because you set up
a mail transfer agent and then these MTAs talk to each other based on the domain specification,
similar to metrics, but metrics allows you to do much more things. This is the reason why
full disclosure, we have been using SNAPs instance, which is from a complete mistake,
the reference implementation of the metrics of the Metis protocol, since we ever set up this
podcast more than one and a half years ago. Oh cool, brilliant. And this whole federation thing
wasn't in the focus area when we first decided upon a communication show between the two of us
because Martin is living in the UK, I'm living in Germany, and we use
element in addition to SNAPs all the time to communicate. During the shows, after the shows,
before the shows, we do our synchronization slots over SNAPs and all the rest of it.
So we have found this piece of technology very valuable, even in a non-federated fashion.
Why don't we change that a little bit and why don't you speak a little bit about the
technology behind SNAPs and the element if that's okay with you? Sure, sure, absolutely. So
so SNAPs is a Python app. It's got the same history, I think, of pretty much any
any piece of software that sort of gains some sort of traction in that. When we came up with the idea
of doing this as an open standard, what we really didn't want to have happen was that it was kind
of you write the standard and then further down the line you go about trying to build some
implementations. We wanted this to be implementation led. And to this day, when you want to make a
proposal to augment the matrix spec, anyone can do that, but you have to show up with a working
implementation. And so that first working implementation was SNAPs and we put it out there.
All of a sudden, we sort of realized that goodness gracious room production with what was
originally a proof of concept. Yes. Yeah, yeah. And so then we had a lot of work to do
because you've got to go and you've got to go and sort of move this along. You've got to
involve the architecture so that it can be much more resilient and scalable and all these kind
of good things. And you've got to do it while you're seeing lots and lots and lots of new users
joining the whole time. So your your landscape is changing. And also the topology of the network
is changing rapidly as lots of new nodes join. So that's where we've that's where we've been with
SNAPs. It's uses twisted for its networking. Aside from that, we were pretty sort of framework
light in terms of what's there. And postgres as a data store, we've recently taken on Redis for
some message passing and I think we'll start using it more and more for caching as well.
The thing that is making me chuckle about the SNAPs team is they're all secretly desperate
to write more rust. And so the structure of it means I could imagine some services getting split
out and as soon as we do that, you know, it may be maybe the language isn't quite so important.
So we might find that we want to go for a rust implementation for some of the more
performance sensitive pieces. Oh, this is very this is very interesting. Maybe we can
shed some more light on the language choice initially why Python and why you are now introducing
a mixture of our service corrective for SNAPs of rust and Python because
fullisters, you're not the only project doing that. Oh, yeah. I mean, Python initially because
you know, it's a great language prototyping. I think it was I think it was as far as that,
you know, in 2014, we didn't we didn't really know that this could be successful or not,
and Python seemed a pretty good language choice at that moment. So that I think was the
the reason I wasn't working on the project at that time, but as far as I'm aware, that's
how it's the reason. I mean, I remember them talking about it. And it was like, oh, yeah,
they're just prototyping in Python. Sure. That seems like a reasonable call.
I mean, I should also mention that there are multiple home server implementations.
There is a dendrite, which is what we would describe as the sort of a second generation
server implementation. That's written in Go. And the choice language choice there was really that,
you know, Go is there for systems programming, and it's a pretty good match for
the sort of things you need to do to run a communication system. And you know, particularly things
around concurrency, it's very well set up for that. But there are also other community
derived implementations, I think, really the most promising being conduit, which is another
rust implementation. And they all have slightly different design goals as well at this point.
But for instance, the dendrite implementation is backing a lot of the matrix peer-to-peer demos.
Actually, I shouldn't call them demos anymore. They're really starting to mature. But
if you're really on board with this idea of decentralization and the protocol supports that,
then there's really no reason why you can't just run the server on your phone. And we're proving
that right now, and we're using dendrite to develop that project. And of course, it has a much
smaller resource usage footprint than something like synapse, and it's easier to run it natively
on various devices. So there's also different approaches flying around. What's been interesting
to watch the development of synapse and dendrite is that a lot of the ideas that underpin the
architecture of dendrite were in response to things we learned from synapse. But then gradually,
gradually, gradually, we've been evolving synapse towards that same kind of architectural set of patterns.
So that's the sort of whistle stock tour of the various technologies. I mean, talking about dendrite
briefly, you can run that as a monolith, or you can run that in a highly distributed manner,
and that uses Kafka for message passing between the various services. And again, it's backed
back to the Perchgres as well. I don't know where you'd like me to go.
Yeah, now I want to pick up on something you started us with is that you had a number of your
developers wanting to pick up the recipes. I mean, there's obviously a number of reasons why I
could be one if they want to, they're like, brust in the programming risk. But from a pure
technical perspective, is there a reason that some of the parts that can require a more
performing language? Is that the reason why they want to do that? Yeah, it's exactly that.
Particularly, what we would call state resolution of a particular room, that can become quite a
heavy operation. When you have a room that has multiple servers, maybe hundreds, maybe thousands of
independent servers, or participating in that room, and they all need to independently arrive at
the same conclusion of what's actually happening in that room. And you could imagine that that
problem could become quite complex. Once you start introducing network failures, latency,
various nodes just disappearing. And so it not being clear where to get your information from.
And all of that combined can create quite considerable load. And of course, you can architect
this in a way that scales horizontally. But still, your straight line speed is also important,
and we've definitely seen some value in that. My general thought here is that if you get your
architecture right, then your language width can complement that, and you really should just
focus on, focus on architecture. But at some level, Ross is there as a systems programming language,
goes there for the same sort of reasons. And they're very good. There's a very good mapping
between that kind of mentality and the sort of problems that they're designed to solve, and
building out communication systems. Interesting perspective there. Full disclosure,
I had a couple of challenges with element. That's the reason why I decided to pull them into
source code and compounding myself last weekend. And that's exactly the point in time when I discovered
element as an at least, what is it? 1733 1734 actually needs rust as a dependency locally installed.
That means, if I got this correct, you are thinking about introducing rust just in
apps, but also are using already rust on the client side. Oh, yeah, on the desktop app.
That's for client side message search. And the reason was performance?
Actually, the reason I think was the chat who has been building out
search for us. He is the lead developer on the matrix rust SDK.
So that's his language of choice. And so it was quicker and easier for him to reuse
some of the work that he had done there in this context. I suspect there probably is also
an argument for performance, but as far as I'm aware, the inertia around the project,
meant that rust was the obvious choice. I mean, the desktop app is essentially a mixture of a
JavaScript framework called electron from a completely mistaken and JavaScript and some other
quick technology components, right? And you're not concerned about the technical depth you're
introducing with that zoo? Well, I mean, firstly, we're trying to move. This is of course a
challenging question. Yeah, no, no, no, no, I understand. I mean, using electron is really a
pragmatic decision. So we build it out equally for web and the desktop client, an electron
allows us to then provide it as a native desktop client, which also then from a packaging point
of view allows us to do things like client sign search in rust. We don't have, and this is for
specifically for encrypted rooms. If you're using the web client, this doesn't support
client-side search. And instead, it's all server-side search. So you only get search for
unencrypted rooms. So like maybe public rooms and that sort of thing. So with our search and
our cryptography infrastructure, in the bounds of that are very well defined. And as a result of
that, we were okay with the complexity for that that that's. So that's really the decision-making
process around it. But I will say going back to synapse one of my biggest concerns of adopting
rust and having a sort of hybrid kind of project is of course, it adds a lot of complexity to
packaging. You need developers who feel comfortable across multiple technologies. And so that definitely
does add complexity and you need to think about that very, very carefully before you really
really commit. So I think where we're at at the moment is there's a lot of enthusiasm for it,
but we haven't we haven't all sort of looked at us each other and looked ourselves in the
eyes and said, are we actually going to do this? That's still very much a for discussion point,
because it would be a significant burden to take on. But we think that there could also be some
really great advantages with it too. Right, right. Yeah, I want to pick up on something else
you mentioned as well is the use of Postgres of Redis. Clearly, I run it myself on
with Postgres being a longstanding Postgres fan, but is the introduction of Redis something that
you notice when you are running your own matrix.org instance is how many users do you have on
there? And is that is using Postgres there to reason for introducing betters or other reasons
for doing that? Oh, so the reason to we use Redis for message passing between processes. So
because it's Python, we've got our main process, you've got your global interpreter lock.
So we actually end up spinning up a bunch of other processes and they need to talk to each other
somehow. And initially we ended up with a kind of homegrown PCP-orientated system that
was fine when we first started out, but building that kind of technology in a really, really robust
resilient way is a hard problem. And lots of people have already spent a lot of time fixing that
problem and the folks at Redis have certainly done that. So really this was a means to help us
improve the reliability and resilience of message passing within Synapse itself. That
was the reason that we adopted it. So if you're running Synapse without worker processes,
then Redis doesn't really get you very much or anything at all. But if you are running workers,
and I think, I mean, matrix doesn't scale or matrix servers don't scale with a number of users.
It's more the complexity of the rooms that they participate in. But the moment you start joining,
you know, multiple rooms with hundreds of people in them, then you may wish to configure it
with worker processes. So matrix to org is the largest node on the open federation,
and that's the one that's really helped us understand how to scale the Synapse.
It's always pushing the boundaries of what everyone else needs to do. So by the time everyone
else catches up, then hopefully we've dealt with some of those problems before they get there.
So I guess that's the, that's that's our sort of landscape, I suppose.
I mean, in terms of the user numbers, I mean, if there is an awful lot, and it depends a lot how
you count it, because matrix not only is its own protocol, it's also written in a way that
means that it's easy to interoperate. And so we interoperate with lots of other networks,
and you sometimes that's really easy, like where it's where there are other open protocols like
IRC or XMPP. Sometimes it's a little bit trickier, like bridging into maybe slack or
you know, WhatsApp or something like that. But those users are then also matrix users on the
matrix side, and then of course sort of native for whatever protocol they're using on their side.
So it's quite hard to give sort of concrete numbers. But I mean, let's say in orders of magnitude,
let's say we're talking millions. And yeah, when you do that, you need you need to separate out
your processes, and we found Redis was a really great way to achieve it. That said, we're still
just running it across three different VMs. So we're not seeing this as sort of super-computer
kind of territory. Sorry, excuse me. But yeah, Redis has definitely enabled us to scale that message
passing base. Interesting, because Martin and myself are like, oh, at least you speak Redis
very positively while we're asking, oh, why am I asking, why Martin asked that question.
You touched on a very interesting perspective. Bridges. If I take a look at about 50% of my telegram
groups that I'm in, all of them actually have matrix bridges, which I find more than fascinating,
because that tells a lot about the community's effort to make things work even outside the
federated ecosystem called matrix. Yeah, so the bridge is really interesting because it's probably
the area that is the sort of gateway for if you forgive the pun of how people really get into
matrix, because the possibilities, it really opens it, it's right there in front of you. You can
just talk to your friends on WhatsApp from your matrix client, and you can also talk to your
friends on Slack and so on and so forth. And I guess the downside with bridges is you're always
limited to the lowest common denominator between the two protocols. But there's so much
community effort, core team effort to try and make those bridges just work as well as they
possibly can. It makes this really vibrant ecosystem outside of the confines of matrix,
which is just really, really exciting. More than interesting. Okay, let's take a step back,
given the success or track record of matrix. Where do you see this project going? Not just in terms
of technical progress, but also painting the bigger picture here. What my domination?
Well, I think the thing that's important to realize with matrix is that while today,
the primary use case is for chat, but all it really is is a means to pass about arbitrary data
across the internet in real time. And so you can just see it as a sort of very generic messaging
there for the internet. I think that's sort of a long term where we think this technology will
will sort of add most value. And wherever you wish to share information and that real-time
component is important to you, then matrix ought to be able to support that use case.
So in the sort of relatively short term, I guess this means things like, you know,
you could do forum software, you could do collaborative documents. So like a Google Docs clone,
we have somebody working on that project right now at Element, just as a sort of R&D project.
You could do, you could implement, you know, services like Twitter in matrix.
And there's a sort of offshoot project called Blue Sky that's sort of doing this actually that.
So these are the sorts of ways that we'd love to see matrix evolve. You know,
obviously we would like, we think that an open standard is the right way for
instant messaging technology to exist and to be in. So we'd like to see that grow and grow and grow.
We'd like to see the ability to bridge into other services and to interoperate,
just become sort of the norm and the kind of expectation. So that anyone can talk to anyone who
chooses to and you know, as a user, you obviously have a lot of control of your own experience.
So, you know, you can choose who you talk to. But then broader than that, yeah, it's this idea of
exchanging data in real time across the internet and just basically creating that layer,
which doesn't really exist fully today for anyone to use.
Okay, got it. Yeah, no, it, I mean, what sort of struck me when first started using matrixes
that so it's very much aimed at I.M, right? And lots of the other platforms are, you know,
looking at audio and video and screen sharing and all kinds of things.
Are you, I mean, looking at some of the things you put out on your blog,
is that something that you can see happening with with my tricks or is there?
Oh, yeah, absolutely. So I just, I didn't touch on that at all, did I?
And also virtual reality is a sort of very interesting direction and case for us. We think
this would be a good way to sort of communicate in that kind of setup. But, you know, as part of,
you know, if you're using a collaboration app like, like element, you know, it's partly chat,
but you care about voice, you care about video. And we feel that we've got to invest in those,
in those sorts of areas as well, or, or, you know, within, within that app. It's got to be
end-to-end encrypted because, you know, that's, that's our bag. And so actually, earlier today,
I got to use our prototype of a sort of video conference, end-to-end encrypted video conference.
I mean, it, because you're not compositing server-side, you know, you really can't have too many
streams all at once, but we had it working pretty well with six or seven. And, you know, we just
see this as a sort of core part of what we need to, what we need to do. The background of the core
team, including myself actually, was building out video telephony codex. And so this is always an
area that we kind of wanted to return to. And what we, what we discovered, particularly over the
last couple of years, is there's this enormous need not only for chat, but also for voice and video.
And we better make sure that the voice and video support we have in element just works really,
really well. So that's what we're doing, I guess, short-ish term. And then, you know, much, much longer term.
I mean, you know, I was sort of, I was sort of joking a little bit when I was talking about
virtuality, but we think that that could be really, really interesting for what we do.
There's all sorts of internet things, applications as well. Again, this isn't really an
area where we've sort of tried to directly support, but you can see that if you could make as
sufficiently lightweight and low-powered metrics implementation, then that could be really,
really valuable because of their inter-op and standards-based approach. So I think chats are core
that if you're making a collaboration app, you're also, you have to consider voice and video
as first-class citizens. Definitely, and I think of having recording
to that as well, by chance. Oh, goodness, yeah. Yeah. In fact, oh, God. You've just made our day
near. We are really looking forward to this version. Please keep us posted. Yeah, if it's really.
If it's not, I'm trying to remember if we've actually shipped it in the main mainstream release,
so it's just a developer channels. But voice recording is here. You can use it right now.
I'm joking. No, no killing. You didn't need to kill. I'm just really annoyed at myself for not
knowing the release date, but it's real soon now. I mean, seriously, just sent me a mail and I'm
going to include this into the show notes because this may be the grail that we've been looking for
for the last one and a half years. Okay, this would, I mean, hang on. Just while we're talking,
I'm looking at a document called Voice Message Release Plan, date of nine July this year.
Okay, I can tell you. What of the press? The team that you might be giving you a date, but
I'm going to very conservatively say you'll have it in September. How about that?
And this is part of synopsis then or how does it work? Can you share more light on the details?
I'm pretty sure we are the only people interested in this. No other people we care about this.
No, no, no, no, everyone's going to care about it.
All right, all right. Go ahead. Full disclosure. People you heard in your first,
Linux in last, the place to be, full disclosure, you get it here. The latest.
But you got it. The flaws yours. I just want to make sure we're talking about the same things.
This is a voice message recording. So I can, I don't want to type. I just say, hey, Chris,
great, great podcast. And then I send you that. Yes. What about what?
What about recording voice calls? Oh, right. That's what we're getting at.
Oh, now you're excited. Sorry.
What we would be looking for. Yes, that'd be the one. That would be the one. Yes, that would be
the killer feature. They would have saved us a lot. Indeed.
The reason we don't have that is because typically,
oh, no, all that is for conferences, like, like multiple people. And the way that that works
in Matrix today is we, we basically build around a, a service called Jitsy.
That series. Yeah, yeah. Oh, yeah. Okay.
And it really serves our purpose. I mean, we obviously want to do this natively ourselves.
But, but this is, this is what we use. And so we use that stack and we use Jibri to do the recordings.
Welcome to hell.
So, sorry for this closure. For one and a half years, not only within the context of this podcast,
also among other communities, I've tried and failed to use Jibri to record Jitsy sessions.
Let's put it more diplomatically with very limiting success.
This platform doesn't scale, I'm afraid. Even the public instances you get
are from from the project itself that put recordings into Dropbox are not really scalable.
All right. Just to, you know, back up my pals at Jitsy, I mean, we ran
for stem off the back of this. And we did all the recordings for that conference.
And all of the video report was, was, was based on, was based on Jitsy and Jibri.
I know this because I was part of this year for someone that was all virtual.
Right. I've yet to see the pull requests. But of the magic that they apparently didn't
the background to make this happen because they couldn't have used native Jitsy and Jibri.
This is my assumption. I hope I'm wrong.
I think, I think, I don't know for certain. I don't think we made any, any changes.
I think it was all configuration change. I think that's the case.
Again, this is magic. I really look forward to the nitty gritty slightly good details.
Because as I said, we have been tried, we have been trying it. We failed.
Okay. I know who to put you in touch with. Thank you.
I'm very happy. You're much appreciated. Okay.
I'm over to you. Enough morning.
Now, the, the, the other thing that you mentioned is briefly a moment ago was when you're
thinking about doing something with VR. And to be honest, VR chat is probably one of the
second highest use applications on things like steam and whatever. So what is the reasoning behind
to add something like that? Is that the reason because you are already a decentralized platform
that you want to give people the opportunity to use it in that way? Or is there just purely
adding more services to it? I mean, at the moment, we're right at a sort of blue sky stage with
this project. You know, we, we think that this could be extremely powerful. We think that,
you know, the promise of VR will, you know, is there? Perhaps we don't live in the reality of
that today. But you know, the work that we're doing here, we need, we need a mix of horizons.
You know, we need to do the things we need to do right now to to grow our immediate ecosystem.
We need to be looking a little bit ahead in the future. And so the sorts of projects that are
more futuristic are, well, actually, peer to peer is not that futuristic anymore, but it,
we used to think of it that way. VR very much is we've, we've just hired someone to work in this
area. And I'm actually, he's the person working on the full mesh video calling right now.
And once he does that, he'll sort of move, move more towards the VR use case. And then the other
area that I sort of touched on earlier was a sort of, you know, the application's beyond chat
generally. And, you know, could you do collaborative documents? Kind of things, who knows, who knows
if it can really make that work? We, we kind of, we're kind of optimistic on that. So it's not part
of a sort of immediate strategy that we can just bolt on and be able to say confidently the RFS
class citizen. It's much more that we just think that this is a really, really interesting avenue.
We think that the doing this as an open standard just offers so much value. And, you know,
as VR really starts to become more and more ingrained, then, you know, we want to be there. And we
want to have had already, you know, a good few years under our belt of trying to resolve these kind
of problems because, you know, it's going to be, you know, a challenge to get it, to get it really right.
So that, that's basically the thinking behind this.
I don't know, it's exciting stuff. It's still very much the domain of gamers right now. Is it
VR? Yeah, yeah, it is. And we just, you know, it seems like a reasonable assumption to think that
it will become probably pretty broader and more mainstream over time.
And yeah, we just kind of want to get ahead of that.
No, that makes perfect sense. Yeah, it's certainly something that I think is taking off quite a
bit, especially in the, in the COVID times. Right. And so completely changing, there's something a
little bit, I mean, the commercialization of, of with element, right? How do you see that
influence in the project, if at all? And what is the objective there is that purely enterprise
support for people who want to run it as an alternative to play a slack or something like that?
Is that the idea behind it? Yeah, I mean, element makes money in two ways. It's either through
basically support and, and services. And the other way is through hosting. So,
while anybody can run their own matrix stack, maybe they would like us to do it for them,
and we'd be happy to provide that. And that tends to be, you know, I don't want to say smaller,
but, you know, maybe, maybe like you were a few hundred or a thousand, a thousand people,
like that, that might be a good place to look at our hosting business. If you are a really
larger organization, maybe, maybe a government, and you have millions of people that you need on
the service, then maybe you also have requirements around needing to host it within your own
infrastructure and all that kind of stuff, then we will help achieve that and maintain that.
But the thing that's really interesting about all of this is the sort of organizations that
want to work with us are choosing us because this is an open source project, and they can be very
transparent. And what's more, the work that we do with them, it's not that we do something
completely bespoke for them, it's much more that they will look at our own map and say,
oh, hey, here's this really good feature, like video recording, say, you're going to do it,
but you're not going to do it anytime soon, we'd like to whack you down.
Audio recording, audio recording, sorry.
Would you accelerate this work if we were to fund it? And at which point we say yes.
And the thing that's really nice about that is then all of this work is available not just
to that customer, but also to the community at large. And that's a really important part of how we're
managing our commercial operations and deals because we think that compounding effect is
really, really important. So that's how the commercial angle is the landscape, I suppose.
And it's really for us then to sort of help these sorts of organizations figure out how to get
the most out of matrix. And of course, the more we do this with various different places,
they all have similar-ish kind of needs. So because we have this compounding effect of
as much as we possibly can getting into the mainstream community release,
it means we then already have these capabilities for others in the future.
And it's an interesting perspective on the way forward. Apart from the integration
of blockchain technologies and quantum computing, is there anything that we should touch upon
before we close off this show? That of course wasn't a joke. Yeah, no, I got that one.
What are the things that are important?
I think we've covered off the main things. I'd say one area that is very important for us right now
is that if you're building out an open network, you have to take trust and safety and abuse,
really, really seriously. And you've really got to build this in as a first class,
it doesn't from as early as you possibly can. And we've all seen other communication networks
or social media services that you have, I'm sure, now really dedicated, great teams working
this area, but it's very hard for them to have the impact and the effect that they need to be
having. And so this is an area where the matrix project is investing heavily in and trying to
build out tools, I guess for ourselves initially, and then to share those tools with so that any
any matrix community can reuse them. And the ethos here is to not only provide tools for
moderators of rooms and communities, but also to give tools to the user themselves. So
if you're navigating an open network, you should have the ability to say
say something about the experience that you're willing to have. Like maybe you're completely fine
to see the whole gory internet slash matrix ecosystem and you don't want any kind of filtering
on that. Or you say, well, there's certain things I'm just not interested in. Now I don't want to
I don't want to see as I use as I use matrix and you should you should have the control yourself to
to do that. So we're in early stages with some of these projects on the community tools where
a lot further down the line. And so I'll just call it out because it's it's an area that
you know any chat app, we just sort of feel like everyone should be talking about and trying
to share their experience and trying and trying to improve across the board. So it would be remiss
of me not to mention it and not to make it very clear how much time we're spending on
on these sorts of projects. And I reckon needless to say for anybody who wants to part of this
revolution, the place is on GitHub will be in the show notes as in the as in this naps reference
implementation as well as elements. Yeah, absolutely. I mean, you know, because of the nature of it,
if you look at our kit and you don't like it and you can do better, just go and write your own
client and write your own server and join the join the party. But absolutely, there are
I mean, we've got a wonderful community, lots of chat rooms that you can join to to get you going.
Full-time jobs, element of hiring, I think a few other companies in the ecosystem are hiring as well.
So yeah, if you like any of the sound of any of this, come and have a chat or reach me on
on Matrix. I'll share my handle and maybe put those in the notes as well.
Yes, please. Thank you, Neil. And people you're in for us, if you want to get rich and be part of
the revolution, element is the place to join apparently. And with that, it takes us right into
the boxes. The boxes is something called the Pixel of the Week. Essentially, it's something that we
all take our guests through in terms of something that has crossed your mind, Neil, that you think
within the last week or two is worth mentioning. Can't be anything. We rarely have government
comments or political views, but rather most of the server evolves around books, movies, whatever,
but anything goes. So if you want to share your political views, that's fine too.
Oh, goodness. Oh, you put me on the spot and my mind has gone absolutely blank.
There is an open source project called element. You might be tempted to mention.
But you don't have to. Neil, that's okay.
Well, hey, I'll tell you what. I mean, it is sort of political, but it's relevant to element.
I think that one of the things rattling through the EU right now that I was really fascinated to
hear was they're trying to figure out, oh, we've got these enormous tech companies and we don't
quite know what to do with them. And the old systems of the last century of how you deal with
monopolistic practice, like they just don't seem to be working. What are we going to do about this?
And there seems to be real consideration going over to the idea that if you're going to run a
server service like, like a Facebook or even a WhatsApp or an Instagram, then you need also
to provide a certain level of interoperability. So suddenly, this can't be a wall garden anymore.
And instead, this has to be something where others can interoperate and they can build their own
clients. And I was astonished to see this because it's an incredibly nuanced and thoughtful approach
to the problem. I think it's in very early stages from a legislation point of view and I don't
want to embarrass myself by misquoting the legislation, but I'm sure I can hunt it down.
And I just think that's not something that's happened in the last two weeks, but I do think it's
something I found utterly extraordinary and I was delighted to hear it.
Details, of course, people will be in the show notes. Martin, anything on your side with regards to
worth mentioning and boxes? Boxes? No, I don't have any boxes this week.
You don't have the boxes? No, it's a great nation of the UK, leaving the European Union as well.
Oh, that was quite some time ago, yes. But the ripple effects are so visible.
Okay, in that case, it's on to my boxes, actually, and it's an author, Quaterneprecit. Unfortunately,
he's no longer with us. And I'm not, I'm not mentioning in a particular books, but there's, of course,
the this world series, details, of course, will be in the show notes. So if you are looking for
something funny in a fantasy slash sci-fi context, with a little bit of a spin on the stories,
Tereprecit is the author to read. There's only about what? 20,747 books on this world alone. So
it'll be a jiffy over the weekend, no worries. Jokes aside, at least we'll be in the show notes.
And also heavily recommend the children's book that he wrote, that he wrote for children,
of course, of all ages. Martin, we do have feedback. We do, we do, we have two bits of feedback
in fact, on episode 49. You want to read it out and then I can add that? Yeah, shall we start with
the short one? Okay, short one. So episode 49 was about version control. Yes. So comment posted
by Trey. He says, thanks for sharing. I have been managing versions of configuration files
locally on my system. And you have inspired me to use GitHub instead. We shall see how it goes.
Keep up the awesome work. Thank you, Trey. Yes, indeed. The most important remark, of course,
and that goes in line with our numbers, is actually the last one. Keep up the awesome work. I hope he
means us. He could be meaning GitHub, I guess. Microsoft, if you listen to the email,
if you listen to the sponsor, I'd let it in last 30 years. Indeed, indeed, I think we don't
know when the job there. David, Maya, if you're listening, I think the Christmas episode,
that's actually that was the one that was published before this one, is actually the one
basically that tops full disclosure. Yes, I'm a complete music, but don't worry about it, David.
Definitely the record of full disclosure. Indeed, okay. Yes. Anything to add, Martin, before I
read the next more comprehensive feedback? No, very kind of off Trey. And yeah, I mean,
it was just an idea we had talk about version control. And as if it inspired people to use things
like GitHub then, I guess. Yeah, perfect. Exactly. And needless to say, you don't have to use GitHub,
you can help me, you can use your own GitLab instance, or GitLab or something.
Shameless teaser, there will be an episode forthcoming, where we will go into a little bit of
detail about GitLab and how to use this in a static HTML journal, the context, statue. Yes,
that was requested by someone. Yes. Yes, can if you're listening, this is your episode.
Oh, can everything, I believe. Well, almost. Yeah, but by the way, it might make sense,
actually, if you read out the comment from feedback, from Bikou, sorry, because in that case,
I can explain the fuck up. Okay, sure. Right. So our favorite commentator, or
the feedbacker, whatever the word for the Bikou, he has spent another bit of time writing a
spend a bit of feedback, which goes as follows. Right. Again, on episode 49,
40, 40 faster or 40 control or second employees, is his subject. Right. Hello, Dr. Zimmerman and Martin,
do you have two ends in Zimmerman or not? We don't know more about it. And
Bikou, we do love your feedback, but unfortunately, marketing puts the time in it on this episode.
So we're going to shorten this about for about two sentences. Okay. Bikou, don't worry about it.
Okay. Anyway, yes, indeed, indeed, keep writing. So because main feedback is that something,
I think something's broken in your flux capacitor. If nothing is broken, then you need to ditch Git
and replace it with something simpler and superior, like dark, fossil, or mercurial, even. Why? Because
if your flux capacitor is not broken, and surely, it has to be your version crawl system.
And it is Git, as you guys mentioned, in this very episode. If that two is okay,
then I'm afraid Martin needs a fire host, fire that's production employees. That's not bad advice there.
Yeah, it has been considered. Why? Why? Because Linus in the sport has version jumps to episode
number 49, straight from episode 43, skipping five episode numbers.
Oh my god. If you go here, the post-production staff, because they are under my personal protection.
Ah, well, maybe this is consequences. Benefit from a mass course, perhaps.
Sorry, but please do go on. Spend some money on training these people.
Right. Where were we? Right. So this episode on version crawl system was excellent as always,
informative and entertaining kudos. Gets, yes, thank you. Biko, indeed. Indeed, sorry, Chris Kerr.
Sorry, go ahead. Okay, he carries on. He carries on. Gets history is very
colourful, full of ideals, egos, ethics, necessities, betrayals, full of great drama in short.
And it involves a hero who is willing to put ideals and ethics aside to reach his goal.
His amigas aren't ready to ditch their ethics at any point,
at and at point. Sorry, other ones, than that bit. They are almost fell apart and parted ways.
The story also has a villain who is not willing to let go his control and lose position of a
secret magical formula that everyone wants, but no one has. Many of our heroes,
friend, try to find their, try to but fail to find his formula. Then comes a
samber artist upon a scene and he steals his magical formula from the villain and hands it over
to our hero. Story ends, but this is only the beginning of a saga.
And so it goes on, right? It does. He has even some suggestions for the cast,
which is a little bit ambiguous if you ask me.
Yes, we have to cut things out a little bit. But as I said, you're lengthy feedback.
Emails are appreciated. And we call, as I said, the offer still stands.
Please come on the show.
He also has a, he does, yes, please come on the show. And if anything to correct Chris
on his pronunciation of Git-T apparently, as it's meant to be, plus.
Well, in his feedback, he mentioned it is pronounced as Ghe and T as in T.
That's a difference.
Ah, yes.
I don't worry about it.
Is this, is this some, some dodgy relative of yours who does keep operations?
I can't go into details, unfortunately.
And because I don't worry about this detail, when we installs and details will be in the forthcoming
episodes of some because it looks similar in laws, when we install this guitar saying we just
call the guitar. Of course, I may be talking wrong, maybe it's G-T, I don't know.
I will be revealed in the in the G-T or G-T episode.
You see, the trouble, of course, with G-T, if you replace a single continent, you are in deep
problem. So G-T might be the best approach to this one. And Biko, let me explain a little bit
about the flux capacitor. Of course, your spot on the numbering actually was fucked up.
And there's nothing else, there's nobody else to blame, then just me.
Oh, even the post-production stuff, no.
Oh, okay. Because that stuff is not too blame for that mistake.
I take the full responsibility, because you see Martin cannot fire me.
No. No, he can't. I wouldn't want to, anyway.
He's better Martin, even better.
That would be not very nice.
As usual, people, if you're listening, of course, we do love you and appreciate your feedback.
So email address is feedback and little is in lots of you.
If you want to send us money, please get in touch with us via some of our sponsor
ads, little is in lots of you, whether you're IBM, Microsoft, or just a soul listener, exactly.
We may be thinking about setting up a prediction scheme to be confirmed during the course of the year
that may, in contrast to other podcasts, give you an ad, not an ad-free version, but an ad-plus
version with more ads at the end of the episode. So if you want this, please get in touch with
our feedback at Linux in lots of you so we can see what we can do about this.
Yes, we can introduce some ads. Exactly. The funny ones, if you know what I mean.
Yes, that sounds excellent. Exactly. You see other podcasts, basically, if you'd add free
version, if you put money on Patreon on this, and we might as well flip that corn around and say,
no, look, if you want to have more joy and fun, simply give us money because that means more ads.
Well, we could also do the other way around and we can put up some annoying ads and then if
people don't want them, they can fix that bad work here. Yeah, Martin, you're on this department,
right? The department of annoying ads. Yeah, I'm sure we can come up with some of those.
I mean, sorry, I thought that was already in existence. I mean, I saw a member with your
headcon in it. And you just had 10 people? Are you insane? 10 people? Well, it's someone
that's to make the tea. Why do you need 10 people? Oh, I want to make the tea. You want to make
the coffee? No, I mean, why do you need 10 people? Why do you need 10 people?
One, one, two, yeah, let's set the disc up and set things on it. Not no video crew. Yeah,
video crew. This is not the way it works. Yeah, there's a guy called Dennis Torvos. I don't know
if the travel arrangements, this is all complicated stuff, you know? No, it's not. Martin,
there's a guy called Dennis Torvos. Yes, I don't know if it's a bell. Exactly. So what's
to do with our ads? Get in touch with him and Bentley saying that Nvidia is sponsoring us.
That should do the trick. You take it and simply record his, he says, this comment. That's
annoying ads. I think we have a few in the bag already anyway. Anyway, also, there's
perfect. And that of course includes the feedback. And as I said, keep them coming. We have been
coming. Yeah. Thank you very much. Appreciate it. And with that, I would like to thank
Neil Johnson to be part of this. Thank you very much, Neil, for making an appearance.
Thank you for having me. And thank you for the project as well. Yes. And thank you for your
contribution to the World Wide Revolution. We're doing our best. We're doing our best.
One day at a time. This is the Linux in-laws. You come for the knowledge.
But stay for the madness. Thank you for listening. This podcast is licensed under the latest
version of the Creative Commons license. Tap Attribution Share Like. Credits for the entry music
go to Blue Sea Roosters for the song Salute Margot to Twin Flames for their peace call The Flow
used for the segment intros. And finally to the lesser ground for the songs we just
is used by the dark side. You find these and other ditties license under Creative Commons at
The website dedicated to liberate the music industry from choking corporate legislation
and other crap concepts.
You've been listening to Hecker Public Radio at Hecker Public Radio.org. Today's show was
contributed by an HBR listener like yourself. If you ever thought of recording a podcast,
then click on our contributing to find out how easy it really is. Hosting for HBR is kindly
provided by an honesthost.com, the internet archive and our sync.net unless otherwise stated,
today's show is released under Creative Commons Attribution Share Like 3.0 license.