[00:00.000 --> 00:10.000]  All right. Thank you for coming. So I'm Pierre, and I'm going to talk to you about Kazama
[00:10.000 --> 00:19.920]  and how we tried bridging Activity Pub with Matrix. So we talked a lot about interoperability
[00:19.920 --> 00:26.360]  even two years ago, and we found it sad that we talked about interoperability for proprietary
[00:26.360 --> 00:36.640]  platforms, not with our alternative decentralized networks. So we tried doing that. Kazama is
[00:36.640 --> 00:47.160]  hosted on GitLab. It's using the license HGPL v3, and it's done in Elixir. So we were
[00:47.160 --> 00:52.840]  shown that there was some stuff that hinted at building it. There was some article on
[00:52.840 --> 01:00.480]  the Matrix guide saying that you could bridge two decentralized networks. And there also
[01:00.480 --> 01:07.760]  was a hack and use comment by Matthew saying that there could be an Activity Pub bridge.
[01:07.760 --> 01:17.440]  And there also was a Matrix client library made by Uhoreg that we wanted to use and also
[01:17.440 --> 01:25.080]  an Activity Pub client library that was extracted from Playromar and made by the MoodleNet people
[01:25.080 --> 01:36.520]  and then by people at Bonfire. So the idea is to bridge those networks by creating puppet
[01:36.520 --> 01:44.360]  users. So Kazama is both an Activity Matrix server. It is an application service like
[01:44.360 --> 01:51.320]  other bridges, and it's also an Activity Pub server. So we on the Activity Pub site,
[01:51.320 --> 01:58.760]  we create puppet actors, and they can talk to Activity Pub users. On the Matrix side,
[01:58.760 --> 02:07.800]  we create Matrix puppet users that can talk to other Matrix users. So we wanted to both
[02:07.800 --> 02:15.000]  build an application service that you can deploy alongside your home server and also
[02:15.000 --> 02:24.520]  to have a public bridge so that other people on the Federated Matrix network can talk to
[02:24.520 --> 02:29.280]  Activity Pub users even if they don't have Kazama installed on their server. So that's
[02:29.280 --> 02:35.880]  what I'm showing here. And we, as I said, you can also be installed on your home server
[02:35.880 --> 02:45.440]  and then you have nicely displayed user names. For instance, just one character that changed.
[02:45.440 --> 02:54.120]  We made a web front end to help people see the bridged addresses. We also show here that
[02:54.120 --> 03:02.840]  we can display rooms that we'll talk about later. We started by bridging the chat that
[03:02.840 --> 03:09.320]  had been implemented by Peroma. It's only a one-to-one conversation chat. So we use
[03:09.320 --> 03:19.920]  the direct rooms of Matrix to do that. We then try to bridge direct messages like on
[03:19.920 --> 03:26.240]  Mastodon. Those are posts that are only sent to people that are mentioned in it. So there
[03:26.240 --> 03:36.240]  we used private rooms in Matrix. So there are no end-to-end encryption in Activity Pub.
[03:36.240 --> 03:44.960]  So for now Kazama only works on unencrypted rooms. It could work on encrypted rooms but
[03:44.960 --> 03:56.360]  then it would just bridge by deencrypted the messages. Then we also wanted to bridge Activity
[03:56.360 --> 04:06.920]  Pub public activities by creating public rooms where public activities are just bridged.
[04:06.920 --> 04:13.560]  It was something that wasn't really well thought out because we thought that it was a good
[04:13.560 --> 04:20.320]  idea to start bridging public activities as soon as Activity Pub users are searched for.
[04:20.320 --> 04:27.760]  So we made a relay actor that started following people quite immediately. It turned out that
[04:27.760 --> 04:35.600]  Activity Pub Fediverse had bad experiences with follow bots, as they say, because there
[04:35.600 --> 04:43.320]  were people trying to index the Fediverse. So there were angry people that started differing
[04:43.320 --> 04:50.200]  our staging instance. But there were also nice people who came in our Matrix room and
[04:50.200 --> 04:55.280]  we thought about ways to make it opt-in. For instance by having the relay bot send a direct
[04:55.280 --> 05:01.800]  message and wait for a positive answer or by having it wait to be followed to then follow
[05:01.800 --> 05:10.920]  back. Here is an example with a peer tube video where we can use a reply to have people post
[05:10.920 --> 05:18.840]  comments on the video. We also did something pretty nice with Mobilizon where you have
[05:18.840 --> 05:28.040]  groups and then we found that we could have people invite Matrix users and it would create
[05:28.040 --> 05:33.160]  a private room and as soon as people joined the room then there would be members of the
[05:33.160 --> 05:39.320]  group and then you could use the same activity types for discussions that happen in Mobilizon
[05:39.320 --> 05:50.040]  groups. So as a summary we bridge the user search, the profile, we bridge multiple activity
[05:50.040 --> 06:01.000]  types, post chat message, video and events. Activity pub rooms are still to be finished.
[06:01.000 --> 06:09.320]  We also started to build Matrix user rooms so people could ask the relay bot to make a
[06:09.320 --> 06:14.600]  room that they are administrator of as an kind of ad book room and then it will publish
[06:14.600 --> 06:20.200]  what they say as a public activity pub activity so they could be followed and appear on the
[06:20.200 --> 06:29.240]  Fediverse. There's also something to be thought again about that because on Activity Pub you
[06:29.240 --> 06:37.560]  need to have a way to see the activities that are sent from the instance when they were
[06:37.560 --> 06:45.000]  sent so we made a web page for the activities that are sent but then there's a thing of
[06:45.000 --> 06:52.600]  also showing replies like that and it's not something that's really nice to also display
[06:52.600 --> 06:58.680]  activities from other instances so we need to think about it again. As I said the Mobilizon
[06:58.680 --> 07:03.800]  groups, the private room has direct messages and the direct room has pure match-hat. We
[07:03.800 --> 07:10.920]  have replies, attachments and mentions. So there is still quite some things to be done
[07:10.920 --> 07:20.120]  but you are welcome to come and provide feedback or maybe contribute if you would like. I've
[07:20.120 --> 07:25.720]  also shown as it's a developer room some parts of the application service library that we
[07:25.720 --> 07:31.720]  made in Elixir so we just need some configuration like the one on the application service configuration
[07:31.720 --> 07:37.640]  file and then you can use the nice feature in Elixir like pattern matching to just select
[07:37.640 --> 07:48.040]  the messages that you want to act on and here's an example. So just to finish I'd like to thank
[07:48.040 --> 07:55.560]  NGI0 and NLNet at FundedF and we are in the process of having yellow to sponsor us some
[07:55.560 --> 08:02.360]  servers for our public instance and we've got hints on security by radically open security
[08:02.360 --> 08:10.600]  and then accessibility by accessibility.nl and we've also started to create an organization
[08:10.600 --> 08:17.880]  to work on Kazama on other projects that are mostly built on metrics so feel free to come
[08:17.880 --> 08:36.680]  follow us and maybe support us. I think that's it. Thank you. Are there any questions? Are there any
[08:36.680 --> 08:53.320]  comments? I'm not so much into social media such as Fediverse but I got the attention that there's
[08:53.320 --> 09:03.800]  much more public conversation going on than is usual on instant messaging so if I got a
[09:03.800 --> 09:14.520]  somewhat closed room type in matrix and there's an interaction via bridge to via Kazama would it
[09:14.520 --> 09:20.200]  mean that whole conversation can become a public conversation on a favor side?
[09:22.360 --> 09:28.280]  No it wouldn't. If there are something that are bridged as public it's only because it's on public
[09:28.280 --> 09:36.040]  rooms and the other way around too. So if we use private rooms it's only for private messages
[09:36.600 --> 09:42.680]  and it's... It keeps the same type of... Yeah absolutely. Thank you.
[09:45.400 --> 09:52.440]  You didn't mention the delete event from ActivityPub so do you support it yet or do you plan to
[09:52.440 --> 10:02.840]  support it in the future? Yeah I forgot to mention it but we already support the delete event
[10:02.840 --> 10:07.800]  so we... Deletions are bridged on both sides of networks.
[10:14.200 --> 10:20.200]  Could you talk about the choice of Elixir? Is it like did you thought that it was a language for
[10:20.200 --> 10:27.160]  this application or just a different language? It's a language that I love but it's also with
[10:27.160 --> 10:34.120]  the framework Phoenix it's also a great language to build HTTP APIs and that's something that we
[10:34.120 --> 10:43.320]  do on both sides of the bridge so it worked out pretty well in the end. Yes. Another question
[10:43.320 --> 10:50.360]  is it already in such a state that we can just, as you proposed, install it next to our home
[10:50.360 --> 11:00.040]  server and it will just run or is it still having some rough edges? I think it's not yet ready
[11:00.040 --> 11:06.600]  but it's really close. I'd really love to start by deploying the public bridge so that people can
[11:06.600 --> 11:13.080]  start using it and provide feedback as a public beta first so I think it's not yet ready to be
[11:13.080 --> 11:18.600]  deployed on your own home server plus the fact that we started to work on the features of the
[11:18.600 --> 11:23.000]  public bridge means that there are still something that could be bridged that are not supposed to
[11:23.000 --> 11:32.760]  be bridged on a private bridge. So what's the prospect on end-to-end encryption? It's very
[11:32.760 --> 11:40.120]  cool that it supports unencrypted stuff but I'm a bit curious on the activity pub side. Is there
[11:40.120 --> 11:48.520]  anything happening there? I don't really much know. I know that people have been talking about
[11:48.520 --> 11:51.720]  but I'm not sure what the state of it actually is right now.
[11:56.280 --> 12:04.040]  So in terms of bridging, is it being encrypted and unencrypted because you said that if you have
[12:04.040 --> 12:11.640]  a private encrypted chat in matrix it will bridge that indirect message in an activity pub
[12:11.640 --> 12:17.800]  but that's still public. If you can intercept that message or access the server database or whatever
[12:17.800 --> 12:25.400]  you can still read that. Yeah absolutely that's something that I think is a choice to make.
[12:25.400 --> 12:32.680]  I think that it's also there are some features that are added if we add support for unencrypted
[12:32.680 --> 12:38.040]  rooms because it still gets encrypted on the home servers and federated on server on matrix
[12:38.040 --> 12:44.840]  but it also could give a full sentiment of security so that's something that we really
[12:44.840 --> 13:08.040]  don't know about and still needs to be decided. Okay no question for that. Thank you very much.