WEBVTT

00:00.000 --> 00:10.640
Right, sorry about that. Hey everyone, my name is Eric, I'm a South

00:10.640 --> 00:14.360
Engineer at Element, I primarily work with the back

00:14.360 --> 00:21.040
and team who help build synapse. So I realized a few months ago that we just haven't

00:21.040 --> 00:25.320
talked about synapse for I think years and years and years, which is a

00:25.320 --> 00:28.400
little shame because I think there's a bit of a perception at times that synapses

00:28.400 --> 00:32.160
a bit boring, it kind of works kind of doesn't a bit old and crusty.

00:32.160 --> 00:37.040
We're actually, we do do a lot of work in synapse and we just fail to talk

00:37.040 --> 00:40.440
about it at all. So yeah, let's talk a little bit about what we've been

00:40.440 --> 00:44.800
up to, where we're going. I'm also just a little bit about what we're trying to do

00:44.800 --> 00:49.800
in synapse, what the goals are, what the aims are, and that sort of thing. So

00:49.800 --> 00:54.760
first, what even in synapse, so synapses, it's just the home-seven implementation

00:54.760 --> 01:00.040
and Python. So our home server is the thing that lives on the server, it's where

01:00.040 --> 01:05.440
your account lives, it's what your client connects to to send and receive messages,

01:05.440 --> 01:10.720
your home server then talks to other home servers, so that's what allows you or

01:10.720 --> 01:14.240
make sure to or you have a account and make sure to talk to users and other

01:14.240 --> 01:19.640
servers, either their personal servers or other companies and things like that.

01:19.640 --> 01:23.920
There are a lot of other implementations of home servers out there nowadays, which

01:23.920 --> 01:28.280
is really, really fun to see. They're trying different architectures and trying different

01:28.280 --> 01:34.400
languages and the like. But synapse is still the oldest, it's been around there for about

01:34.400 --> 01:38.480
over 10 years, like 11, I guess, this year. So it's the most

01:38.480 --> 01:42.520
featureful out there, it is the most battle tested and certainly the most widely used in

01:42.520 --> 01:47.160
the ecosystem. I think that's about 10,000 according to our phone home stats, which I

01:47.160 --> 01:51.560
checked the other day, but that's just the ones that have actively opted in. So the phone

01:51.640 --> 01:56.920
stats, so God only knows how many they were actually out there. But, you know, it's been

01:56.920 --> 02:02.480
10 years, so it's gone through a little bit of an evolution. So it started out as a prototype

02:02.480 --> 02:10.240
back in 2014, before we even knew what Matrix was. So we were just trying things out and I

02:10.240 --> 02:18.960
was there, Keegan, where he's. And like we sort of built some things and figured out what

02:19.040 --> 02:23.600
this Matrix protocol could look like at which point we launched and told everyone about

02:23.600 --> 02:29.040
it and it was great. But, you know, it was no longer a prototype. And so we sort of

02:29.040 --> 02:35.320
more saw it then at that point as a reference implementation. So the idea there is that

02:35.320 --> 02:39.480
you'd have different spec. But if that was a bit confusing or you didn't understand how

02:39.480 --> 02:43.760
that would work in practice, you could just go and have a look at the code. And it would

02:43.760 --> 02:47.400
be nice and simple and easy to follow. You'd have this implementation which is kind of

02:47.400 --> 02:52.840
no froze. But it would allow people to try it out and see how you built something on top

02:52.840 --> 02:59.120
of it. Unfortunately, more of people started using Matrix and that requires more features

02:59.120 --> 03:03.720
and more config options. And since we wanted this to be a great success, we kept saying

03:03.720 --> 03:08.520
yes, obviously we'll build these features. And we kept building as the ecosystem grew as

03:08.520 --> 03:13.280
a matrix grew. We kept adding more and more features on top of it. And it very quickly

03:13.280 --> 03:18.280
stopped. Being a reference implementation at that point, and started being more of a

03:18.280 --> 03:23.880
feature for batteries included style implementation. All of that happened very naturally

03:23.880 --> 03:28.560
and organic clear of the time. It's not like we set down and go white with changing direction.

