IPFS GUI and Browsers Weekly, 21 Aug 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: MFS-based cohosting, HTTP multiaddrs - IPFS GUI and In Web Browsers Weekly, 2019-08-21

Description

IPFS mirror: https://ipfs.io/ipfs/bafybeifaxanbf6salkmygjbvcowd667wxbeunqs66jhg7qrcxcdmgcmw4m

A

Okay, welcome to go and in your browser slick, likkle. This is 21st of August 2019 and we have short-staffed called this week. There are some agenda items we will go to.

B

So Terry and the trick are with me: the trick is adding some agenda items so maybe.

A

Maybe I'll go with the first one. Should I share my screen: yeah, okay.

A

So the first item on the agenda is co-hosting I hoped for anak to be on this call, but so I we wanted like probably discussing in depth, but I will give a quick update on the discussions we had in the past week since the last column. So the idea about co-hosting websites, maybe I, make it.

B

A

Okay, so the idea is both ipfs, companion and ipfs. Desktop could provide a better alternative to pinning of websites, and we named that co-hosting. So the idea is that when you have a website that you care about, there should be like a toggle to join the group of peers that contribute bandwidth for hosting the content of that website. And the idea is, it should be like initially we. The idea is to use NFS for that and do not introduce any custom like configuration and things like that.

A

I wrote on the idea: I guess maybe too long, but the shortest shortest idea is that if we come up with convention for naming a path on em FS for tracking or hosted websites and all the historical snapshots of those websites, we actually don't need to introduce any like configuration files and things like that, because if we have let's say co-hosting a directory and inside the inside of that director, we have either IP NS, hashes or DNS linked DNS linked names as directory names and in each of those directories.

A

We would have sub directories with a timestamp of the time when we fetched the specific snapshot and I. Guess that's enough for us to have this like distributed orchestration of co-hosting cause.

A

When we have this directory structure in em FS, then both ipfs, companion or ipfs, desktop or maybe just a common line bar script or some tool running in the crown is able to check em FS using like ipfs files, LS command and return a list of co-hosted websites and then listing contents of the direct specific directory for a specific domain and sorting them by timestamp.

A

We are able to tell when was the last stop shot fetched or when was the last nap shot refreshed and then, if we agree that, there's like a will refresh each 12 hours or some other time, then every application responsible for refreshing co-hosted website can just go there. Sort all the snapshots check the timestamp of the last snapshot of the latest snapshot, and if it's over the threshold for refreshing, it will just refresh the website copy the latest version to NFS.

A

If it's the same as the old one or as the latest one it just bums the timestamp, so it renames the directory and on and actually that's all needs to happen. So we just we just use NFS for that. No text files, no configurations just this compassion and why it's where I like it is because it's simple it does not introduce any new config files and in new formats, and then it enables us to experiment with user interfaces for managing Co hosted websites.

A

So people are a would be able to both use like ipfs, companion, user interface or IP first desktop, but at the same time they could just go to file screen in a web. Ui go to co-host at co-hosting directory and just manually, remove all the snapshots or just remove a specific domain name. So if someone removes co-hosting example directory, they both remove old snapshots and they just remove this entire web site from being refreshed and tracked by all the sudden orchestration.

A

So that's the idea, and the idea is just both IT first companion and IP first desktop can make implement this in their own pace. We can, of course, like we should synchronize and agree on like naming labels of or something like user interfaces, but basically that's that's the idea.

A

Are there any questions on this? One.

C

Yeah, this is really neat because I feel like it does.

C

It gives me kind of like that, the local and offline local network scenario, so you know these common cases where you're say we running an offline workshop or something like that. One person can download the website, then other people can get it from the other people to have it on the local network, even if you're not connecting the Internet so like some.

C

This enables, at the UI level, some very to be sick, use cases that we've talked about for a long time, but aren't reasonably doable right now, or at least the foundation for be able to build on some of this, and it, it seems like something that would be useful to do is to speck this out clearly, especially because the goal is some level of interoperability between implementations and different nodes operating on it.

A

Yeah, that's a good question where, where we should expect something like that, because that's so like the way I think about this, is we implement this sort of like in user land? First, it does not like require changes to go ipfs or JSA PFS. We basically just use em FS built that stuff on top of amethyst and then, if, if it's like good enough or we need more control, let's say to have a better control of the refresh rate or things like that.

