IPFS SIG - Local Offline Collaboration, 18 Dec 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Local Offline Collaboration Monthly 2019-12-18: Braid Protocol, NYC Mesh, High Social Impact Apps

Description

On our December 18 call we explored the Braid Protocol with a presentation from Michael Toomim (00:45), learned about NYC Mesh's local chat app built on IPFS from Oliver Fisher and George (22:34), and discussed high social impact applications with Arkadiy Kukarkin (33:18).

Learn more about the monthly calls of the IPFS Local Offline Collaboration Special Interest Group: https://github.com/ipfs/local-offline-collab/issues/25

For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS

Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5

A

Hey everybody, this is Terry today is December 18th, and this is the ipfs local and offline collaboration group I'm having our monthly column super excited to get started and a few different demos today, so we will jump right in Michael. Do you want to share your screen? Just tell us a little about braid.

B

Sure, let's see if I can find them buttons for that on.

A

Mine, it's big green one at the bottom Center.

B

B

Okay, can you see this.

A

C

Okay, so, and how much time should I go for it? Terry here.

A

Is ten minutes.

C

All right yeah, let's do that. Okay, so um so I've been working on braids no braid is an attempt to decentralize the web using standards. Okay, so I want to I've prepared this talk as a bit of a pitch or an argument. I want to see if you guys agree or disagree that we can centralize the web just through through like a standards effort, and so we get to take this back.

C

What was kind of like the web like used to be these closed networks like AOL and CompuServe. They also had a lot of the features that we have on the web now like shopping and chat, and forums and stuff like that, but they couldn't connect to each other. There's these giant, centralized monoliths and the web was able to decentralize it was. It was a decentralized alternative that could out-compete them and the web out competed them because it there is two things that it did. It made it easier for people to add new content.

C

So when you, it was easier to throw up a website or in a web page, anybody could do it much easier than it was to convince the CEO of AOL, Steve Case, to add your content AOL, and that meant that all of the like they're about million programmers out there on the web, they're only you'd only have maybe a thousand programmers in your company and a million programmers is gonna, be able to make a lot more stuff in the thousand programmers, and so that meant that a lot more content was being added.

C

The second thing that that the web did and the web was able to it was easier to do that partially, because not only do you have a standard, but you have these libraries that made it so you didn't have to write most of the code if you're gonna replace AOL, that's a lot of code, but if you just want to put up a web page, all you have to do is write the HTML everybody already has browsers.

C

There are already servers out there, and so that makes a developer's job a whole lot easier to add new content. Now we're too similar we're at like this at a higher scale.

C

Now websites themselves have become the giant, centralized entities, and so my thesis here is that we're gonna be able to decentralize these websites by extending the standards again and adding new libraries that are going to automate stuff and make the developers lives easier and then we're going to be able to out-compete the thousands of programmers at Facebook with the millions of programmers on the web, and it's gonna look something more like this. You guys is this: can you see the right side of the screen? I, don't I'm, not sure yeah I.

A

Can I okay.

C

Good, okay, okay, so I'm gonna go quickly now through. So braid is an extension to HTTP. That adds some new features. It makes it much easier for you to make websites and it makes it easier for you to share the state within web sites and that allows us to build more of a mesh okay, so I'm gonna.

C

So the problem that we're solving is that the web- just it didn't add enough I'll, just take you through so the web was designed for static pages, so HTTP transfers some HTML from a server to a client, okay, and that made a lot of sense when pages written by hand and they're. But like what happens, if the page changes they didn't have any way to update the client when the page changes, so they just added this reload button.

C

Okay, so this is gonna, be a common theme, and that was like that made a lot of sense at the time. When pages. Look like this you're writing, HTML by hand they're, really not changing that often yeah I just have a user click, reload no problem, but then pages started changing more and more. We started getting these databases that would generate the actual page and they might change like every week or every couple of days or you know when someone reloads it, and so then you had to you started having this new model.

C