03:28.560 --> 03:33.280
It was just the right thing to do and we did it. But it does mean that we haven't really

03:33.280 --> 03:40.200
ever had a nice kind of pithy one-liner for what is the goal of synapse, what we trying

03:40.200 --> 03:44.520
to do with it? Which is unfortunate because it's really nice to have something like that

03:44.520 --> 03:49.640
so people understand what we're doing and why we're doing that sort of thing. So yeah,

03:49.640 --> 03:53.600
over the past few months, that's kind of been a topic that we've talked about internally

03:53.600 --> 03:57.920
a bit more on this part. The synapse team, like how can we explain to other people what

03:57.920 --> 04:04.120
our goals are? But long story short, this is kind of what we've ended up with, is the

04:04.120 --> 04:10.080
idea that we want to provide a great experience out of the box. So any more concretely,

04:10.080 --> 04:16.560
what does that mean? Well, for end users, this means being reliable, like it sounds like

04:16.560 --> 04:21.760
a really low bar to not drop messages as a messaging app. But it's quite important. You do

04:21.760 --> 04:28.160
one of those wants, if it's wants in a blue moon and people just stop trusting you. And

04:28.160 --> 04:33.320
like for instant messenger, you need your users to trust. Otherwise, they're just going

04:33.320 --> 04:37.040
to go and do something else because if you can't rely on them, your message is being sent

04:37.040 --> 04:42.800
through. You're just going to have to use something else. And it's not just the kind of

04:42.800 --> 04:47.680
whether a message gets through. It's also whether the user perceives it as kind of working.

04:47.680 --> 04:52.480
They can't see what's going on in the hood. So like that perceived robustness is also really

04:52.480 --> 04:59.600
important. So if the app feels slow and janky and kind of a bit jittery, people are going

04:59.600 --> 05:05.200
well, something's clearly going wrong. And so performance is also really important here,

05:05.200 --> 05:12.240
like perceived performance. So that's important for us. And on top of that, obviously, having a

05:12.240 --> 05:17.600
fast app is nice and that will make people want to use us. And then on top of all of that,

05:17.600 --> 05:23.120
you need all the modern features that you expect from a messaging client. 10 years ago,

05:23.120 --> 05:27.840
the messaging ecosystem was different. There are a lot less features. Whereas nowadays, you

05:27.840 --> 05:33.680
have encryption everywhere. You want multi device support, you want reactions, you want threads.

05:33.920 --> 05:38.480
And, you know, as time moves on, that's going to keep happening, like more and more features

05:38.480 --> 05:42.800
will need to be added. And synapse will make sure it's as a whole, will kind of need to keep

05:42.800 --> 05:48.320
pace. So that's important. But users are on the only people which want to target here,

05:49.280 --> 05:55.360
server operators are also important. Like a lot of you, I imagine running synapse in one way or the other.

05:56.640 --> 06:02.640
And it's really important that it's easy to install. At least initially, even if you have to do

06:02.720 --> 06:07.440
some more comfort down the line, if you get bigger. Because no one's going to recommend running

06:07.440 --> 06:12.080
synapse. No one's going to try running synapse. If it takes hours and hours and hours and a lot of

06:12.080 --> 06:17.920
fast to get going. And similarly with maintainability, like if you're running this stuff,

06:17.920 --> 06:22.800
you're running a server-sized thing, is always going to require a little bill effort. But if it's

06:22.800 --> 06:28.960
taking hours of your time, kind of every week, just to keep it updated, again, it's going to feel like

06:28.960 --> 06:34.240
a FAF and people are just not going to recommend synapse to others. They're not going to run

06:34.240 --> 06:41.600
at their communities or the businesses. So operators are also really important to us. And so

06:41.600 --> 06:48.640
we want to give them a great experience too. But this is, we can't be everything to everyone.

06:48.640 --> 06:53.840
Like this is, you know, there's a lot of different use cases. In matrix, we see a lot of different

06:54.400 --> 07:02.400
deployments out there, whether that's just tiny, like personal servers or the communities or