A

We could think about like spiking it out and moving it to ipfs core spec, so the moving it from like user land, something implement a PFS desktop and companion to something implemented. Natively just like amethyst itself is bioactive SMGs, ipfs I'm, not sure like. If at this user land level like when that spec would leave I I even.

C

If it lives in this issue- or it just has an experimental directory in companion, repo or something right like but I, think having, especially because the goal is to have multiple nodes be able to operate and have the shared understanding. That's why I actually like it should be. Probably expect that that labeling and naming structure should be expect up somehow or.

A

Maybe or maybe we should create like a dedicated to people like co-hosting experiment in ipfs Shipyard, and we could just keep like an aspect therein with me or like spec directory, as that would also act as a good point for synchronization, because right now, if like me or connect from their IP first desktop, has a question about this. When we don't have like a rig like project agnostic place to cause this right.

C

Yeah I know that sounds like a good good solution. Yeah.

A

So, probably after this call or maybe tomorrow, what.

C

I'm, so if let's say I am on on the same local I'm on the same subnet, but we're disconnected and we both have ipfs nodes running so like what would the commands be for me to identify what sites what you have in your co-hosting store.

A

Yeah, so actually people are not able to browse each other's and Ephesus. However, your node announces all the see IDs you have in your repo on the DHD and also if someone on your local network is asking you for a CID that you have you just provided, so it would sort of work in an implicit way. So if someone is interested in the same website, you have in your store, there's no and it's in the same like snapshot or like most of the website did not change, and you have most of it.

A

So actually, there's no communication or no signalling needed apart from what's already built into ipfs. That person would ask hey, I, want to browse example.com and start like resulted to CID and, like start requesting blocks and you by the act of having those blocks as a part of the snapshot you have in the NFS. You would just provide it well.

C

So I so companion in that case, would would hijack the request for example.com or intercept it, see that it has that blocks or that in its local co-host store it ffs. Then it would love those blocks up. So let's say- and this is just a single node scenario- I've already co-hosted, example.com I'm, now not connected with the Internet but I make that request the companion loads it from my local I'm a fast first and then from the local box, store that how the local loading scenario would work. Yes, yes,.

A

So, basically, like loading website from your local TFS, not true HCP gateway would just it would just work, because okay having this website as a snapshot in your m, FS is just a way of keeping that those blocks around to keep them from being garbage collected right and that's like the only reason why, like the only like, effective functional, functional reason, why we have it in MF s, apart from like managing the list of co-hosted websites right.

C

How do things get in that list? How do I add something to co-host? Yes,.

A

So that's when so either user interface, like ipfs, companion or I, can first desktop comes in I. Imagine like in a TFS companion, it's easier because you have like you can add some new interface elements. The browser, while.

C

Somebody's looking at a webpage or whatever yeah yeah.

A

There's like an icon on the browser toolbar and you can like co-host this website, you don't even need to like load it actually from ipfs. You can just like mark that you want to co-host it and it will be added to your local node for aquafers desktop I. Imagine it would either it would be really responsible for refreshing and like managing, but it uses web UI, so I think on the settings of the web UI.

A

We would have like an echo hosting experiment which the text that you have this hosting directory and it lets you like add domains or like URLs of websites from there. But it's like just a new I. We can add on top of this, how.

C

Would this work in embedded, nerd scenario, so, let's say I'm running am better known in companion.

A

For companion, its companion is actually Beck and techno stick sort of so both HTTP API exposed by a local, NGO, ipfs and embed the J's ipfs running. In brief, let's say both expose the same programmatic interface. So if you add that a la UI element just like co-host this website, it would work the same. The problem would be like the storage, the storage or in embedded node. If it runs in a browser extension, then we have like an unlimited storage because there's like a flag browser extension can request.

A

However, if you transcend on a like a regular websites, then it will be limited by the current limits in browser.

C

Yeah interesting yeah I'm, really interested in an extension level embedded no use case for this, because I feel, like that's the that gets us over the the install hump for having regular users install separate software. Besides companion, I.

A

Mean it's it's. We are slowly getting there. There's a PR. It's like working progress to a to actually like implement and enable the garbage collection in je and by the J's ipfs like in J's ipfs in general, because right now.

D

A