You have a database down here and then in order to do that. Well, you didn't made an MVC framework and that was like okay. Now we need a way to structure this changing data model view controller. Is the pattern for synchronization for object-oriented programming that was developed at Xerox PARC, so one way or whenever we see scene, MVC, I think this is a way to synchronize. You have some data in the model you're going to update multiple views whenever it changes over time pages started, changing more and more so.

C

2011 like this is a feed of this is just a facebook feed snapshot it every day for I'm some student for a month and then JavaScript started happening. So now you could pay change the page on the client without hitting reload, and that was pretty cool, but you also wanna be able to get data from the server. So then we added extra XML HTTP requests and you kind of know that that API wasn't really thought through cuz. It's called XML uzuki request.

C

We don't use our xml anymore, and now we have pages that are kind of they're changing all the time and you actually expect them to be live updating real time as people change stuff somewhere else, but there's still this reload button and what does a reload button do now? Well, it's just like in case the code doesn't really work because we have piles and piles of code and when you write a web app now you need all this junk.

C

Then we add through and react, and this is why web programming just totally sucks today, there's a pile of junk, and all of this is here just to handle change. So this is what we're gonna solve. Okay, this is all because HTML HTTP itself just never handled change in the protocol, so instead we're like working around it with all of this crap and every time you build a website, you do it in some non-standard way. You just figure out a way to do it and everyone has a different way to do it.

C

None of our ways are compatible, and that means that it's much easier for us to access data in our own site than access data on someone else's site that we're not sharing we're, not collaborating, and we just build these silos. So the braid protocol extends to http with synchronization so that you don't need any of this crap we're gonna throw in, and instead we're gonna actually do. Synchronization super super.

C

Well, it's a hard problem, but we know we have CR D T's, we have operational transform, you have version control and the braid protocol supports every month all these methods of synchronization, it's agnostic to the particular one, but it gives you, but you can get all their features, and that means that so on, the left is how we build websites. Today we have this whole stack of stuff and each one's different, and every time you build a website.

C

You have to wire together everything in a different way, with braid HTTP itself handles the synchronization, and so every every piece of state you access it. The same way. Every piece of state has a URL, and let me show you what that means.

C

So, but here's, let's say have a braid website: every black dot here is a URL and you can access it from the client from the server uniformly, and that means that you can also access some data on some other server just as easily as your own server or you can make a different user interface that different user interface can access data on whatever server it wants, and this lets you make new user interface for any website that you have, and every user themselves could even have their own user interface, and so we can get a separation between the UI and the state behind it, and you can create your own UI.

C

So you no longer have like a monopoly power like right now. Just because Facebook has all this data. Everyone has to see their friends the same way, but if we build our social sites on brain, everyone can see their sites. However, they want. This I think goes along with a lot of the local first approaches as well like we're. Seeing this we're seeing people separating the state from whatever is happening locally: okay and when I just drew I, don't know if you could see that transition, but you can also have things peer-to-peer.

C

So every little black dot is a URL. You can access any URL anywhere else. So.

C

To do this, one of the big trick that makes this work super well is great technology, with CRT, T's and operational, transform that collapses differences distances between time and space. This lets you program with state locally or remotely just as easily, so you can access state on any website. You can read and write it as easily as a local variable, and you can do that in the same offline first way as a CR DT lets you do, because any changes that happen on any two computers merge in the same way.

C

So this is an abstract model. It's just like what you're seeing right here. This is what we call a braid. This is the reason why the protocol is called a braid every colored region. Here is a let's see if I can pause it. Oh, no, that's got to click kinda, quick, okay, so every colored region here is a patch, and these are three different computers. One two and three: you can see the network messages at the bottom that they're sending so they're. Sending these little set messages. They have a patch.

C

This patch says replace region from zero zero. With a Z Z Z, it gives it a version ID and it says which parent versions that comes from and these patches are just getting broadcast around the network. They receive them in different orders or different sequences. The each has some text at the top and that text is getting synchronized by aggregating all these patches together and so the colored regions are patches.

C

The reason like this is emerge, and so it merged this Z Z Z AAA, with Z and n and M G, Z and I got Z n, N and ng Z, and as long as every computer merges any two patches in the same way, they'll reach a consistent resulting state and so what we, the the. So this is the the basic model of a Brady of patches.