07:02.400 --> 07:09.200
something like first-end or like those really big servers like make sure to or big companies or

07:09.200 --> 07:14.720
small companies, tons of different use cases. And so we do need to have a little bit of focus

07:14.720 --> 07:18.880
of who we're prioritizing and what sort of features and deployments we want to do at the

07:18.880 --> 07:25.280
least, we're just going to run out of time. So this is kind of just what we're focusing on now.

07:26.560 --> 07:33.280
And the first big one is the smaller medium-sized messaging deployments. So that's like the

07:33.280 --> 07:38.320
vast majority of the community, certainly, are fit into that bill. And the idea there is that

07:38.320 --> 07:46.000
we'll spend as much time as we can trying to make those better. Make, yeah, give a great experience

07:46.000 --> 07:52.400
to those users and the people running those deployments. For things like the slightly larger deployments

07:52.400 --> 07:57.200
where you start having to do a lot of stuff with workers, we're still going to support that. Obviously,

07:57.200 --> 08:01.280
we're not, this is not about taking anything away. This is just, we're kind of acknowledging

08:01.280 --> 08:06.080
the fact that if you're going to run those larger deployments, it's going to take more tinkering

08:06.080 --> 08:11.440
in a little bit more time. It's not going to work straight out the box about any kind of extra

08:11.440 --> 08:17.600
configuration. And we kind of see that as fine people will expect that. And also for non-messaging

08:17.600 --> 08:22.960
use cases, we certainly want to support them and we do support them. But again, it might take

08:22.960 --> 08:27.760
a little bit more tinkering just because we don't know what the messaging use case is kind of

08:27.760 --> 08:32.480
the usage patterns and that sort of thing. And that can be radically different than a messaging

08:32.480 --> 08:37.040
app. And so that just requires a little bit more performance tinkering and that sort of thing.

08:37.040 --> 08:42.720
But we do still support it. Just not quite out the box. And then finally, you have some of these

08:42.720 --> 08:49.360
really, really massive deployments. We're talking about like millions of users here. And that's

08:49.360 --> 08:52.720
just something that synapses currently, really just doesn't particularly support out the box.

08:52.720 --> 08:58.720
It tends to just immediately fall over. And part of that is just the architecture of synapse fundamentally

08:58.800 --> 09:07.440
the way that replication works. And the like, element does need to do that. To actually do that,

09:07.440 --> 09:12.320
you do need to have extra tooling and expertise and you do think a huge amount of time trying

09:12.320 --> 09:18.560
to make that work. You can just about do it. Element has just done some of this and help people

09:19.760 --> 09:24.320
run at that scale. It takes a lot again, a lot of custom tooling and stuff. So if you do want to do

09:24.800 --> 09:29.760
come and talk to us, the fundamentally kind of out of the box, the first version just falls over

09:29.760 --> 09:34.640
and there's not much we can do to not make that just because of the use cases that are very

09:34.640 --> 09:42.640
different and kind of have to take it by a little bit more case-by-case. So this is where our focus

09:42.640 --> 09:48.400
is. So I know when you're at the top that people start having issues with the larger deployments

09:48.400 --> 09:53.440
will fix that. We'll continue with the documentation for how you run like that sort of deployments

09:53.440 --> 10:02.720
as well. So that's a lot of talk about kind of goals and aims and kind of how does this actually

10:02.720 --> 10:10.080
relate to what's actually happening around and the practical reality. So how are we doing today?

10:10.080 --> 10:16.000
Like some of that was aspirational. I think things that we do do quite well is making easy to install

10:17.680 --> 10:22.080
so like you only need a postgres and a front-end web server and then you can just grab the

10:22.080 --> 10:28.400
Docker image or the devian packages or one of the many third-party package that people maintain

10:28.400 --> 10:34.720
and you just generate the config and voila. I mean Matthew showed earlier just how easy that

10:34.720 --> 10:41.600
can be. It takes 30 seconds. Sometimes it's been these sort of things up. So that's great. We also

10:41.600 --> 10:46.800
try really hard to make it easy to keep updated as much as it personally horrifies me to see people