Don't have garbage collections, so you add stuff to your node, but you I you actually there's no mechanism to automatically like purge stuff. You did not clean or did not put in the NFS yeah.

C

A

We need to like to solve that sooner than later, yeah.

E

C

Really like to do something like just build a bookmark, a URL and then tag it like a Firefox house, bookmark tags just tag it with code, IP, plus co host, or something like that, and then it just goes whatever I haven't made bookmarks today, yeah.

A

Yeah Firefox API for managing bookmarks is much nicer, like yeah more options than they would have in chromium. So that's sort of also so for that tangent shall like it's attracting discussion, but like the problem with the way we implement our features is that we sort of need to look at chromium based browsers, as as the baseline yeah.

B

A

Are a lot of features very nice features we could implement in Firefox, but then we diverge code base and we need to like test and maintain effectively two different code bases. So so far we've been pretty good at like keeping a single code base, but that's that's always a struggle. Yeah.

D

So if you're picking sites to co-host, are you looking at real human, readable name.

A

Yeah, that's that's the plan, so the plan is, if we you go, let's say two dogs, ipfs IO or like Turkish Wikipedia right, those like regular Wikipedia on ipfs that arc or dogs ipfs io name and in the web browser there would be like an icon or a position in the menu menu after clicking on ipfs icon to co-host this website.

A

D

Maybe this is a silly question, but does that mean if I'm the one who makes the website first I have to go like buy a domain from Namecheap or whatever before then the people co-host my thing with a nice readable name or is there some way to get a free is like IP, NS or something? Let you make a nice readable name, that's just an IPSS plan that would work for the same thing. Yeah.

A

So right now you need to own a domain to set up the DNS link. However, like I hope, there will be a service that gives people some domain under some like, like generic domain, which does not require buying canned domain. It would just I think Jim created a very interesting demo when you use like geek app for user authorization, so it does not require any additional accounts.

A

It just gives you an input when you put the content identifier of your website and you submit it and you get a domain name, but that's like a separate, separate topic. How? If, if we, when we implement this, then we can think how can we make it easier for people to for website creators or people who want to create a quick website to get a nice domain Hugo for as a part of his IP NS work created, something that was called I, believe alias or label?

A

The idea was that we would provide a domain name under which people could specify some label when they published IP NS and when you published IP, unless you all you'd get DNS link address for free as a bonus.

A

So that would not require any like third-party service. It would just work from command line. It would be like limited to like you would still have to take care of pinning like keeping your content alive, but we would provide the domain name. So there are like multiple ways of handing.

C

You give an example of like what that domain name would look like in that scenario like it was under a pre-configured root domain. We that we provide, but then people would get a certain mean yeah.

A

Yeah, so that would be like when you publish something type in, as you say, let's Dietrich stuff and you type that as a label, and we would give you like Dietrich. Stop that, like websites that ipfs I or probably different domain like totally different domain for this purpose for security reasons. But it would be like frictionless if you quickly want to share something with meaning URL instead of gobbly or see IDs.

C

But then, in reality that dns would never that readiness request would really never happen right, yeah. So the way it's released in that scenario when you're loading it through Campania in the moment, yeah.

A

So like the the DNS would have to the DNS txt lookup, for which we use for finding out. If this domain name is backed by ipfs, we do DNS DX, you look up so that one DNS lookup needs to happen. But after that you don't actually need to send any HTTP requests to any server you just redirect to local gateway, and you load it from my DFS and yeah.

A

So, basically, just as summary for this discussion is that the co-hosting feature would enable people to like, pin and follow DNS linked websites which have like human, readable names and the topic of how people publish under human readable names is like a separate one. We can tackle that like separately, but when.

C

You say Deena's linked websites, though, so it's not. We can't do it for non DNS link enabled website. Oh, we.

A

We can do that for like websites published type in asunder', your peer ID, hash, so sure sure yeah so without a human, readable name, but I want this feature to work for both because, like most of people who are interested in human, readable names, yeah still like stuff, like, let's say, Linux repositories or like package manager repositories could be published under IP NS, with like peer ID instead of human readable, and some people just would copy that peer ID to co-hosting directory like created the create a directory with that name, and they would automatically become co-hosting entire package.

A

Manager' three things like that: yeah yeah.

C