C

You can fork when two things at at the same time and you can merge together and in order to get consistency, all computers have to merge in the same way, and so in order to do that, we just add something to HTTP called a merge type. The merge type says how two things merge together and I. Think that's the next slide, perfect. Okay, great! So now here's the actual protocol. So this is a put request.

C

An HTTP over here is a get request and we're adding a couple features so we're adding versions, we're adding patches and then with gets. We also add subscriptions okay, so this first first phase of braid doesn't have any peer-to-peer features, but the data model of the braid, which you just saw in that last page, that visualization that totally supports peer-to-peer messages. We just don't have a network transport. Yet okay, this is just let's get that data model and let's extend that into HTTP n. It turns out. Http is ordered, really really close.

C

Okay, so we just add. So we had versions patches and subscriptions basically so in merge types. So I'm gonna walk you through this, so over here on the left you can do a put, and then you specify a version. The version is just some unique string: okay, it's whatever it is. You can encode in here a version vector if you want so different, CR, DTS or operational transforms, will use different data types for versions whatever it is. You can encode it in a string.

C

All the braid cares about is that it's unique okay, then you encode the parent versions and a parent versions is going to be a sequence so string and this gonna comma first string. Here's one with multiple parents over here he has a content type, so this one's JSON and it has a merge type. So sync 9 is the name of the algorithm. That's doing that merge, and so as long as all the clients and Peter and servers implement, sync 9. They can all merge the same way now this put is contained with two patches.

C

Okay, so it says patches, 2 and now the and now it knows that it's gonna find two patches. So here's one patch and here's, the other patch and each path has a has a Content link so that you know how long it is- and you know when the next patch starts now. Here's an interesting thing content arranged. So this is specifying a path.

C

So every Patrick replaces some region in the document with another thing, so this is replacing the region, that's specified with JSON of dot messages and then from in an inserting from one to one. So it's just inserting a nothing kind of like an empty or a single location. It's inserting this, and so this is an array with an object. This is basically a message. This is chat and the person just posted a message to the chat, and here it's now saying that the second patch said that the JSON of dot layed has changed.

C

You're gonna, add this object. Okay, and this is the date with a value of some number, and so this would be like at editing a message in a chat, and then you get a response that says okay, so this is the basic format or that we're adding to put requests and then for a get.

C

The the big feature we're adding is ability to not just get one thing but to subscribe to all upcoming changes until you're done, and that gives that's that's like a key thing for synchronization, and so we have this a similar thing here. We say git, you just have this a pet or subscribe and say keep alive and then the response you have multiple patches coming in and each one is this the same format like over here? You can also I. Think one of these is has no patch.

C

Let's see yeah, this one doesn't even have a patch. This is just giving you a full, so you can just give the full body of the resources. If you want- or you can say, patches call in one or whatever it is, then you can give it in patches as well.

C

Okay, that makes sense guys cool.

C

So I didn't have the demo prepared. Sorry we'll have a demo of really good demo in a couple months, maybe sooner just working on it. So some of the benefits, though so you know the reload button- becomes unnecessary. This the algorithms can automatically guarantee this things are in sync: all updates can get pushed automatically caches, never get stale. You don't have to. We get rid of all these stupid heuristics like max age and HTTP headers, and you have to like get your cache control right or otherwise. Things are gonna cast right.

C

It's just handled automatically, which is really cool network, becomes a lot more efficient. You only send ad. If you know, if you go to Facebook a second time, it's just gonna. Send you a different last time. If a resource like a file changes it'll, always send you a diff, it's never gonna redundantly send you stuff again. You have to write a whole lot code because you're not wiring together things anymore, you'd, like most of the logic that I that we write in web apps is just synchronization logic and this automates.

C

All that this is the 70% is just an I. Don't have any like theory, for it I mean that's the theory for it, but we've noticed this in our just our experiments. We rewrite programs using this model and our web apps and it just gets rid of a about 70% of code pretty consistently and that's that's kind of a cool result. We also get an offline mode for free, which I think is relevant, so you offline first, you get collaborative editors and everything um the server can go down. Your app can go.

