IPFS IPFS þing 2022, 10 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: js-ipfs - @achingbrain - IPFS Implementations

Description

js-ipfs - presented by @achingbrain IPFS bing 2022 - IPFS Implementations - https://2022.ipfs-thing.io

A

I'm going to talk about uh joseph s where we've been where we are where we want to get to um so.

A

And we see that.

A

Okay yeah, so so this is jsrpfs. uh This is me, I'm making brain. um My name is alex port cds. Really, you can just call me alex I'm making brain on the internet. uh That's the repo for jsrpfs and the website.

A

A

Js ipfs, what's it for what is it for it's quite hard to break it down? Really because it's like because javascript runs everywhere.

A

So it's hard to just say: yeah, it's for the browser yeah it's for it's for servers, but it's for everything. Unfortunately, um but it runs on almost every computer in the entire planet. So if you want to get ipfs onto every computer on the entire planet, javascript is a great place to start. So it runs on browsers servers, desktops mobile 2 degree.

A

You can run it as a standalone daemon. You can run it as an in-process node as part of your application. So then you get proper inspection, easy debug ability and all that all that good stuff um it also like you know. Javascript is one of the most I was gonna say is the most popular, but I guess apparently, uh python has now stolen. That crown um it's good, that this is a late talk.

A

Yeah yeah they'll come around they'll come around, um so yeah 12.4 million uh javascript developers are in this world, which is quite an insane number uh and they could all be getting involved with jc ipfs and making it the most amazing way to share content and build distributive apps they're. Only 53, more than half of all developers use javascript like hands up in this room who uses javascript or has used trial zippers. At some point I mean that's more than half.

A

So architecture, how does it all fit together? Well, uh it's worth considering history a little bit so js ipvs started off as a as a kubo clone, um which has led to you know several architectural decisions over time. We've kind of come to the conclusion that maybe that's not not a great goal uh for something as flexible as javascript, um because you then end up so you replicate the apis. You replicate the design decisions of another system which might have different uh requirements to the ones that you're building, for example.

A

If it runs on the server you typically don't care about bundle size. So it doesn't matter if there's deprecated bits of the api that you keep around forever. um If you're running the browser, you definitely care about that kind of stuff.

A

Also, you know when you're in that situation it lends itself to a kind of a kitchen sync style of implementation. Where somebody requests a feature, you add the feature you never take it out, which is not great when you're trying to keep an api, an api, small and focused and easy to to understand and to get into and to use so we're trying to.

A

After after that realization we tried to break it up into smaller things, um so it's more of an ecosystem of modules, so lib p2p in particular, is very uh composable. um You can remove features if you don't need them. You know which is uh which is great, because it means you can. You can focus on a lot of uh different use cases um but yeah.

A

So I professed core uh was that was an attempt to remove a lot of the um extra if you're running an in-process node as part of your application, you're not going to want a cli you're, probably not going to want an rpc server, so those were stripped out, see we just use ips core. Instead, unix of fs is reusable um it's being used by other projects outside of js ipfs the same with bitswap. So you can basically pick and choose your components.

A

So ifs core is this idea of just the the operations that you would use uh as part of everyday use of ipfs? So it's the kind of things that are implemented by the uh kubo rpc api.

A

um It basically talks to unix fs, like everything is based on uses first for ipfs, uh which beneath that is dagpb, uh which is you know the structures within ipld that they're created to make up your unixfs file system underneath that this bit swap, um which is you know how you exchange uh the blocks.

A

If you're exchanging the blocks you're going via p2p or you're going to the bits, are you going to the block store if you have them already on your machine.

A

So this is uh yeah, so what I touched on about ipfs core being a smaller version, a bit more lightweight. So if you install ipfs, then you get the cli you get if it's call an http api and a daemon versus ibus call, you just get ipvs core itself and you don't have all this extra package.

A

So the pain points of jsi professor, why doesn't it do well? Well I mean it's not the kind of things that you think so like javascript is slow right. Everyone says javascript is slow. Well, not really like cpu intensive task, it's not fantastic out, but there are solutions. So in node you can drop down to c plus plus add-ons for it in node and the browser you can use wasm, so things that are slow in our stack at the moment. Are things like um encryption?

A

So if you do those kind of things in wasm instead of in but they're like yeah, so if you do them wisely, instead of in in javascript, you'll, see a speed up, and it also sits quite nicely because if you uh target small pieces of the application that need to get uh optimized and things likewise are fantastic, like it's not a great fix, if you want to do like large scale systems, because you're either in wasn't or you're, not um there's a significant developer experience penalty that you pay.

A

If you are not completely up to speed with the code behind the wasm, um whereas if you're just doing very small, focused uh improvements, then then you can there's a significant amount of low hanging fruit network intensive tasks so like browsers, uh they are pretty hostile environment in general. For um the kind of coding that we're trying to do uh with the you know, you can only have a certain amount of connections open.

A

uh It doesn't support particularly useful transports. uh So there's no tcp, there's no quick um as a listener, uh but, like I mean, do you want your browser to be able to open tcp ports? I mean- probably not probably not like. Can you imagine if there's uh like a cross-site, scripting thing, that's injected by an advert onto a website that you're looking at and suddenly you're opening tcp ports everywhere and connecting to things I mean that sounds bad. You know, so these things are there for a reason and they do they protect everyone.

