WEBVTT

00:00.000 --> 00:10.000
Jane's in the blue shirt here is going to do something for you and you know when I leave

00:10.000 --> 00:15.000
Okay, I love you, God. Thank you, thank you.

00:15.000 --> 00:24.000
And that's where you want to buy a screen, so this is going to be nice.

00:25.000 --> 00:27.000
All right, I'll get out of the right.

00:27.000 --> 00:29.000
One, two, yeah.

00:29.000 --> 00:31.000
Hello.

00:32.000 --> 00:36.000
Thanks for having me here today.

00:38.000 --> 00:47.000
Today, I'd like to give my talk about Verify activity pop,

00:47.000 --> 00:50.000
sub or framework for TypeScript.

00:50.000 --> 01:02.000
If you have tried to build federated social app, you know the pain,

01:02.000 --> 01:15.000
and today I show you how Verify and to element these pains.

01:16.000 --> 01:20.000
So let me introduce myself.

01:20.000 --> 01:25.000
I'm home in here and I'm from South Korea.

01:25.000 --> 01:32.000
It was, it was about 10 hours from there to here.

01:32.000 --> 01:36.000
Thank you.

01:36.000 --> 01:41.000
It's my first time to be here in Europe.

01:41.000 --> 01:44.000
So, it's exciting. Thank you.

01:44.000 --> 01:51.000
And I'm trying to verify and follow and bucket.

01:51.000 --> 02:04.000
And I also organized federated care which is Korean community for federated developers.

02:04.000 --> 02:08.000
And I also run a hospital.

02:08.000 --> 02:12.000
This is a software engineers,

02:12.000 --> 02:16.000
logins prep on the, on the very first.

02:16.000 --> 02:21.000
And yeah.

02:21.000 --> 02:25.000
Let's start with the problem.

02:25.000 --> 02:31.000
So, why did I build Fed5 in the first press?

02:31.000 --> 02:39.000
When, when I started to build hollow,

02:39.000 --> 02:47.000
my single, single user, single user, Fed5 starboard software.

02:47.000 --> 02:53.000
I started, it would be very easy.

02:53.000 --> 02:59.000
Because at this point, it's just just JSON over SP.

02:59.000 --> 03:03.000
And there are obviously specs.

03:03.000 --> 03:08.000
There are many implementations, existing implementations,

03:08.000 --> 03:15.000
to, to, I, so I can look, look into that.

03:15.000 --> 03:28.000
So, I estimated about two weeks, but, how, what it was not.

03:29.000 --> 03:34.000
It's, it's, first, it's not just JSON.

03:34.000 --> 03:36.000
It's JSON early.

03:36.000 --> 03:40.000
And property names can expand to your eyes.

03:40.000 --> 03:46.000
And same data can have multiple shades.

03:46.000 --> 03:52.000
Specs are, specs are very, very extensible,

03:52.000 --> 03:56.000
but it also, on the specified.

03:56.000 --> 04:01.000
And many, in case, are left to interpretation.

04:01.000 --> 04:06.000
So, there are many implementations, but they,

04:06.000 --> 04:08.000
they literally differ.

04:08.000 --> 04:13.000
So, for example, activities that, let me also,

04:13.000 --> 04:18.000
might be rejected by, miskey.

04:18.000 --> 04:25.000
So, I spent over a month debugging,

04:25.000 --> 04:31.000
so, see, in the old property problems.

04:31.000 --> 04:40.000
So, I, I, I, I decided to build my own framework for activity power.

04:40.000 --> 04:43.000
First.

04:43.000 --> 04:47.000
So, what is fetched by?

04:47.000 --> 04:53.000
It's an opinionated factory power framework for high-screen.

04:53.000 --> 04:59.000
Opinionated means, it makes decisions for you,

04:59.000 --> 05:03.000
for you, the right decisions.

05:03.000 --> 05:13.000
We have key features like, such a thing.