C

Well, especially, we don't have well I, don't have the pewter pure mode over WebRTC, but we do have one working in the lab and that allows the server to just go down your peers. Keep connected. You can continue chatting. The server can come back up if you want, or if you don't like that server you can switch to another one. You know someone it can like fork it and okay, cool I think that was probably about ten minutes. So that's the website.

A

C

Yeah cool questions run again, yeah.

A

Let's take a few minutes for questions. What do people want to ask.

D

Right so this is very cool. Personal is somebody that worked on a CR, VP based work and no so challenging that can be work so I guess. My question is so the synchronization bits I think is. Is that made very clear, but it seems like some of the ideas here relates to kind of like almost Semantic Web like contents and the piece that I don't see very clearly is querying so in terms of actually being able to use States from and as a place.

D

So it was, they just push to you as a part of kind of an existing instruction. I can see how that works, but, what's about me wanting to access state that is not already exposed in that way,.

C

So not exposed in that way. So, okay, so there's there's a couple pieces here. I guess one is what if the app has not exposed the state in a particular way that you need and then the other question I'm hearing is querying. Is there a connection between these two.

D

I mean I, it seems like these concepts are related to me. Maybe that's not right so.

C

It's okay, so all are going to dress them both to some degree. So with querying, we don't prescribe anything with querying. You can do the same things to do with HTTP. Okay, so you can just put a question mark in the URL. Add some arbitrary stuff.

C

This is a it's like a key value model just like the web. Okay, every URL is a key and it has a value at the other end of it. The different series of the value is changing over time and we've added the semantics of like a dag of time that, with this braid and the ability to patch and synchronize and get updates now, if somebody said, the second question is like what, if somebody has an added braid support to their website?

C

And you can you don't have to add braid support, you can still use regulation CTP, but you're not going to get the synchronization semantics you're not going to get guaranteed consistency in some situations. You might just want to add a couple of these features of braid, like maybe just the versions or maybe just the patches, it's useful to do patches without versions. For instance, if you only have a single writer, you don't really need versions, you know they're all gonna come in in a certain order.

C

You're gonna put them all in all in and you still get diffs and stuff I, don't know. If that answers your question, you can so you can kind of mix and match the support. You're doing you get different variations of consistency, features or network efficiency, depending on which features you have.

D

So I guess it sounds like you know. If I want to query, let's say so: okay was the Facebook example. I want to query that feed of a particular user by another name, but not the URL of the defeat object. I would rely on some kind of search and polls that exposed to now.

C

Right yeah, you could imagine subscribing to that search endpoint or you could do a search. Endpoint grab the user's name or they. You know the URL for that users profile information, and then you could synchronize with that, got it well. You can synchronize with both yeah.

E

Have you thought about or I'm wondering how this would fit in with like cross-origin? Would we just use, of course, yeah.

C

I know I thought about that too, and actually a controversial opinion on Korres mom I looked into the root of it. I think Korres was added because, like if you've ever programmed with Korres, you might have noticed that it's a pain in the ass and it sucks- and you know, yeah, okay, so I, don't think I think we can actually get rid of it in this new world. Chorus in I did some in my in my interpretation, I. Think Korres is there, because websites were already web servers.

C

Web apps built under the security assumption that other browsers could not access you access a page unless the user specifically went there and that changed when xmlhttprequest was introduced. Okay and so Coors was like an oh moment: okay, oh we just added a feature into our web apps, which allows other sites to access our servers. Well, okay, let's not allow that, even though that's really cool, isn't it well? Okay, let's let people do it if, like we, if they explicitly say it's okay, which means they bake the security model into their app I.

C

Think, anytime we're moving to a new app or new API for accessing on multiple sites. We can let go of that annoying course thing and we could do it like opt out instead of opt in I. Think, like WebSockets, for instance, are much more permissive and the web hasn't broke.

A

Any last question before we move on.

A