10:46.800 --> 10:54.000
running so that's from years ago. It is quite satisfying when you do need to update. They bump

10:54.000 --> 11:01.360
the version, get the new package and they just restart and it all just magically works. Like 30 seconds

11:01.360 --> 11:06.400
of time taken to do that and a huge amount of work goes into that. Like we do database

11:06.400 --> 11:11.760
gimmers changes all the time but we really really try to make that force compatible so you don't

11:11.760 --> 11:18.240
have to do any manual steps there. We've also been continuing to just add new features that clients

11:18.240 --> 11:23.120
need. We're kind of looking at for example adding some better threading APIs for the next or the

11:23.120 --> 11:30.800
rest of it and reliability. We don't really drop messages ever nowadays. Again it feels like a really

11:30.800 --> 11:38.320
low bar but it's an important one so you know I'm going to take the win. But obviously synapse

11:38.400 --> 11:44.240
isn't perfect you know consistently the biggest complaints we get from people are around resource

11:44.240 --> 11:53.280
consumption and usage so things like memory usage, database size, get CPU usage and that's sort of

11:53.280 --> 11:59.920
thing. So that's a big one and closely related as performance you know especially

11:59.920 --> 12:06.560
perceived performance from users so whether that's just it takes a long time to load in the app

12:06.560 --> 12:11.840
or to send a message or something you know that's something that you really need improving.

12:11.840 --> 12:16.320
For a lot of people it's actually fine and a lot of people do use synapse after the box and it's

12:16.320 --> 12:21.840
fine but it's really easy for one of your users to just join makes you say it's cute for example

12:21.840 --> 12:26.880
and then you watch synapse really struggle on those smaller boxes which is unfortunate because

12:26.880 --> 12:33.840
it shouldn't take one user to do something dodgy for it so it goes slightly webly. So I mean a great

12:33.840 --> 12:40.160
example of what we've been doing recently to make this better is doing things like the signing

12:40.160 --> 12:48.880
sync API which is part of matrix 2.0. So the sync API is used to get your rooms and messages

12:49.680 --> 12:55.920
from the server and so when you start up it's how you get all those rooms and it's how you get

12:55.920 --> 13:01.120
new messages and it's last time and things like that but the problem is it's that it doesn't

13:01.200 --> 13:06.640
scale very well with how all your counters the more large rooms you have in there the more data

13:06.640 --> 13:10.960
it sends down at that initial launch and if you're someone like Matthew not trying to pick

13:10.960 --> 13:17.440
a new but that can take 15 minutes if not longer now to 20 minutes keeps going up as the problem

13:18.240 --> 13:23.840
it started off for a couple of minutes and now it's at 20 and so that's obviously just fundamentally

13:23.840 --> 13:30.160
unacceptable like you can't run a messaging up like that so sliding sync is something that

13:30.240 --> 13:35.360
kegum has been working on to just get away from that and change the API to be

13:37.200 --> 13:46.160
scale to larger counts and that has taken the time to sync initially from 15 minutes to a second

13:46.160 --> 13:51.840
which is a thousand x speed up which is great and it's a great example of how we can change the

13:51.920 --> 13:59.760
API's just to make it more efficient and that is used on element x so you can try it yourself for

13:59.760 --> 14:05.600
example and yeah I mean it's one example of what we've done and we're trying to do some more

14:06.160 --> 14:15.280
of that sort of thing then sometimes you know a second time a second is still too long for this

14:15.280 --> 14:20.000
sort of thing but at least when you're at a second it's a lot more plausible to start

14:20.000 --> 14:25.040
optimizing that heavily and really bring that down just know we essentially take a second it's just

14:25.040 --> 14:33.040
us being slightly slow in Python so to support that we've added a vossport into synapse we're not

14:33.040 --> 14:40.880
rewriting synapse into us at all as much as I'd enjoy doing that it's just used as a tool in our

14:40.880 --> 14:45.920
belt so when we do find one of these CPU in terms of tasks we hear a hard we can move that into

14:46.800 --> 14:53.600
rust and hopefully that will go faster and things like that as a small sidebar I am