A lot of really interesting use cases unlocked mm-hmm by this. This is, which is one of the reasons why I I'm really interested in seeing this kind of written up as a as a separate aspects of it. Those different people that are trying to implement for those use cases can kind of evaluate at a high level what this unlocks for them and give feedback. Yeah I mean from an experimentation standpoint, yeah just ship it now an experimental for. Oh no.

A

But I totally agree that we should like create that repo and create a spec cause apart from a cliff as companion and I, give as desktop. What I want to have is just like a bad script. Someone can just add the cron and add it to their server and that that takes care of like refreshing, their websites, our website their care, so they would run it in a headless mode as well. So at least we would have like three implementation. Three implementations of this co-hosting scheme, yeah.

C

Yeah that that the fact that there are three different implementations is where you're gonna shake out the issues, I'm very very interested to see how how that concept works across multiple nodes, yeah.

A

I really like this approach that we all sort of like growing this in userland without like take it, because if we would design this as a part of like the car, that would be like much longer but much longer time between design and like actually shooting stuff yeah.

C

But I mean I'm kind of interested like how much more, how much more of the core do. We want to build out anyway, right like at what point how much, how fat do we want the protocol to be oh yeah.

A

Like I, really like this approach, like NFS based approach, because it does not actually need to be uplifted to curl, it could just stay in a my fantastic. It's just a convention, yep.

E

Yeah, so that's like an update.

C

E

C

It's a it's a really good, like kind of dog fooding vector for the protocol as well right, like I, think one of the things that people don't understand is that things like m FS. Well, no, they don't exist but where they fit into the picture. I think most people's picture is just that narrow continent address you access, something by it's the ID, that's it you know, and therefore they think that you can't actually build applications on top of the protocol. Yeah yeah, well that that mutability makes a lot of those benefits.

C

Uture trading off benefits at that point, which is, I think, one of the things that is extra unclear for developer users, who are trying to figure out or their IP fest fits their needs or not. Yeah,.

A

I feel this visual of looking like quickly just this visual of having like a directory with a lot of snapshots. I feel that could unlock some pathways of thinking about like creating caps or like managing data using KP FS, because that's basically a lot of people like ask. How do I handle like versioning ipfs and you could just create the right snapshots in em, FS yeah.

C

A

C

Actually, that actually should probably be like that at the fqdn. Therefore, for that domain, right, Micah, like we'll probably I, need to also make a convention for how the origin is serialized into a path structure. No I, only existing standard around that yeah.

A

Yeah but yeah, so that's actually a good good idea. So the thing is: if we put stuff on I'm on em FS right, so there's like this example.com and under that we got like a long list of it snapshots. Then you can just copy CID of the route and share it to someone and you go out like the full history of this one website that you accumulate it over time.

A

Yeah. So that's that's! Interesting are.

D

You not, then, like storing a gazillion files, because you're like every day, you're multiplying.

A

Yeah, so if entire website changed then yes, but usually only a small, it's.

D

More like they get to get concept of, like oh yeah. That word changed, but we're not during.

A

The whole version.

D

Of the page somewhere, okay, yeah.

A

Yeah, so that there's like a dead duplication at the block level for free when we do this yeah.

B

Cool I think Dietrich froze, or is he just muted I think he dropped from the call.

B

Let's give him a minute.

B

Yeah, let me like quickly check.

B

A

All right so more or less co-hosting.

A

The second second item: oh yeah, here's the tree a.

C

Dietrich I think my you know that is not great yeah.

A

I quickly move to the next one.

C

I had some rapport questions.

A

If you have questions feel free, I did not move yet.

C

Keep keeping that video off to keep my internet? My bandwidth usage.

A

Door, alright, so anything else on co-hosting and questions I can save it from them next time, yeah, maybe well. Next time we have a canned repo with some specs and stuff. Alright. The next item is oh, this is a like a hard hard cookie. So.

A

Http addressing is done using URLs and.

A

In ipfs and the p2p echo system, we are using multi others. The problem is sometimes we want to represent a new RL of HTTP service. Let's say like HTTP API: we want to use, we want to represent it using multi other, and there is a problem that conversion from URL to multi other, especially for HTTP URL, is lossy.

A

We it's not one-to-one mapping and there's a discussion we had about HTTP protocol I wrote some notes from a meeting if anyone is interested in this, but the short description of the problem is that we want to support the NS over HTTPS and all the DNS over HTTP endpoints are on HTTP website, which includes a domain name and then a path.