A

um Node, on the other hand, is really good at networking things. It's uh it's event. Loop based model is incredibly efficient for io, so yeah it it's again. It's it's the the places you're deploying js ipfs uh that have different limitations, and it's something we all need to be aware of.

A

Maybe future tech, so china, trying to do really cool stuff like quick, is, is a is a real shame at the moment, because it solves some pretty significant problems. But there's no implementation for node.js like there is there's a pr open against node, um but it uses a fork of open ssl because of some things that happened with the open, ssl uh team and they didn't merge.

A

I mean check it out. It's it's kind of yeah, it's a bit bit uh facepalmy, um but yeah. So one day, maybe we'll get quick in there uh webcrypto is how we do most of um the cryptography. This is the way we would like to do all the cryptographic uh operations, because it's really fast, um but it does miss some things.

A

So, for example, ed25519 keys is nice important with crypto, which is really quite tedious, so we have to have either a native chest or a wasm implementation of that, and all the operations are async, even all the hashing and and that kind of thing which is really quite tedious, because it just introduces like artificial latency for no reason into your application.

A

The team, the team behind js ipfs, I mean at the moment it's basically me, which is uh you know, pretty significant bottleneck, but we've had some fantastic alumni pass through these hallowed gates. uh Think of the things that they've gone on to do amazing anyway, having one person on the team is not so bad. You know the meetings, the team meetings, the daily stand-up is very quick.

A

There's not a lot of dithering, there's very strong alignment on on the direction of what's gonna, where we're gonna go next, um but we're hiring so, please, you know, uh come and come and help it's really fun honest.

A

So traction I mean it's growing, I profess generous adverse is growing if you look at so that graph, there is, uh is basically the number of downloads in the last year and it's a nice like it's, not a crazy curve upwards, but it's basically doubled in the last year.

A

um So more and more people are using this and we also have uh I mean I hope this list is accurate. We also have lots of people who are using jsibos and or parts of it or they depend on things that depend on js ipfs.

A

What's next, what's on a roadmap so with ipfs uh we just recently switched to esm only because it's very important to try and like the dream is no bundlers. The dream is like running in the browser: no bundlers like no, no, nothing, just only uh only javascript, that's in the standards uh trying to remove all the node specific stuff so that we can run on dino and bun. Anyone heard of bun discovered this the other day uh it's another and yet another javascript runtime um like because we want to be web first.

A

Basically, so we want to. We want to have a. We have a smaller api like instead of this idea of trying to replicate uh cubo. We want to try and like have like an api. That's like configurable!

A

It's going to be uh you can you can like choose like pick and choose the component for your use case? If you don't need ips, don't use ipns, you know. If you don't, if you don't need like a dht, don't include the dht like be free like have a nice tiny, focused bundle, I mean that would be lovely uh and a name like we're gonna rename it.

A

I don't know what t yet, like maybe cubo js.

A

Ifps I like that one too banana, I mean yeah great, it's got, it's got emojis already. I love it um yeah, so we're going to rename it. um I think it's like the thing about renaming. It is it's not it's.

A

Not it's, not a low cost thing to do, because every every package that depends on it is going to have to change all of its imports, um which is incredibly tedious and yeah, like we've inflicted lots of pain on the user base for our constant refactoring, and this is another another bit of refactoring, but it will be renamed, but I think it will be renamed after we have like some something better for them to migrate. To that. Isn't this this cuboid clone uh yeah and so in libya on the pcp level, we're gonna!

A

Well, there are so many there's a whole lot of improvements you want to make so yeah, better discoverability connectivity. We've got like re like delegated uh routing through, like the new reframe protocol. That's that's being created, like I want to add uh proper nat hole punching, so uh that means circuit relay v2. We want to have like yeah. Also now, we've already got um d-trick at the back. We've already got a working dht implementation. Thank you very much. I did see that on your slide.

A

It's been there since january, unbelievable. uh What we don't have is uh dht server mode like it is there, but you have to turn it on explicitly. um Kubo at the moment will flip itself into server mode when it works out. What its external ip addresses or external addressable addresses are. What is external multi adders are um so we need. We need autonot for that first, um so that we can say with a relative degree of confidence.

A

What our external addresses are once that's there and we can turn on dht server mode if you're, externally, addressable um uh yeah, so adding like a full-time local software having real-time node orchestration. So we have this uh our http rpc api, uh which has all the limitations of http. So we can't do bi-directional streaming. um There's like there's a very there's, not a lot of access control applied to it and that kind of thing.

A

uh So, instead of having like a websocket api, which can be event based so we'll be able to build like real-time applications or applications that respond to the node state in real time have like we have to expose the full of the pcp api in the browser, which is just going to be amazing.

A

um I'm very sorry about that kind of thing and also like to choose your own adventure like you should be able to build this thing like yourself, so we have like all these little components that we can use to create these distributed applications, um and you should be able to pick and choose them and combine them together in a way that makes sense so trying to uh make sure that we haven't like baked in assumptions into the interfaces we exposed and that kind of thing very conscious of running out of time.

A

um Yeah it's gonna be amazing. It's gonna be so much fun!

A

Oh and that's the end. That's the end of my talk. uh I've run out of time, so I mean that's it. If you wanna come and find me and ask me questions afterwards I'll be around. I'm alex. Hey! Can brain? Thank you very much.