14:53.600 --> 14:59.600
astounded how easy it was to integrate rust into the Python ecosystem pyro 3 in all of its

14:59.600 --> 15:06.400
libraries just make it super easy as expecting at the very least during all the native wheels

15:06.400 --> 15:12.000
and all the native packages would be a pain to set up the CI4 but they just have a CI build will

15:12.000 --> 15:18.160
command you stick it up there and it just builds everything for you which is great and example of

15:18.160 --> 15:24.720
how this has helped us these numbers are from a very old dodgy laptop that if you send a message

15:24.720 --> 15:31.280
in a room with 5000 local users it takes a long time to calculate all the notifications and all the

15:31.280 --> 15:37.040
push rules and that sort of thing previously because that's quite intensive algorithm because

15:37.040 --> 15:41.360
everyone changes their notifications all the time there's notifications settings all the time

15:42.400 --> 15:48.320
and that you take three seconds and that has come down to 500 milliseconds by pouring that bit of

15:48.320 --> 15:55.200
code into rust and actually the rust part where it actually calculates the push rules takes a few

15:55.200 --> 16:00.960
milliseconds here it's just quite a lot of shuffling around for other bits and pieces for 500

16:01.600 --> 16:07.120
so that's only a 6x speed up there for that API but it's still not shabby and it's something

16:07.120 --> 16:11.840
that we can slowly use to move other bits and pieces over to rust where it makes sense

16:14.080 --> 16:18.400
obviously we've been doing a lot of other stuff so I have two is a big thing

16:19.280 --> 16:23.200
if you know other reason it would be nice to have two face support and also everything else

16:23.840 --> 16:28.640
authenticated media is a big one which protects yourself from being used by your users just as

16:28.640 --> 16:34.480
a nice file which is really nice for your users but annoying when you're running a server

16:35.360 --> 16:41.280
there's also been tons of smaller performance improvements which just very incrementally move

16:41.280 --> 16:47.600
the nail but together really help and then obviously the bug fixes and security updates etc etc etc

16:49.360 --> 16:54.160
so that's kind of what we've done over the past deal話 here and coming up

16:54.880 --> 16:59.680
we're kind of not quite sure what we're doing yet but this is the sort of stuff

17:00.480 --> 17:05.360
that we're looking at so continuing to support major features and that sort of thing

17:06.160 --> 17:12.400
but really to help really to look into the API changes and changes to state res and those

17:12.400 --> 17:18.080
kind of algorithmic changes to really chase the performance improvements state res is

17:18.720 --> 17:24.560
as security also talking about just now is a huge contributor to performance problems

17:24.560 --> 17:28.800
and resource usage because it tends to enlarge rooms you have to pull out all of the state

17:29.200 --> 17:33.120
do this algorithm put it back but we can look at moving that to incremental things

17:33.120 --> 17:38.880
and incremental algorithms and the like and then also better of us support what we have today

17:38.880 --> 17:44.240
is very bare bones and you can't do a sink away ever it can't directly access the database

17:44.320 --> 17:48.960
so it kind of limits our usage of it quite a lot a lot of our actual heavyweight algorithms

17:48.960 --> 17:54.400
do need to talk today to buy so directly a lot but if it has to bounce back into Python and back

17:54.400 --> 17:58.800
to Rust you kind of lose a lot of the benefit of writing it in Rust in the first place

18:00.880 --> 18:08.400
so yeah I think that's basically what's on the roadmap and hopefully this gives a good summary

18:08.480 --> 18:14.560
of kind of this capacity we can take to get to our own goal I mean we're going to continue

18:14.560 --> 18:19.360
to do all the day to day maintenance as bug fixes and security updates and performance tweaks

18:20.080 --> 18:25.040
but hopefully hopefully hopefully with a bit of time and a bit of effort this takes us back to the

18:25.040 --> 18:31.440
idea of getting synapse being giving a great experience out of the box because that's what we want

18:31.440 --> 18:36.720
and hopefully that would really really help metrics as the ecosystem as a whole and yeah

18:37.440 --> 18:41.840
just want to quickly say thank you to the community as well it's been great to see you