A

So that's a problem because, right now the HTTP protocol does not take any argument and after long discussion we realize there's a generic problem around multi others how to represent protocol specific parameters. So that means, for example, when we talk about HTTP HTTPS, which is HTTP over TLS, the TLS itself has something called s: ni s, ni header, which tells you which tells the server which hostname it you want to talk to and then on the HTTP level.

A

After, like inside of encrypted tunnel established by TLS, we can ask for a different hostname using host HTTP header. So that's something called domain frog hunting which can be used in censorship. Circumvention when you ask when you connect to remote server and you ask for one domain and if someone is looking on at the packets and does the deep packet inspection, they look at TLS handshake and they see as a nice s, ni field saying.

A

Oh, this person wants to talk to this server and then, when the secure tunnel is established, HT actual HTTP connection starts, HTT discussion starts and then client might ask using HTTP protocol for a different host name, which right. So that's probably the most exciting use case for this apart from Venus over HTTP, so DNS over HTTP is using the same domain name. However, it's using a custom path, which is the same class of problem.

A

We are not able to provide a custom, hostname or custom path when we specify multi other for HTTP service, so that's more or less the problem. Space short term use would be to be able to specify the NS over HTTP or any other HTTP based web service using multi others instead of URLs but like in general. It's not HTTP specific problem we may have other protocols that would accept, like customization of the connection, would have custom properties right now.

A

We have no way of specifying like when right now we have just this so right now we have let me zoom in so right now we have just yeah I want to connect to this IP using TCP on this port and I want to talk to it using HTTP. We don't have this part, so I can connect to a web service at a specific port, but I'm not able to provide custom hostname I'm, not able to provide custom path.

A

So I can only use web services which expose the API at the root of the origin and I'm not able to use things like basic out or set some cookies or maybe API keys in HTTP headers. So it's like a problem problem problematic space for us. If we want to smooth the others more and more, especially in a web-browser context, yeah and.

C

I'm surprised this I mean this problem hasn't been unblocker, the stuff that we want to do so far. Yeah.

A

So so far, we've been just using web services, which were exposed at the same hostname on the route. That's how most of things work. For example, in J's ipfs we have an option to customize location of preload nodes and those are specified using multi others. However, those multi others look like this. There is no path, it's just like domain name and port and the protocol right all.

C

Right you working so are you proposing changes to the motor, a multi, I, respect, yeah.

A

So that's an open question: how to represent protocol specific parameters right now, it's not possible and we during the call we had last week, I believe or two weeks ago we looked at some ways how to cement like how to extend multi other semantics, to enable that and not make it like HTTP specific, but make it possible to represent custom parameters for any protocol. So there are basically two ways we come up with.

A

One is to add this like bracket notation in which the parameters are comma separated, and that, like this domain domain, frenetic I mentioned, would look like this, so you connect to a specific IP. Let's say something running in I'm, not sure. If clouds have cloud providers allow domain fronting anymore, but you could run it and like in somewhere else, so you connect it over TLS. You ask for this host name. However. Inside of encrypted tunnel, you ask for a different host name and then you could like add the additional token for some web service. I.

C

Mean you know we're just getting up serializing JSON in there right so.

A

That's the problem: how to make it, how to make it like to feel native to multi other spec right multi seems a little seems a little tail wagging the dog there yeah. So that's the problem. How do we represent parameters? One is do something like this, which looks ugly. However, it keeps like the protocol segments intact. It's still just one hope in the path.

A

Another idea was to introduce like a special purpose protocol, which is like key value and which is applied to the previous protocol, which is messy in my opinion, I like if I would have to choose something. It would be something like this, so it's just like my psi that it's an open coffin problem and if someone has any better idea than this feel free to click on this link and state, your ID other yeah.

C

Well, one question: I have is like why why multi Hatter.

A

The idea for multi other is that we can encapsulate arbitrary paths over like multiple hopes of multiple protocols right.

C

Sorry so I guess maybe that wasn't the question I meant.

A

I mean I can for web service specifically or like for web services. You mean, or do me yeah I, guess.

C