All right, thank you so much Michael that was great and I popped. This I took some notes which Michael you should look and see what I wrote down wrong. I do that so feel free to construed, and then now we have Oliver in George. I think both with NYC mash effect was about a local chat, apps they're building on IVFs. Do you guys have something you want to share on the screen or just chat through something.

E

I could share my screen and just give a quick intro to NYC miss.

E

You're back nude.

A

Yeah you're good just find that share button. A few nope yep, almost yeah there we go we're.

E

We're a community network so basically what we're doing just connecting buildings and people directly to each other, with mostly rooftop wireless antennas.

E

We have about 300 buildings connected now across the city, so two super nodes, so this these are located at internet exchange points. So this is where we gear directly with other networks, and then we have.

F

These wireless.

E

Links across the city, rooftop, rooftop and.

F

That um distributes.

E

The traffic for using OSPF for routing so there's two goals or one is connecting people directly today.

E

With the other goal, which I think is a little more interesting, is creating our own network on with internal servers main active, even if the connection to the outside internet goes down one, we don't have any super serious services. You know we have like Wikipedia, Troon I, think some people have personal blogs. George has been working on my chat service and we've been talking about ways. We can do a lot of stuff, so it would be great to just ensure that to you guys and any feedback, Georgiy wanna talk.

F

G

You all hear me.

F

G

A

G

Super so basically, as Oliver said, having a community built network offers really interesting opportunity to us.

G

It's I mean a lot of the broader peer-to-peer services are I, feel like the kind of concept is structuring the internet more like the actual social connections between people, and so reflecting that in the structure of the network, is a really cool opportunity.

G

So, firstly, one of the benefits of having a distributed network like ours is that the resiliency model is.

G

Not having everything be a spoken wheel model allows for better resiliency each as long as we can keep a subset of the network up, we can access the internal network, even if we lose connection to the broader Internet, so kind of from that idea. I was thinking of implementing a chat service that uses IP FS for the storage and distribution and.

G

The starting point was having a private swarm just for NYC mesh I, think they're. A couple benefits ipfs is still relatively new and so the scale running it globally, it's a little tricky, but internally within the mesh, the scaling isn't an issue.

G

It also allows us to function completely, even if the network is partitioned in the broader Internet and that's a really interesting, interesting property. When you consider potential like a disaster scenario, for example, during Hurricane sandy, the internet for certain neighborhoods was inaccessible for days in some parts over a week and back then NYC mesh hadn't really started, but there was a mesh service in a neighborhood in Brooklyn and that was able to provide internet to people in that neighborhood.

G

It's pretty impressive accomplishment, and so basically, the approach that I took was having a private swarm and then having bootstrap nodes inside of the network and so the bootstrap nodes. Thinking of having well-known small computers like raspberry PI's that are connected directly to antennas and that's neat, because you can run on antenna. It's a solar panel, Raspberry Pi as well yeah cuts out as many external dependencies possible.

G

So that's pretty much the architecture, it's pretty simple idea to get off the ground. We haven't gone very far in terms of developing something that is ready for users, but proof of concept is in place. There's.

C

What does a bootstrap node do.

G

The bootstrap yep so fair warning, my knowledge of ipfs is still fairly basic, the bootstrap node when we have a client connect. We specified the bootstrap node for them to find a first peer to join, and so those are just right now. I have a Raspberry Pi running on my node, and so that's the bootstrap node. Oh so.

C

The mr. notice for the the chat up not for the mesh itself well,.

G

For the for the mesh itself, but the chat app kind of piggybacks off of the sorry, the bootstrap notice for running ipfs on the mesh, our local squirrel, okay,.

C

Okay, and so this.

G

Is a piggyback okay.

C

And we're gonna talk about the swarm you're talking about the chat, app you're, not talking about the bio think. What do you thought? Good? The pipes? No.

G

No yeah, this is on top of the actual NYC.

C

Finish networking.

G

Energy structure, cool.

C

A

Some other questions.

D

So it sounds like there's that got a demo. If we can recap, is there a repo or anything like that? Yeah.

G

There is a repo, it's 180 lines of code, I, think Oliver you're.

F

Out of computer.

G

If you want to share it on the command line, you like enter a name, it hits the bootstrap server and then.