18:42.400 --> 18:46.880
help a lot especially each other with running synapse otherwise yeah thank you

18:56.480 --> 19:00.080
I suppose is someone of you wants to ask the question

19:01.040 --> 19:07.360
thank you what's the question when are we going to finish faster room joints

19:08.160 --> 19:15.280
oh not I don't know Matthew when okay wait a second when I'll be going to finish faster room

19:15.280 --> 19:24.880
joints so we've got that that's the idea of when you join a room over matrix over the federation

19:25.440 --> 19:28.960
and if it's a really large room it takes ages to synchronize all the state

19:28.960 --> 19:32.800
they make sure they execute what I can't remember it's like some obscene number like 100 megabytes

19:32.800 --> 19:37.840
of Jason or something which just takes a while to first pull out the database and then shove

19:37.840 --> 19:45.520
over the wire and then actually process on the other end we changed it so that you could do that's

19:45.520 --> 19:52.960
a two-faced thing where you kind of do the join you get joined to the room and then you can

19:53.040 --> 19:57.920
get messages and receive messages and send messages and in the background you're synchronizing

19:57.920 --> 20:05.520
the state so you get a really fast kind of snappy join and then you can again incrementally put

20:05.520 --> 20:12.080
things in unfortunately that's what we have today unfortunately it's not quite good enough

20:12.080 --> 20:19.360
with the user experience because when you join you have to have that synchronized state before

20:19.440 --> 20:23.680
you can get any history so you still end up staring at a blank screen and the spinner while

20:23.680 --> 20:31.760
everything goes on in the background in terms of what's next I honestly can't remember how much

20:31.760 --> 20:38.880
work remains I think it's at least a couple of a month or so of just trying to make

20:38.880 --> 20:45.120
do some performance optimizations to make that faster and do better kind of thinking of the state

20:45.120 --> 20:49.760
and allow especially allow backpagination to work so at least you have some history and

20:49.760 --> 20:56.000
you don't scared of blank screen when you're joining so yeah

20:56.000 --> 21:00.880
there was a head over there

21:09.280 --> 21:16.640
sorry yeah okay so the question yeah so the question is are we going to make

21:16.640 --> 21:22.400
starting to think the default across the ecosystem we really really want that to be the default

21:22.400 --> 21:26.480
and certainly it's kind of going to be we're going to duplicate the old sync API's

21:28.080 --> 21:32.800
I don't know how aggressively we want to push that I mean step one is to actually get that into

21:32.800 --> 21:38.560
the spec it's commonly waiting on me to have the time to finish up the remaining concerns

21:39.120 --> 21:44.080
it's almost there and then it can hit FCP and we can actually get more apps using it

21:45.280 --> 21:49.600
but certainly we want to deprecate it it's a bit harder to deprecate these things because

21:50.400 --> 21:54.720
there's a lot of use cases especially with bots and things that do quite like having

21:55.280 --> 21:58.720
getting everything at once and they don't care that it's so slow and they don't care that effects

21:58.720 --> 22:04.320
serve a performance so much but that's certainly a conversation to have around when can we actually

22:04.320 --> 22:09.280
delete that endpoint from the spec and how much work to support like the bot use cases

22:09.680 --> 22:16.560
how does that make the methods that all and all the scale of the user in the context of the

22:16.560 --> 22:21.920
free scale by talking up so I'll have to make sure to all kind of on the scale in terms of the

22:21.920 --> 22:28.640
priorities we listed a lot of that is me with a stick poking it which is kind of what I

22:28.640 --> 22:36.000
meant by takes a bunch of expertise to run we element also does have a bit of prior to retooling

22:36.000 --> 22:39.840
on the side help with the bigger parts of the scaling problems that's specific to make sure it's

22:39.840 --> 22:47.680
to org but yeah generally we just we try really hard to just keep an eye on it I'm

22:47.680 --> 22:53.120
almost surprised that my pet phone hasn't page me about it recently but yeah I mean that's very much

22:53.120 --> 22:58.000
approaching the scale when you do have to have a lot of the custom tooling and just for the auto