I mean for yeah like yeah, so if feels like we're bumping up we're bumping again up against some design constraints that multi adder yeah put in there years ago, yep and that aren't meeting the needs for more sophisticated protocol usage yep. So that's not why multi otter, but maybe like why? Maybe we should just change multi other.

A

Yes, so right now turns out it's like a very hard problem. It requires basically like extending the multi other spec so for now, I believe when we will implement DNS over HTTP and go or J's ipfs will probably use URLs if they're will add like a configuration option in your go: ID, Affairs or Jessica. First note where you can like customize the DNS over HTTP provider, and that would be like regular URL and maybe in the future.

A

We will also support multi other in the same field, but we don't want to like block implementing DNS over HTTP to this, like what the other discussion yeah.

C

I like that, I like that idea of just using URLs in this case, it simplifies a lot away a lot of these questions where return to shoehorn a really complicated set string, representation of protocols, relationships and expectations into multi error, which isn't really designed to do any of that yeah.

A

And I I, agree and I also would like to even if we don't come up with a good like way of representing this. I would really like if someone come up with another use case for this apart from age like web services, that want to specify custom host, name and path and like because right now, it's very HTTP, centric and I believe we. We may not be able to solve this in a clean generic way unless we have at least one other use case when we want to provide or override protocol specific parameters. It.

C

Might be worth talking to Bernie, because bluetooth has a whole bunch of like clear metadata that you can provide around with its connections in order to specify the nature of the requests and all this other stuff. Yeah.

A

That sounds that sounds like a good idea, yep. So that's more or less what I wanted to mention here and kinda related. We have two libraries for converting between multi other to URL, to your eye and from your eye to multi other, and both libraries are now part of multi formats org.

A

So those are like official now and those are libraries for converting like if you have multi other of this would like simple web service, and you want like regular URL.

A

It's it also like if you don't specify HTTP at the very end, and you have just TCP port, it assumes HTTP by default code. That's what's like at least in jail, and people been using this and they had to manually slash HTTP here, so we default to HTTP by default, and but you can like to disable this behavior if you want and for another direction, there's your I to multi other, which is also lossy.

A

So if you have, if you have a URL to a website which is using like DNS name and HTTP- and you want to convert this to all the other, the problem is, we don't have actually like a generic DNS protocol. We have DNS for and DNS six. We also have DNS other, but this one requires additional DNS link, txt lookup, so it's like a lossy conversion by default we assume DNS, for so when you convert URL to a website to multi other it. It just assume DNS, for you cannot write it here.

A

Some people are using this as like a bridge if they don't want to mix URLs and multi others in configuration of their app. Some people just want to use only URLs for everything or only multi others for everything, so those libraries are mostly used for that I.

A

Believe, that's it. That's the update on this. The trick. Do you want? Don't have any questions for this so.

C

No all right, the problem seems to be addressed by the previous issue, which is the fact that it was lossy in both directions. Yeah.

A

Yeah, it's not, and those libraries are the best we can provide right now to like ease the pain, but you still need to be aware of how what's what's lost when you convert from URL all right next one how to cover more of the text matrix yeah.

C

So this is, you know the thanks for adding the companion bits into that matrix. One of the I think we want to probably get to more of that being covered, but it's it's like it's pretty it's very, very empty right now and and that that's a little concerning yeah and I. Guess you know how asking you know.

C

We probably have this conversation when there people from all the different parts, web UI and desktop and companion about having a plan to fill more of this out with something, even if it's just issues tracked, so that people can understand that. There's part of the words that we know we want to do. Yeah, good idea, yeah I, believe we're all in turn. On till next quarter, yeah.

A

I believe there's like a either discussion on here, unlike her look into having a daily running a benchmark for like jeaious and go to see if there are any regressions so nice, those tests that we have here, let's say like when there's a new PR emerge to go IPO festmaster.

A

We could have like a test suit running once a day to tell if it breaks web, UI or companion, because we're do is a small subset of specific api's and similar ipfs companion is also using a small subset of AP is, however, in the past we had situation when there was like a breaking change, or there was like a non breaking change, which turned out to be breaking due to the fact that different browser vendors yeah he run the same JavaScript differently turns out so yeah I totally agree.

A

That would be very nice to have this safeguard right now. The way we do, those, at least from the companion perspective, the way we handle this is when Steven announced announces. There is or Alan that there's going if s or jessep EFS release or release candidate, like I I, usually do manual test smoke. Testing against compile just ensure the API does not break in the past. Well, we had the very first version of ipfs companion, which was using her visual handle as decay.