G

D

If you could just drop that into the.

H

I went okay, so.

D

It's it's just it's a little hard to hear. What's that background, noise, yeah.

G

Sorry about that yeah.

D

I think this might actually make a good.

A

Sure does anybody have other questions before we move on.

C

Are people using the.

G

H

Kind of plan long term.

G

As we develop, more services on the mesh is to have basically a captive portal. So when you join the mesh, you join a public node. You see all of the different services that are available and I think that'll be a good opportunity to kind of inject those into people's habits.

C

Okay, so this the status right now is like it sounds like this is a very cool idea of using an IPS fast chat, app on the New York City mesh, just because it seems to fit really well with the network infrastructure itself, and it should be pretty robust and you've been developing it to some degree and then at some point we'll be launching it I guess when the the service available and like Paige, it's like there's much to apps, you have.

G

Yeah, it's you know, it's been kind of a piecemeal development effort. There's the project itself is, you know, has a lot of challenges and mesh services are not the have not been like a burning necessity, but it is definitely a something that we're slowly working towards yeah.

C

Cool, um how has it been building it so far? How do you has it been easy or hard.

G

Yeah I mean, frankly, was really easy. It took the basic demo took a couple days. Yeah all of the I have to say that the ipfs interface is very, very friendly and easy to use yeah, especially with JavaScript now and having a uniform interface.

G

Yeah I was surprised.

A

All right, how do you.

D

Separate is that.

A

Thank you very much George and Oliver. That's super cool like how do you want to take it to the discussion you had a night yeah.

D

D

Okay! Thank you. Sorry, the background noise, just like kind of scrambled, my brain.

H

D

So, yes, I think this is actually a perfect segue into the topic that I wanted to talk about. I, don't I, don't have a presentation or anything like that, but there's a there's, a doc that summarizes these ideas and I think it's already in the writing the notes.

D

So, if you're familiar if you're not familiar with a BFS planning process, what we're doing this year is basically or what we've so here is to have kind of a public call for themes for 2020, so kind of Northstar goals for Foresta, inform our development and resource allocation and the idea that I could in which is, you know, very grandiose. We type a little high social impact applications I think this.

D

Of course, we need other kind of hide social effect, things that one can do, but this is the subsets that I saw as a very good fit for the strengths and the mission of ipfs so and by the way, this these thoughts might be kind of obvious to people who are regular participants in AB local offline matters. Oh, thank you Carrie, so I may be preaching to the choir to certain extent, but I just wanted to talk through this a little bit and get some feedback. I did see.

D

If you know anything can kind of come together out of this. So.

D

You know where this idea came from, it has been. I can take a lot of events this year. Events like radical networks, conference here in New, York, a lot of kind of meetups and other events with a focus on not just Dec, but the social implications of the technology and one pattern that I saw emerging is that a lot of folks in a humanitarian disciplines, so people working with everything in situations ranging from refugee camps, so the remotes or underserved regions, inner-city neighborhoods disaster zones, etc.

D

They seem to have I'd, have a consistent set of requirements or like a technological support framework, even though they you know they may operate in like very different scales, very different budgets, there's kind of a pattern that emerges in what people seem to find useful or in I guess the kind of challenges that they face and the similarity sent to be that they work in bandwidth, constrained environments, so there's usually either unreliable altogether missing or very extensible playing to the rest of the world.

D

There is a strong existing community that has specific needs that are defined by the community themselves and not by an external actor, and there is a strong need to be able to share information quickly and reliably in this local environments and finally, the somewhat less common but still I, think very strong requirements is that the tech needs to be maintainable by people within the community that it is serving rather than by outside consultants, or somebody like that. So you know it basically keeps working without the need for and and outside agents.

D

You know being present on a call and as I as I looked at, you know as I as I heard these stories over and over again. It's the the thing that really stuck out to me is that a lot of the properties that these organizations want consistently are at least theoretically enshrines and ipfs values and design goals. So we are, we should really be able to work in these environments better than kind of a standard web stack.

D

We should be able to provide local routing and resiliency and content integrity that a lot of these folks need and.

