GPN19:Foundations for Decentralization: Data with IPLD: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „ Ein Vortrag von Eric Myhre auf der GPN19. Do you wish building decentralized systems was easier? That building content-addressable storage for applicati…“) |
Keine Bearbeitungszusammenfassung |
||
Zeile 1: | Zeile 1: | ||
Ein Vortrag von Eric Myhre auf der [[GPN19]]. | Ein Vortrag von Eric Myhre auf der [[GPN19]]. | ||
Do you wish building decentralized systems was easier? | Do you wish building decentralized systems was easier? That building content-addressable storage for application data was simple? That APIs could be well-documented and developed in a way that’s agnostic to the serialization format? That addressing structured data with an immutable hash was just a function call away? | ||
IPLD is making all that happen. | IPLD is making all that happen. | ||
The end goal is that a developer can build an application | The end goal is that a developer can build an application that’s like “the next git” – or something even more ambitious and similarly decentralized – and with the IPLD libraries in hand, it should take hours instead of weeks. | ||
Come hear about: | Come hear about: | ||
* The IPLD Format layer – how we make JSON, CBOR, and other formats interchangeable (and how you can bring your own); | |||
* The IPLD Data Model – how we define canonical hashing over all the formats IPLD supports; | |||
* and The IPLD Schema System – how we define some simple, and optional, but incredibly useful standards for typing structured data: both for making data validation easier, making schema evolution possible, and making a clear road for advanced operations like deterministic sharding for large dataset support. | |||
We’re building both specs and library implementations (starting in Go, Java, and JS); this talk will show some example snippets. | |||
In comparison to existing systems, you can think of it like: Protobuf schemas and graphQL queries had a baby, but rather than being built entirely for big-enterprise needs, it’s got native support for both human-readable of JSON and fast binary message formats like CBOR; it’s built for people of the “bazaar” rather than the “cathedral”; and we’re Apache2/MIT licensed FOSS through and through. | |||
{{Navigationsleiste GPN19:Vorträge}} | {{Navigationsleiste GPN19:Vorträge}} |
Aktuelle Version vom 29. Mai 2019, 12:29 Uhr
Ein Vortrag von Eric Myhre auf der GPN19.
Do you wish building decentralized systems was easier? That building content-addressable storage for application data was simple? That APIs could be well-documented and developed in a way that’s agnostic to the serialization format? That addressing structured data with an immutable hash was just a function call away?
IPLD is making all that happen.
The end goal is that a developer can build an application that’s like “the next git” – or something even more ambitious and similarly decentralized – and with the IPLD libraries in hand, it should take hours instead of weeks.
Come hear about:
- The IPLD Format layer – how we make JSON, CBOR, and other formats interchangeable (and how you can bring your own);
- The IPLD Data Model – how we define canonical hashing over all the formats IPLD supports;
- and The IPLD Schema System – how we define some simple, and optional, but incredibly useful standards for typing structured data: both for making data validation easier, making schema evolution possible, and making a clear road for advanced operations like deterministic sharding for large dataset support.
We’re building both specs and library implementations (starting in Go, Java, and JS); this talk will show some example snippets.
In comparison to existing systems, you can think of it like: Protobuf schemas and graphQL queries had a baby, but rather than being built entirely for big-enterprise needs, it’s got native support for both human-readable of JSON and fast binary message formats like CBOR; it’s built for people of the “bazaar” rather than the “cathedral”; and we’re Apache2/MIT licensed FOSS through and through.