A

The good thing about that time was there was a very nice way of orchestrating were like browser running browser extension and it gave access to like low-level access to tell if how the browser behaves when we move to web extensions. Nothing like that existed, but it's been some time so I believe it's worth like. Looking at the space, at least for a keifa's companion to see, are we able to run like actual tests like tests in life, Firefox or life chromium right, yeah, cuz right now, the test should we have just like I listed here.

A

It's end-to-end functional test. So basically it's like a subset of unit tests. We don't like test everything, but there are like hot cocoa, puffs, puffs related to like redirects or puffs related to the way we normalize protocol handlers to ipfs, puffs so or the way we handle DNS linked, lookups or or caching.

A

Those things are covered with tests and those tests run. We have like CI, however, those ran again like those just run in karma and in note, and not in actual browser extension yeah.

C

A

So that's problem.

C

Chris Chris Waring was looking at setting up setting up a browser, stack open source account which would give us free access to real browser testing. So that might be something that and they have CI and stuff set up. But I don't know about how much support they have for running with web extension. Yeah.

A

I think some I think stuff improved I need to just revisit it cuz in the between the time we had to switch to web extension, and now things like headless, Chrome and headless Firefox happened, I'm, not sure if those in like how useful are those when you test web extension but I, know.

C

It's it's super useful, so, like I wrote a compatibility layer for the puppeteer API to work with Firefox, so I could run tests against both Chrome and Firefox with the same skirt and.

D

C

Now, that's that they're implementing puppeteer support natively in Firefox and that allows you to do those types of operations. Sorry.

D

Didn't interrupt I need to drops like a local offline collaboration Karl, which you're both welcome on. If you want to join, and we should think about whether you aren't talk about the co-hosting on one of the coming months, Paul is it based on what you just said earlier. It sounds like it could be an interesting fit for that. Oh yeah.

C

That's that definitely I mean probably too early yet, but when, when yeah.

D

Yeah, when you're yeah, okay I, will calculator right, yeah.

E

Yeah testing yeah there's a lot of surface area, mm-hmm.

A

Yeah but I I believe, like the problem with testing Jess I prefer to go or go idea phase is that those tests already take a lot of time. So that's why I like suggested to piggyback on this, like benchmarking thing, which way, which would run like once a day and then send a report if it's like, if the built of benchmarks over built of tests against our GUI apps crashes,.

C

Yeah really good idea: mm-hmm yeah you're right, like especially the volume of commits and stuff. It's definitely not something we need to run per commit yet, but the ID, knowing once the day, will really narrow down many issues and let us know in advance yeah.

A

I mean like those tests that safeguard against, like the desktop or companion would be probably could not like. They would not take much time unless we want to ensure, like the entire API.

A

Now that we probably could make it run short, but it's not something we want to add two regular build. It would be something separate.

A

Yeah I'll yeah: it's something I need to at least for the companion I need to see if we are able to do like actual tests in Firefox or Chrome.

A

For jeaious ipfs I've been like writing. Some patches to Jess, ipfs and running them like running can Toyota suit local. He takes a long time so there's a switch to just grab specific tests using a lick in some string like I want on the tests which have like DNS, name or stuff like that, just like not wait, half an hour or like 15 minutes for tests to pass.

A

So it's not like. We would have something similar for desktop or companion, but we would for sure test specific code paths, yeah.

C

Maybe what I'll start doing is I'll add an agenda. I am for each one of these cuts items in the list for that many weeks of these meetings, mm-hmm so next week, I'll have people write out what the smoke test would be for each one of these things and a link to issues and then maybe we'll break this up into I'll row by row. Basically slowly attack it over time. Yeah.

A

That's a good idea, or even like just start at just one.

A

Yeah I guess that's what we yeah.

C

Maybe I'll file an issue each week on one of these yeah and how the group discusses it. Yeah.

A

How do we like test stuff right now, yeah, okay,.

C

I'll see you later I'm going to join the local offline meeting, yeah.

A

I'm not able to join this week, however, like the next next next month, because I think local call is monthly right yeah next month. We'll probably do we talk about the co-hosting cool.

C

Yeah I think that that would be very interesting for that group. All Right see you see.

C