05:13.000 --> 05:18.000
First, let's start with the most fundamental problem.

05:18.000 --> 05:22.000
Telling me Jason Ali.

05:22.000 --> 05:27.000
Jason Ali is the root cause of activity power complexity,

05:27.000 --> 05:29.000
in my opinion.

05:29.000 --> 05:33.000
Same data can be multiple representations.

05:33.000 --> 05:37.000
And, for example, our property can be a string,

05:37.000 --> 05:41.000
or an object, or an array,

05:41.000 --> 05:44.000
and there's no static types.

05:44.000 --> 05:53.000
So, you need to, you have to check everything at runtime.

05:53.000 --> 05:57.000
And, you need to resolve context,

05:57.000 --> 06:01.000
so that property names can, property names,

06:01.000 --> 06:05.000
expand to for URIs, qualified URIs.

06:05.000 --> 06:12.000
So, there are also implementation differences.

06:12.000 --> 06:15.000
Most of them don't do it one way.

06:15.000 --> 06:17.000
Minsky or another.

06:17.000 --> 06:20.000
So, without proper exception,

06:20.000 --> 06:23.000
you, you are called, because,

06:23.000 --> 06:29.000
a mess of tight text and case cases.

06:29.000 --> 06:37.000
So, here's, here's some example.

06:37.000 --> 06:41.000
So, the actual property,

06:41.000 --> 06:46.000
in an activity can be just URIs 3,

06:46.000 --> 06:51.000
or it can be a, it can also be an object embedded

06:51.000 --> 06:55.000
object with several properties,

06:55.000 --> 07:01.000
or it can be an array of multiple actors.

07:01.000 --> 07:05.000
And, so, our, sorry, are valid representations,

07:05.000 --> 07:07.000
according to the spec.

07:07.000 --> 07:11.000
So, you're called the most handy or real damn.

07:11.000 --> 07:15.000
So, it means writing,

07:15.000 --> 07:19.000
if and as a change for every single property,

07:19.000 --> 07:24.000
that's what role activity property parameters looks like.

07:24.000 --> 07:29.000
So, verify, test it away.

07:29.000 --> 07:34.000
With verify, you just call activity that,

07:34.000 --> 07:36.000
get actor method.

07:36.000 --> 07:39.000
In need of actor or norm,

07:39.000 --> 07:43.000
and TypeScript knows the exact type.

07:43.000 --> 07:47.000
If the actor, if the actor is URI,

07:47.000 --> 07:50.000
verify that she's in automatic query.

07:50.000 --> 07:56.000
If it's embedded, you get, you get it directly.

07:57.000 --> 07:59.000
And if there are multiple actors,

07:59.000 --> 08:03.000
you can interact with, get actors method.

08:03.000 --> 08:07.000
So, your ID gives you auto compression,

08:07.000 --> 08:11.000
and type errors are caught at compile time,

08:11.000 --> 08:14.000
that in production.

08:14.000 --> 08:21.000
And, I also noticed that the secret if we note.

08:21.000 --> 08:24.000
So, cross-origin embedded objects are automatically

08:24.000 --> 08:28.000
refetched from the origin.

08:28.000 --> 08:30.000
These pre-banned spoofing attacks

08:30.000 --> 08:32.000
were some, someone,

08:32.000 --> 08:38.000
embedded the fake actor object.

08:38.000 --> 08:41.000
Next, let's talk about cryptographic signatures.

08:41.000 --> 08:43.000
Another major source of pain

08:43.000 --> 08:47.000
in activity pop development.

08:47.000 --> 08:50.000
Every activity part requires

08:50.000 --> 08:52.000
needs cryptographic signatures.

08:53.000 --> 08:57.000
For outgoing activities, you sign with your privacy.

08:57.000 --> 08:59.000
And for incoming activities,

08:59.000 --> 09:03.000
you verify against the sender's public key.

09:03.000 --> 09:07.000
It sounds simple at first,

09:07.000 --> 09:11.000
but which signature scheme are there.