D

It's not, and the reality is that most a you know, I actually the NYC mesh folks and somewhat weakened this this argument, but by actually building on ipfs for opera environment.

D

That kind of like one I imagine, but a lot of other folks, don't seem to really be aware or actively or akin towards building articles were these situations with which I give us there's a handful that have used that and majority just built on existing web web tech, and basically this made so this I think this is a an opportunity for us to reflect to understand why we are rarely chosen and to perhaps try to close these gaps and make the tooling available for situations where it can make a really dramatic difference in the lives of people today aligned with our kind of greater social impact mission.

D

So there's not really a specific trajectory or agenda that I I have laid out it's it's like there's a few obvious gaps, I think one of the biggest being documentation or examples address this particular use case I think there are a handful of challenges that we know we're facing. I. Think, as you know, as a racing mesh folks already saw, you know you can deal the operates on the main swarm. So a lot of people operating in kind of disconnected or potentially disconnected network segments have adopted privates worms.

D

There's the bootstrap node is clearly it like a single point of failure. In the configuration that's and we see much adopted, you could use multiple bootstrap notes, but that still does not eliminate the most static points of failure, so I think it better, which sort of discovery mechanism is needed.

D

We need to become a little bit more aware off kind of different different connection classes, so we're not trying to connect to things across a really expensive in a LAN link when really what you want to do is work with nodes, this in a local network in things like that, but it's it seems it's just like a very approachable goal and a goal that will have a significant positive impact today, which is I, think something that we as an organization have been seeking, but not necessarily always fun game.

D

So again, these are very abstract thoughts, but I. You know, I welcome. I welcome any any and all feedback.

I

A

I

I believe, there's a in the same repo there's another proposal about like mobile, like focusing more about mobile use cases I'm interested about their overlap, because usually the communities which could benefit the most from like, like the centralization and technologies like that and the local Discovery story. It's always like the Mobile is always in the picture and I wonder if you have like any deeper thoughts about how could we like leverage mobile for those high social impact applications yeah.

D

No that's. Actually. This is something I should have pulled out right away as one of kind of the more obvious gaps. I think a lot of the time. Folks and disadvantage positions are not going to be carrying around like computers, they will have phones, uh probably have over phones for Android phones, not extremely performance, but like battery life might also be a big concern in a situation with our interruption like you might not have a lot of opportunities to charge.

D

So I think this is some somewhere where we are very far behind HTTP sure and I guess. One thing that I didn't really mention, but I feel like I, should Colette explicitly. Is that I think in this situation in particular and for reasons like mobile use case and other practical limitations a lot of the time the people building tools to these situations will usually absolutely simplest technology that actually does the job like I, think more so than in many other situations like people will generally not be building.

D

You know react websites with like tons of JavaScript when people people will be building the simple like most static pages possible or using off-the-shelf things little people there's a lot of like WordPress is just maybe not necessarily the best example of simplicity per se, but it is very, very off-the-shelf and is quite predictable and familiar so I think it's up to us to tell the story as to why we deliver value that justifies using the complexity of something like IP address and I think this is a great.

D

This is the great kind of proving ground that will be a precedent for every other case, where we also it's gonna, be a little bit less less pressure in Adsense, but pushing ourselves through. This will I think improve every other situation as well.

A

Yeah I think that last point you raised extends far beyond these use. Cases like I personally find all decentralized technology to be much harder in terms of onboarding. So there's this like what is the actual benefit right? There's an article I'll drop, a link in here, I didn't interview with Nolan Lawson about this after he gave a talk on it at one of the last offline camps.

A

But in my mind you have like amazing benefits that could make you use something you're not familiar with really super clear benefits or super easy onboarding, and at least one of these has to be fabulous. They can't both be unclear and I see like so much unfamiliar vocabulary in decentralized stuff, just the concept of like hosting your own thing.

A

Instead of using a service, that's already out there just that federated like there's so much vocabulary and there's a talk that someone's writing up now on this, like this kind of beginner friendly language problems from the last stuff, I can't um but I think that's not specific to ipfs, but explaining the benefits plus making onboarding easier and vocabulary more accessible. Those go hand in hand and have to have at least one of them of me. I also just wanted to call out the offline camp.