22:58.000 --> 23:02.640
scaling and for some of the custom bits for the federation state media and stuff so

23:03.600 --> 23:12.240
there's about 170 workers yeah 170 workers I think across two beefy boxes there's a bunch of

23:12.240 --> 23:39.200
VPSs so yeah yeah yeah I think about five yeah yeah I mean we have yeah about that number

23:39.520 --> 23:45.760
so for the microphone how many people are directly working on synapse probably the the

23:45.760 --> 23:49.760
wider back in team is just a bunch of other work as well as probably about six seven

23:50.560 --> 23:54.880
actively on synapse any given point at the moment is realistically closer to two or three

23:56.320 --> 24:00.960
and yeah depends whether you also include make sure both indication service and that which is the

24:00.960 --> 24:12.560
move over to I want to so you two questions you and you so I have a question about the

24:12.560 --> 24:23.600
mass of the authentication so you wait in the synapse and you just went and so the question was

24:23.600 --> 24:28.640
are we going to integrate mass into synapse at some point where masses the thing that speaks

24:29.600 --> 24:36.800
and the hope and desire to get at least a small part of mass into synapse so that when you do

24:36.800 --> 24:40.720
spin synapse up you have something basic that works with like username and password and stuff

24:41.280 --> 24:46.240
where it was actually the moment mostly focused on just getting mass onto make sure it's to org

24:47.120 --> 24:51.600
so we haven't quite gone to the stage of looking at when we want to do that but it's certainly

24:51.680 --> 24:58.880
desire to have something there probably not the full blown mass but at least their bones basic

24:58.880 --> 25:03.040
thing which means if you want to do have more features and use a more comfortable thing you can

25:03.040 --> 25:08.080
spin out a full blown mass and the nice thing about masses is written and rust which we can

25:08.080 --> 25:14.320
integrate more easily into synapse so you can just use it as a library is the plan and then you

25:14.320 --> 25:18.160
just need to spend some time hooking up all the database API calls and the thing like

25:19.040 --> 25:25.200
probably was saying the standalone mass is going to continue to be the primary thing so it's

25:25.200 --> 25:30.160
not going to be about sliding thing where there was a throwaway proxy that got killed and integrated

25:30.160 --> 25:36.960
instead the standalone mass will be the main way that people use it so if you're wondering

25:36.960 --> 25:41.200
should I wait to deploy mass now so there's no just going to it now it will continue to be

25:41.200 --> 25:50.160
even trying to grab it you do it's wondering what we have and and to end in crypto and

25:50.160 --> 25:56.800
charge it's when you're calling with what about files and if there's some way to press it on so

25:56.800 --> 26:05.360
that you know man in the middle can make sense of and so is the question like how do we

26:05.360 --> 26:13.680
deal with file attachments with all of the encryption so all of that is already handled so the

26:14.240 --> 26:22.560
media APIs they are just all the same and what happens is on the client side you use the same

26:22.560 --> 26:28.080
encryption scheme that you use for all of the events to actually basically encrypt the attachment

26:28.080 --> 26:33.360
before you upload it and then you share the keys for decryption with everyone in the room

26:34.080 --> 26:40.320
and then the server just sees as opaque it encrypt a blog it can access it but obviously it's

26:40.320 --> 26:45.360
encrypted to there's not much point and then anyone else can download it but unless you have

26:45.360 --> 26:53.360
the keys again that's that's pointless it's already done yep

26:53.360 --> 26:58.400
not about implementing some advanced crypto things to you and privacy like things that

26:58.400 --> 27:03.440
signal does for example product context recovery or is it sender things

27:05.440 --> 27:10.960
we'll have some of that question so I'm doing some more advanced stuff around the privacy

27:10.960 --> 27:16.880
perfect for serving protocols like signal I think some people have been looking at it that's

27:16.960 --> 27:22.000
watch more in terms of crypto team land I don't think there's any active what going on

27:22.000 --> 27:27.440
but there's MLS we're looking at I mean there's MSE's MLS going around and that's the thing

27:28.480 --> 27:33.200
but we as a back-end team I'm really looking at anything at the moment thank you very much