Pablo Andrés Dorado Suárez<!-- .element: style=" height: 35vh; margin-bottom: 0" -->
Pablo Andrés Dorado Suárez
@pandres95
Antes de Empezar
Note:
Hablaremos de algunos conceptos básicos acerca de comunicaiones y telecomunicaciones.
Handles the logic of publishing and exchanging goods and services. This is an implementation of the RFC002.
Design Goals
The pallet-listings extends the capabilities of pallet-nfts, with two some specializations:
Calls to handle the tasks of creating inventories, publishing items and setting properties for them.
A global index of all the published items, with categories.
The logic to create template items.
The logic to handle orders and the integrations with payments.
Start Date
03/02/2025
Description
Define the APIs to handle the Listings service and accompanying integrations.
Authors
Pablo Andrés Dorado Suárez (hola@pablodorado.com)
Summary
Audiences
High-order components (insights by Dani <3): No need to customize. Low/no-code. Provide web components.Note: Maybe a separate library for components??Virto Connect
Checkout
...
"Web2" APIs (insights by Dani/David <3): Used to construct higher-order components.
Built using VOS, using zInk! Programs.
Don't expose blockchain concepts (e.g. expose Authn via OAuth 2.0).
Versión muy (muy) reducida
Hay cinco cosas a entender a la hora de trabajar con una blockchain:
Los sistemas descentralizados (como blockchain) son considerados canales abiertos (que pueden ser escuchados y potencialmente intervenidos). Por esto, es necesario usar algoritmos criptográficos para proporcionar unas garantías fundamentales: confidencialidad, autenticidad, integridad, y no repudio.
Una blockchain es una máquina de estados, de naturaleza atómica y transaccional, compuesta de:
Una cadena de bloques: lista enlazada por hash del elemento inmediatamente anterior. Esto, para garantizar la integridad de las operaciones, y de merkle trees (arboles n-arios, donde el valor del nodo es el hash de la concatenación de los hashes de los nodos hijos, hasta las hojas, que son o bien las operaciones, o el estado), y que se usan para poder verificar rápidamente cambios en el estado de la base de datos sin necesitar de mucha información.
Un estado: este estado puede ser cualquier base de datos, pero típicamente es un trie n-ario de llave-valor. Es un trie n-ario, porque así es muchísimo más fácil usar hashes para calcular los prefijos de las llaves, y leer la información muchísimo más rápido. Pero para efectos prácticos, las bases de datos de una blockchain suelen ser de tipo llave-valor.
Beneficiary: HUf7Nvfhp85yFZm31zV2ux8h1946Bzzmos2jqGGhp3bWXD4
Amount: 55.95 KSM (1,600 EUR — $31.138/KSM @ EMA30, $1.09/EUR)
Call: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkreivo.io%2F#/extrinsics/decode/0x470b0a0300d8dba69752ffb04fa563b126a31b037c8bebeb73e3c66cacd7c8efab46bd34230b000ce0dfe232
As you probably might be aware, I was selected to receive a sponsorship for up to €1,600 to attend this year's Polkadot Decoded.
Accepted people list
However, due to the conditions of the sponsorship, I must confirm my airline travel tickets or hotel reservations (or both) by this Friday, 18:59 COT, and reimbursements can be given back to me as late as 31 August!!!
Allows dispatching calls on behalf of a keyless account using an authenticator that resolves alternative signing methods.
Overview
Historically, having an account on the Web3 Ecosystem and using it to send transactions over a network has been as easy as having a private key which can sign those. Now, this ease comes with some tradeoffs. One of the most important is securely storing that key, to support signature operations.
Nonetheless, transactions are endorsed by accounts, not keys. A key is merely one means to get an Account. This pallet provides mechanisms for an Account to exist without necesarily hold a private key as traditionally known. This is done by introducing the concept of an Authenticator, very well known in the Web2 Ecosystem.
Terminology
An Authenticator is a handler that allows processing Challenges to either gather access to the Account, or to register a new Device against the Account.
A Challenge is the process where an Authenticator gathers a cryptographically verifiable input from a Device, and decides whether to provide access to an Account.
Introduction
Yaay! You just created your community. Now, let's learn how to execute something on Kusama, from your Community.
Note: This tutorial assumes you're the admin of the community. If you already decentralized your community, and the admin is the community itself, you'll need to encode the final extrinsic and submit a referendum on your community track (this will be covered in the next part of this tutorials).
1. Craft the extrinsic to send
Craft the extrinsic you want to execute in the name of the Community.
Once you have the extrinsic crafted, copy the encoded call. You'll need it on a couple of places later.
Screenshot 2024-05-07 at 11.27.22 PM
Go to the Runtime page, and submit the transactionPaymentCallApi.queryCallInfo runtime call with the following params:
kreivo-1ksm1dao
Introduction
Creating a DAO is usually a not so straightforward process. It usually involves deciding how do you want it to work, the goal, the methods for deciding how to onboard the members of it, and how to govern it.
Additionally, the deployment of a DAO doesn't get much easier: setup a multisig, find a network where to deploy the Smart Contract for your DAO, issue a token among your members, then start receiving funds on the account dedicated for the DAO. Aside from the technical challenge this means, being able to decide managing your community out of the ordinary way (via tokenized governance) implies modifying code you probably have to thoroughly check and audit.
Between the cost of deciding, and the technical expense of deploying, the process of thinking in establishing a DAO hasn't been an easy task.
Until now.
Community Manager
Chamber of Commerce
Overview
Terminology
Goals
Create communitiesSetup Membership collection
Configure Referenda Track
Setup Community Admin Origin
Add first member
Overview
While OpenGov is a huge advancement in terms of building a decentralized solution for on-chain governance, some features in its design can be used to take advantage of some unwanted behaviours. One of them is snipping: in this case, being the last actor to ever vote in a poll while in confirmation period, thus drastically affecting it's status, ignoring the overall result (both on decision period AND mostly all the confirmation period).
Since decision and confirmation periods are now extended, having this kind of behaviour leads into an expensive outcome when an otherwise passing poll gets rejected last minute and needs to be reintroduced from the beginning.
This feature request aims to find a solution, using a concept similar to Candle Auctions, but intended for determining the state of the poll within the confirmation period.
Proposed Solution
The current state flow for the referenda protocol goes like this:
Why?
Voting with assets: Vote::AssetBalance(AssetId, AssetBalance)
Staking with an asset
many others…
The Problem
No currently built-in solution in polkadot-sdk.
Version: 1.0.0-draft.0 (2024/01/14)
Authors:
P. Dorado
Summary
The Ticketto Protocol is a decentralised protocol to easily and securely issue, hold, and transfer tokens to grant access to events.
Motivation
Abstract
In a landscape where the event industry grapples with issues of security, transparency, and high operational costs, a new approach to ticketing emerges, harnessing the robust capabilities of blockchain technology. This paradigm shift addresses the critical need for a cost-effective, secure, and transparent ticketing process, particularly benefiting indie and underground events, which often face barriers in accessing advanced ticketing solutions.
Kippu (切符, [train] ticket) utilizes blockchain technology to enhance the event ticketing process, especially for music concerts. This whitepaper delves into the implementation of blockchain within the Polkadot ecosystem to revolutionize event ticketing. It outlines a scalable, low-cost model that significantly reduces ticket issuance costs, while ensuring a seamless and user-friendly experience for all participants. The focus is on an innovative solution that democratizes access to cutting-edge technology in event ticketing, setting a new standard for how live experiences are managed and enjoyed globally.
Introduction
The event ticketing industry has long been fraught with challenges that hinder both organizers and attendees. Issues such as ticket fraud, scalping, and a lack of transparency in pricing and distribution have consistently plagued traditional ticketing systems. These challenges are compounded for smaller, independent events that struggle with the high costs and complexities of accessing sophisticated ticketing solutions. The need for an innovative approach to address these persistent issues is evident.
Enter the world of blockchain technology, a solution that offers a new frontier in event ticketing. By leveraging the inherent security, transparency, and efficiency of blockchain, it's possible to reimagine the entire ticketing process. This technology not only promises to combat common problems like counterfeiting and unauthorized reselling but also introduces a paradigm shift in how ticketing costs are structured and managed. The emergence of this technology in the event ticketing landscape opens up new possibilities for a more equitable and user-friendly system, particularly benefiting niche and underground events that have traditionally been underserved by conventional ticketing platforms. This whitepaper explores the application of blockchain technology in event ticketing, presenting a novel approach that stands to transform the industry for a diverse range of events.
Introduction
"Podcastless" is a unique podcast hosted by Pablo Dorado, Julián Pardo, Manuel Castiblanco, and Javier Collazos. This Colombian podcast delves into a variety of topics, exploring perspectives from the past, present, and future. The first season found a specific audience, and with new technical advancements, the team is set to produce further seasons with a renewed focus.
Goal
To produce new seasons of Podcastless while balancing time and obtaining feedback without disrupting our workflow.
Work Schema
Asynchronism: Adapt to the hosts' schedules.
Commitment: Dedication to producing quality content.
Fun: Ensuring the process is enjoyable.