A

Medium publication you'll find a tab there with a collection of stories about decentralization and a tab there about developing world which clearly, what you're talking about, isn't always developing world situations, but a lot of the constraints that you see there in terms of things I, don't think about everyday I. Don't need to think about how the electricity affects my Wi-Fi, for example, which some folks do, but there's there I think you'll find relevant articles in the decentralization one.

A

There are some articles on people who are living in like these intentionally kind of like the NYC match like we want to have a little a little community, with our only tools that we're serving on our own mesh network and things like that, like internet in a box kinds of things. So there's some reading there and on properly.

D

Yeah I just wanted to quickly respond to your your first points, which I fully agree with, but I also feel like the amazing benefits. Parts can really shine in some of these situations. I think we can maybe figure out the onboarding through leveraging the benefits in a use case where, like our value proposition, can be relatively clear.

D

I think was, you know something like social networking, probably not going to be building that's on ipfs for good reasons, on kind of a normal internet situation, but for, for example, the good archive folks were telling me about a project where they had used with us texts that were scanned and digitized and ocr'd, and they were actually bringing them back to Nepalese villages literally on yak back in these, these the servers and I and they're they're, just using normal HTML in this case, but it's like I can just imagine being able to seamlessly preserve and share these these X between, like a couple of villages that on like opposite mountain peaks or something like that, and you have a way to access the collection that is shared, but it's also validated and kind of transparently available to you, as a user like I, think I think it a use case like that.

D

We can really explain why you want to use this sector without necessarily having this boasts polish onboarding process, at least the quality, the developers so I, don't know, I. Think there's a lot of a lot of opportunity here. I.

G

Wanted to piggyback on that thought kind of a concrete project that I was considering, which, how do you communicate information in politically hostile climates, for example, specifically how? How would you communicate in China and Western China? So we, your and not having to use the broader Internet and being able to transfer information and directly from one phone to another in a private way, seems very interesting and being able to separate the delivery piece from the addressing like I'm trying to send a message to my mother.

G

But we have mutual friends and so I can pass along other people's messages through the same mechanism, and that seems like something that ipfs would be uniquely suited for.

D

We've had some folks try to work on literally that exact project a couple year couple years ago. Unfortunately, the performance and routing ability just wasn't there at the time, but I think it's probably going to be time to revisit that idea. This year, we've done our together.

A

Yeah just say from the perspective of the broader offline first community, not specifically decentralization. There are a lot of reasons to implement an offline first pattern and they include stuff that is like generating money like if your thing loads, faster, your company, makes more money, but the arguments that I think work better across audiences are the humanitarian ones. So I agree with you on that front that you can find a use case in this vein. That will feel more.

C

A

Fuzzy and that's not like personally I prefer to hear about the use cases that come across as that than the ones that come process down with the government down with whatever that. Sometimes the centralization comes off as antagonistic, so I love the idea of using this kind of humanitarian cases. As the example.

A

So we had two more minutes, any other comments on this discussion or other thoughts. I.

D

I guess I just wanted to ask: maybe that and waiting as well just to chime, you know, feel free to chime in a synchronously. That's very experiences, hoping something very much like this and I'd love to maybe try to compile a.

D

Parasitical kind of useless case list in this name, so I would love any contributions. Awesome.

A

And the link to that github issue that are cutting mentioned is in the meeting notes. um Well, so I'm just gonna look at the calendar for one. Second, we meet on the third Wednesday of the month, so for January, that will be the 15th.

A

So the same issue that you saw this meeting posted in will be renamed with the new date and we'll continue the conversation there. So if anyone has another topic, they want to discuss a demo of something cool, but they want to present. Let me know you can always comment right on that issue and this agenda slash meeting note stock is the one we use so I'll add a new section and we keep adding ideas for next time.

A

It's great to see everybody and thank you so much Michael and Oliver and George and Arkady for sharing and leading the discussion into everybody who came to listen everybody good day.