Everything EOS Short Clips and Rants, 4 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Centralized vs Decentralized API Providers and API+ Blue Paper Discussion [Fireside Chat Highlights]

Description

Watch the full EOS fireside chat from March 2, 2022
https://www.youtube.com/watch?v=qKZfhB60e3o

Read more about the ENF sponsored working group Blue Papers
https://medium.com/eos-network-foundation/blue-papers

Everything EOS is the official media channel of the EOS Network Foundation (ENF). The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.

// EOS Network Foundation //
https://eosn.foundation
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosn.foundation
#EOS #EOSIO #ENF

A

I only had a brief chance to read it as, like. You said quite long, but it seems a little bit spread out into multiple different initiatives. Is there any reason it's not trying to focus on, let's say one or two: instead of uh more than that.

B

I think it was just a matter of time. We didn't feel we could go deep enough on some of the thing, which is why there were proposals for teams to follow up afterwards. I know when we originally started. We got real deep into history and then that kind of led into streaming technologies and better ways to optimize. All of that. So that way it wasn't relegated and hosted by just like three people, but to actually like propose a real solution.

B

I don't think we would have been able to come to consensus in time to meet the deadlines and have this thing published. So that's why we didn't get super deep, not a great reason, but it definitely needs to happen well.

A

I'm not actually talking about the the depth of the descriptions, I'm more talking about the fact that there's like, I think, four solutions there tackling different things. Is that supposed to be four different products, or is that just four different avenues of the same product? There's the graph rosetta distributed api central api service uh specialized apis?

A

These are these sound, like they're, very different things again, I haven't had a full chance to read the documentation. Some.

B

Of them do have some overlap like when we're talking about the central api and the decentralized one, basically they're, both valid options. That could both be done, but they also could both be done independently.

A

So here's here's the actual question are these initiatives meant to be done in parallel or is one going to be chosen and the community will run with that? One.

B

That is a discussion to be had, I think, people and specifically with the centralized versus decentralized like they're, both going to have pros and cons, and it's really up to the community on which approach they want to approve. We expect some people are going to rally against having a centralized api provider and having the network support that people are going to ask questions like. Why should the network subsidize that cost? The answer for those people is going to be?

B

Okay, here's a distributed, incentivized, decentralized platform that, in this other proposal, that they could choose to support and, like matthew said they both could exist in parallel and meet everyone's need. It's just. The costs will then go up since we're kind of duplicating effort.

A

Again, forgive me for not having read this in depth. uh Can you give me a brief difference between what this the decentralized api and the centralized api would be sure like we're talking about an actual api here, not uh the company that runs the api right.

B

We are talking about an organization that would be running the apis for the central api proposal. Think like infura, it's this entity that provides a turnkey solution for any new developer coming on board to just be like. Oh, I can use this and I know it's going to work because it's like this organization's purpose is on the floor.

A

Ultimately, because this is uh developed and funded by the community, the underlying technology would still be open sourced.

B

A

So the fact that it's a central, a centralized unit distributing it isn't actually make it centralized.

B

True, but the fact that the community may invest in hardware, rentals or purchasing of hardware or something along that lines to actually operate like a really robust solution that is centralized like that's under the control of an end. I see.

A

So the business model of let's say the cloned infira wouldn't necessarily be the same as inferior where they charge people based on their usage, but rather the community sponsors that effort yeah.

B

And there could be paid offerings on top of that as well. The proposal itself does kind of delineate between those two options as directions. We could go.

A

B

Are kind of trying to address the issue that we have public apis available right now, but there's no underlying uh guarantee that those will exist and that those will work, they're kind of operated on a best effort basis and both the central company operating a professional, hosted solution and an incentivized centralized model could help ensure uh general availability of those services rather than this best effort basis. We have today so.

A

In the case of a centralized one, which I actually think is a pretty good idea- and you know, we've seen how infera has helped the ethereum community, would it only be for es mainnet or were we talking about all the other chains included as well?.

B

We we started thinking about eos, but we talked about other chains constantly.

B

We think that this, like group, or even the model or the technologies and the things that come out of this effort, could easily be applied to other chains and that organization could branch off into other chains with the three teams that were involved in this paper: ours, grey, mass eos nation and then eos rio. We all operate on multiple chains and offer these sorts of services to other chains, so that thought was really forefront in our mind, as we were thinking about ways to potentially do that.

B

I don't know if it's written great that way, but we aimed for that yeah. The paper is really.

C

Deliberate about saying.

A

C

I owe as much as possible, I mean.

A

I kind of have to look at all this stuff from a third party perspective now because I do feel like I'm a third party at this point and not necessarily for ultra but all the other chains, uh that I do things either in my name or not in my name where we're watching you know, what's happening with all of these blue papers, the wallet plus the api plus, and that's one of the biggest questions that everybody has.

A

Because, yes, a lot of these chains haven't pushed back to the eos community per se, but we're all trying to push forward for open sourcing a lot of our own code so that we can make those progressions from the stuff that we've built for the past couple years and apply that to all of the other networks as well. And it's just. It would be nice to be able to see that coming from this foundation and all of the outputs of these blue papers as well read.

B

And I think some of that's starting to happen with the eos io plus working group, because we're now talking about the blue papers and how those ideas could be adopted so that they're capable of supporting any chain and how that looks and feels and how people interact right. Before this call, we had kind of a call about how we prioritize development and how chains come to consensus to come up with direction when it comes with when it comes down to code and operations and standards. Things like that.

B

So I think the blue papers were probably initiated before this thought, or this idea really felt like it could be a reality and now that it does feel like it's a reality. The blue papers kind of have to they don't have to change, but we have to think about them slightly differently in this larger eos io context. So I think we're all aligned the papers and their timing, however, may have not leaned into that quite as hard.

A

As as far as manpower goes you you had mentioned that you're not sure whether it would be decentralized apis and distributed apis at the same time. Is there enough manpower to go around for both or would it be in better focus? uh Would it be better to focus on one great.

C

Question yeah, I don't think there's enough manpower to do both like starting. At the same time, it feels like the the amount of expertise needed to build one or the other define how those things work um was going to pull on the same set of experts. So we just need to be careful about not overloading them. You know somebody made a comment earlier about, I think with zach. It said you know, aaron and gramas team have been spent the last. You know six months writing papers and not writing code.

C

So we have to be careful about spinning off too many projects and not having the time to actually do a good job on any of the projects that are in progress. So, yes, I would is.

A

There a paper coming out that talks about onboarding new blood.

B

It should be, I mean I think that came up in one of the channels. I don't know what channel but like yesterday, in that like, we should have a significant portion of our knowledgeable people, training, new people, and I don't know exactly what that means, but like we need catalans essentially that are taking up the cause and gaining this knowledge set, because right now the the knowledge is really limited to an incredibly small amount of people and the documentation is honestly not sufficient enough to onboard somebody themselves without significant time.

A

I think just the stack is such a large monstrosity at this point that uh yeah it's kind of hard to do, regardless of the documentation not to say the documentation is good. I think you're, absolutely right. It's not great by any.

B

Means, hopefully, these papers and just getting the ideas out and starting to discuss them like this is a good first step towards making that a reality by getting people interested and identifying that need.

D

I also think the uh developer onboarding could fall under the mantra of the whatever the eosio plus working group becomes because there's a lot of overlap between all of the chains. So it's kind of like that's the kind of stuff that everyone can kind of combine efforts on and come up with, the solutions for.