09:11.000 --> 09:18.000
So, there are four major signature schemes.

09:18.000 --> 09:23.000
One is draft cavity.

09:23.000 --> 09:26.000
This is the defect of standard.

09:26.000 --> 09:32.000
And IFC-1941 is the official standard

09:32.000 --> 09:35.000
that widely audited.

09:35.000 --> 09:39.000
And I think Masoldoen recently audited this.

09:39.000 --> 09:43.000
And L.D. signatures for embedded profiles,

09:43.000 --> 09:46.000
but it's also solid.

09:46.000 --> 09:49.000
And there are object to integrate the profiles

09:49.000 --> 09:52.000
for embedded profiles, as well.

09:52.000 --> 09:54.000
It's modernly pre-announced,

09:54.000 --> 09:56.000
refreshment of L.D. signatures,

09:56.000 --> 09:59.000
but not widely audited.

09:59.000 --> 10:01.000
Different servers, different schemes,

10:01.000 --> 10:06.000
and you need hand over all of them.

10:06.000 --> 10:10.000
But you can use that type instead,

10:10.000 --> 10:15.000
which supports all four ultimate curry.

10:15.000 --> 10:20.000
So, with FFI, you just write your business and logic.

10:20.000 --> 10:23.000
Look at this code.

10:23.000 --> 10:28.000
You define an inbox listener for follow activities.

10:28.000 --> 10:32.000
And when follow activity arrives,

10:32.000 --> 10:35.000
the signature is already verified.

10:35.000 --> 10:40.000
You don't write any signature verification code yourself.

10:41.000 --> 10:45.000
When you call, context that send activity,

10:45.000 --> 10:48.000
message, verify science is automatically.

10:48.000 --> 10:52.000
You don't think about which is akin to use.

10:52.000 --> 10:57.000
There's a magic called double knocking, as well.

10:57.000 --> 11:01.000
And FFI tries to RFC-1941 first.

11:01.000 --> 11:04.000
And if the servers reject it,

11:04.000 --> 11:07.000
FFI falls back to draft activity,

11:07.000 --> 11:10.000
which is the reverse standard.

11:10.000 --> 11:15.000
And it also remembers the pre-fronts for future requests.

11:15.000 --> 11:22.000
So double knocking is only happening at first time for each peer.

11:22.000 --> 11:26.000
And this is kind of interoperability.

11:26.000 --> 11:33.000
Well, for you, you shouldn't have to do yourself.

11:33.000 --> 11:39.000
And FFI does it for you.

11:39.000 --> 11:44.000
And next, let's talk about Scarogchi,

11:44.000 --> 11:51.000
specifically the FNL-FNL problem.

11:51.000 --> 11:56.000
What happens when you post to 10,000 followers,

11:56.000 --> 12:01.000
there's a night approach, 10,000 HP requests.

12:01.000 --> 12:06.000
And you are sovereign with timeout.

12:06.000 --> 12:08.000
Because some servers are slow,

12:08.000 --> 12:14.000
and some servers are temporarily down.

12:14.000 --> 12:19.000
And you should, FFI delivers should be

12:19.000 --> 12:23.000
retried with exponential tech curve,

12:23.000 --> 12:28.000
and memory pressure with a from cue request.

12:28.000 --> 12:32.000
And there are many more.

12:32.000 --> 12:37.000
In actuality poll, there's actually inboxes,

12:37.000 --> 12:38.000
as well.

12:38.000 --> 12:42.000
And many servers have a single inbox for all users.

12:42.000 --> 12:45.000
And you should send the ones for server

12:45.000 --> 12:48.000
that wants for actor.

12:48.000 --> 12:53.000
So you need to detect it,

12:53.000 --> 12:58.000
and detect this.

12:58.000 --> 13:08.000
So, building this all this from scratch

13:08.000 --> 13:12.000
would be, would take weeks of work.

13:12.000 --> 13:21.000
So you will probably get it wrong the first few times.

