Hello everybody, I'm Nico, I am talking today about logifers pit to pier applications with
orbit db. We have the people who have been here already today have been hearing a lot
about YGS and other CRDTs which are great. And orbit db is another CRDT distributed database
which is relying on IPFS. Can I ask if anybody have heard before orbit db? Okay, thank you.
And maybe some people louder. Okay, orbit db if anybody has heard orbit db before,
it's actually already 10 years old and the last years where I know orbit db since 2022,
when I was evaluating it, I'm not from orbit db, not from IPFS. I was just interested
in developing pit to pier applications like the idea of having web applications which
completely work without any servers. How is it working? Is it working? If so, how?
And I discovered orbit db in 2022 with a workshop and at the time the
possibilities were still limited. You had a centralized signaling server where the
apps, the web applications could communicate only between the browsers and never between
between server nodes and it was a limitation. So, but anyhow, this concept, this tutorial,
what I was trying was very exciting. So, I kept on prototyping with this pattern and wrote a
block and at the end of it was really great. I discovered, oh, orbit db, this thing is
this database is inconsistent, the CRDT somehow database is crashing, right? And I thought it's
my fault. So, one year later, I tried again another prototype and at the time it was 2023 at the end
of the year. At the end of 2023, repeat the peer got upgraded and they made it possible
that Jay has a little bit to peer nodes which are running in browsers or mobile applications
that they can now also communicate with each other with web RTC and also communicate with
loop peer-to-peer nodes which are in running on server nodes. So, this was actually exciting for me.
Naturally, IPFS builds on loop peer-to-peer and orbit db builds on top of IPFS. IPFS, I don't know,
I cannot go too deep into everything Jay is loop-to-peer on IPFS and all of it because it's a big
topic but it was never so easy to go into it as now. This is what I can say. IPFS is
called interplanetary file system content addressed your store files in your browser,
in your browser running a peer IPFS node which another browser can directly get the file from.
This is actually amazing and orbit db and this is what is the local first part when you work
with orbit db, right? You have an IPFS node running in your browser. This is why it's also working
offline and it can sync between devices. So, you have your data in your browser, you have it
in your mobile and the syncs. This is what IPFS does and as I said, loop peer has many different
transports, web RTC, web socket, web transports with all kinds of different programming language
which makes it very compatible with a lot of things. Lip peer-to-peer is not my topic today,
I'm going further. orbit db is my topic today. What is how is orbit db working? Usually,
you have the choice of storing your data only in the memory or in level db or index db.
I connect to this speaker which was speaking before me. It is also important and we should,
in my opinion, we should find a solution to all of these standard questions no matter which CRDT we
are using. When a user comes to my app, he doesn't know this is a local first app or anything.
He doesn't care in fact. Also, how can we make sure the question arises? Can we just store
any data on his phone or can we not do it? gdb are questions. We should at least tell him or
give him the choice. You can now store your data, keep it on your device or just keep it in
memory as you like. I keep it on by default or you can switch on and switch off the network.
What about the whole decentralization? If you run a simple orbit db app in your browser,
then you would start with a relay or a signaling node somewhere in the internet. This is comparable
with a server in the sense you were talking before, but you could, any time have more nodes.
And this node also can run a orbit db and you can implement it that way that these nodes
are kind of pinning in IPFS we call it pinning when we mean caching or archiving these data
based entries. So whenever an orbit db node launches, it would connect to the relay nodes
and would sync with the relay nodes which needs to be synced. At some point probably it needs
some kind of consensus because we don't want to sync with the whole network. I haven't been
implementing anything of this. If anybody wants to implement something like this, please talk to me
because this is still open. I go forward. orbit db has also access controller. What we can do
is we can tell for each peer that a certain d id or identity is allowed to write to my
database or we can just say everybody can write, which is a bit dangerous, but for demo reasons
is a cool thing to do. Then we had people talking about access controller and certain
access controller frameworks. I'm right now evaluating and also implementing ucans, which is in my opinion
I don't know many others I have to admit, but I know the ucans for now is good for peer to peer.
So I can delegate capabilities between the peers where one peer could be a file, a file back
up system or anything like this. For example, I can show you later maybe, show you later about ucans.
The next, when you talk about permissions and ucans access controller, you need to talk about
identity. The application, the web application, which I'm building, don't have any accounts,
they don't have any password. Then in the past, we had the situation that we needed some
seed phrase and some onboarding for the keys is very difficult. We could have an Ethereum
provider with a Meta mask, things like that, or maybe you could use everything as possible.
And last year, I found web out n and pass keys are also working great for web applications
and then the question arises, where are living the keys? Because if the keys, the key store
is living in the browser memory, or when we start the note, then it's probably could be dangerous
keys could be stolen by malicious browser extensions. There might be on mobile devices
because there are no browser extensions, but in browsers is not so cool. This was the point where
I got a bit insecure, can we build applications like that? Luckily, I found out that other people
were talking today already, have already a solution for that because they also want to sign
U-cans and delegations with pass keys. Usually web authentication API is not made to sign
arbitrary messages. It's only made for authentication, actually they didn't want it to do this.
But even the key is hardware secured in your mobile phone, in the secure element, or in my
laptop, each laptop has this secure element, is living hardware secure in your hardware device,
or you have a U-B key in the key on that one. The question is how can we sign an OBDB lock
an entry for the database? This was stored by Alice, so Bob knows this was Alice,
who was editing my to-do list. This can be done. This can be done by varsic envelopes.
So what you do is you take the a couple of bytes and inline it inside of the challenge,
which is signed by web authentication API. There is a specification for it, which is done by chain
agnostic, chain agnostic. If you want to know about it, you can look it up,
varsic envelopes, and you can't, but also works for anything else. All right. How much them?
Questions? If there are questions, you can ask questions, otherwise I have maybe a little demo.
Questions or demo? Okay. I have a video made with you anything. This is about U-Cans with
Pas-Ki. So we have, I'm creating a credential in my browser, and I take the DID, which is generated,
and I have on my command line a storacha account, which is storing decentralized storage.
And I get the U-Cans, which is the delegation, and I import it into my browser.
So import it, and at some point, and I'm finished with this,
it should be possible to see the contents of my decentralized space, right? And just my browser,
authentic verifies this delegation, signs it, and sends it to the, has certain capabilities
about reading, listing, and uploading, and yeah, let's see if it works. And so you can see
there are several files in my space, and I just uploaded the, the proof into the browser.
But it goes, sorry? This is just, this is a demo, U-Cans. It's online, I can give you the U-U-L,
but maybe you can find it in my GitHub later. So I go forward. So you have, I upload data.
There's no server here, I connect directly to the, to the backend, to the, to the cloud,
which stores the decentralized data. And what I can do further, I can have another browser
for a mobile device and can delegate the capabilities, what I delegated to this browser to another
browser or to another person. So, and naturally, each of these capabilities have certain,
are only valid for a certain time, and can also be revoked, and things like this, right?
Um, I think that is, this is now the presentation for the second browser, create another
DID, I make the pass key, I, I have no password anything, I just use pass key, and then I make the
delegation in the other browser. And, uh, yeah, then I copy the, the delegation to the first browser.
Naturally, this takes very long in this demo. It is possible to make this all peer to peer,
that nobody sees anything about this, uh, transport of the proof. You can transport the proof
from one device to another, not otherwise, just by sending it via a little peer to peer
stream to the other browser or to your mobile device, right? So, now, this is, finish. Okay.
Thank you. Thank you very much.