13:21.000 --> 13:29.000
So, FFI, just configure or message queue.

13:29.000 --> 13:37.000
And this exam preshows how to use reddit.

13:37.000 --> 13:42.000
But FFI also supports any other message queue

13:42.000 --> 13:47.000
like ANQP, DinoKibi, post to rescue,

13:47.000 --> 13:48.000
and so on.

13:48.000 --> 13:52.000
And you can implement your own adapter as well.

13:52.000 --> 14:00.000
If you want to configure it automatically

14:00.000 --> 14:04.000
literally with exponential tech curve up to ten

14:04.000 --> 14:07.000
or ten by default,

14:07.000 --> 14:13.000
and show the inbox optimization is also over a level set.

14:13.000 --> 14:17.000
And so if you set pre for show the inbox option

14:17.000 --> 14:20.000
to two, and then with FFI,

14:20.000 --> 14:23.000
you duplicate it automatically.

14:23.000 --> 14:31.000
So, FFI also have two state files

14:31.000 --> 14:35.000
since version 105.

14:35.000 --> 14:43.000
And so activity is go to the queue immediately,

14:43.000 --> 14:47.000
and walk us delivery in parallel.

14:47.000 --> 14:50.000
So, you are post returns instantly,

14:50.000 --> 14:54.000
and delivery happens in the background walker.

14:54.000 --> 15:00.000
So, and FFI, the delivery are also

15:00.000 --> 15:03.000
retried automatically.

15:03.000 --> 15:08.000
This is production ready quality of scalability

15:08.000 --> 15:11.000
with minimal configuration.

15:13.000 --> 15:17.000
And one more thing about FFI's philosophy is

15:17.000 --> 15:23.000
it doesn't detect your technology scale.

15:23.000 --> 15:28.000
FFI works as a middleware for your existing framework.

15:28.000 --> 15:30.000
That was a good framework.

15:30.000 --> 15:36.000
For example, Hono, example, express FFI

15:36.000 --> 15:42.000
or Netflix, or anything that speaks the standard request

15:43.000 --> 15:48.000
or response API or property.

15:48.000 --> 15:52.000
You can use your preferred volume.

15:52.000 --> 16:00.000
That's only the comment is a key value store for catching.

16:00.000 --> 16:08.000
So, we have deliverable devices as well.

16:08.000 --> 16:18.000
And we have FFI new call for

16:18.000 --> 16:23.000
to let you inspect any activity power OZ.

16:23.000 --> 16:28.000
It takes FFI, FFI, or you are,

16:28.000 --> 16:31.000
it fetchs the OZ.

16:31.000 --> 16:37.000
It also provides, also provides fetch thread.

16:37.000 --> 16:42.000
And it generates a temporary key pair of signs

16:42.000 --> 16:47.000
though, we test for you.

16:47.000 --> 16:51.000
FFI inbox is even more powerful.

16:51.000 --> 16:55.000
It spins the temporary activity of server

16:55.000 --> 16:59.000
with a public URL, and you get an anchor

16:59.000 --> 17:03.000
with an inbox that can list of activities.

17:03.000 --> 17:06.000
It looks like this.

17:06.000 --> 17:12.000
You can see the full HP request activity

17:12.000 --> 17:17.000
and detailed the logs.

17:17.000 --> 17:22.000
And when it, you are done testing press,

17:22.000 --> 17:26.000
controversy and FFI sends delete application

17:26.000 --> 17:30.000
activities to our peers.

17:30.000 --> 17:35.000
So, ghost is a major portion platform

17:35.000 --> 17:44.000
with millions of users, and they choose FFI.

17:44.000 --> 17:49.000
And they are also different projects

17:49.000 --> 17:55.000
that depend on FFI too.

17:55.000 --> 17:58.000
So, thank you.

17:58.000 --> 18:01.000
Thank you for all of us.

18:01.000 --> 18:05.000
Thank you.

