diff --git a/packages/documentation/astro.config.mjs b/packages/documentation/astro.config.mjs index 85aac97ee2..a969075093 100644 --- a/packages/documentation/astro.config.mjs +++ b/packages/documentation/astro.config.mjs @@ -144,15 +144,12 @@ export default defineConfig({ }, { label: 'Open Payments', - translations: { - es: 'Pagos Abiertos' - }, link: '/overview/concepts/open-payments' }, { label: 'Payment pointers and wallet addresses', translations: { - es: 'Apuntadores de pago y direcciones de billeteras' + es: 'Payment pointers y wallet addresses' }, link: '/overview/concepts/payment-pointers' }, diff --git a/packages/documentation/public/img/fsp-responsibilities-spanish.png b/packages/documentation/public/img/fsp-responsibilities-spanish.png new file mode 100644 index 0000000000..13b3f3deca Binary files /dev/null and b/packages/documentation/public/img/fsp-responsibilities-spanish.png differ diff --git a/packages/documentation/src/content/docs/es/index.mdx b/packages/documentation/src/content/docs/es/index.mdx index c6f87d7fb4..d408bcbf78 100644 --- a/packages/documentation/src/content/docs/es/index.mdx +++ b/packages/documentation/src/content/docs/es/index.mdx @@ -1,40 +1,40 @@ --- -title: Hello from Rafiki -description: Rafiki is open source software that provides an efficient solution for an Account Servicing Entity to enable Interledger functionality on its users' accounts. +title: Saludos desde Rafiki +description: Rafiki es un software de código abierto que ofrece a una Entidad de Servicio de Cuentas una solución eficiente para habilitar la funcionalidad de Interledger en las cuentas de sus usuarios. template: splash hero: - tagline: Rafiki is open source software that provides an efficient solution for an account servicing entity (ASE) to enable Interledger functionality on its users' accounts. + tagline: Rafiki es un software de código abierto que ofrece a una Entidad de Servicio de Cuentas (ASE) una solución eficiente para habilitar la funcionalidad de Interledger en las cuentas de sus usuarios. actions: - - text: Read Rafiki docs + - text: Leer los documentos de Rafiki link: /es/overview/overview icon: open-book variant: primary attrs: - data-umami-event: Landing page - Rafiki docs + data-umami-event: Página de inicio - Documentos de Rafiki --- import { Card, CardGrid, LinkCard } from '@astrojs/starlight/components' - - Test Rafiki by running two mock ASEs that automatically peer with one - another. + + Pruebe Rafiki ejecutando dos ASE simuladas que se interconectan + automáticamente entre sí. - - Review the requirements for deploying Rafiki to a production environment. + + Revise los requisitos para implementar Rafiki en un entorno de producción. - - Discover what's in our Backend GraphQL schema. + + Descubra qué contiene nuestro esquema GraphQL de backend. - - Discover what's in our Auth GraphQL schema. + + Descubra qué contiene nuestro esquema GraphQL de autenticación. diff --git a/packages/documentation/src/content/docs/es/overview/concepts/account-servicing-entity.mdx b/packages/documentation/src/content/docs/es/overview/concepts/account-servicing-entity.mdx index 8e5ef933a8..e5fdc7acde 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/account-servicing-entity.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/account-servicing-entity.mdx @@ -9,8 +9,8 @@ Como entidades reguladas, las ASE están sujetas a las leyes, normas y regulacio ## Responsabilidades y obligaciones Image with four panels that summarize the four main responsibilities of ASEs diff --git a/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx b/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx index 40437a5b70..72958dedeb 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx @@ -2,28 +2,30 @@ title: Compensación y liquidación --- -## Clearing +import { LinkOut } from '@interledger/docs-design-system' -When a payment is made over traditional banking rails, the money doesn’t move instantly. First, there are checks to confirm that the money exists and can be transferred. Clearing networks are responsible for exchanging messages between ASEs to facilitate these checks. This process is called clearing. When a payment successfully clears, it means the payer’s ASE has an obligation to the payee’s ASE. +## Compensación -The [Interledger Protocol (ILP)](/overview/concepts/interledger) is not a traditional clearing network, but does function in a similar way. +Cuando se realiza un pago a través de los canales bancarios tradicionales, el dinero no se transfiere de forma instantánea. Primero, se realizan verificaciones para confirmar que el dinero existe y se puede transferir. Las redes de compensación son responsables del intercambio de mensajes entre las ASE para facilitar estas verificaciones. Este proceso se denomina compensación. Cuando un pago se compensa correctamente, significa que la ASE del pagador tiene una obligación con la ASE del beneficiario. -- ASEs that implement the protocol must become [peers](/integration/requirements/peers) to transact with one another. This is comparable to traditional banking, where ASEs must use the same clearing network. An ASE can't use Interledger to transact with another ASE unless they have both implemented the protocol and have peered with one another. -- Peered ASEs exchange ILP packets, which are packets of value that contain transaction information. ILP packets are akin to the messages exchanged during the traditional clearing process. -- The successful exchange of ILP packets between peers creates obligations between them that must be settled. The receipt of a fulfilled ILP packet is basically a conditional IOU—a promise to pay—that affects the financial accounting balances between the peers. +El [Interledger Protocol (ILP)](/es/overview/concepts/interledger) no es una red de compensación tradicional, pero funciona de manera similar. -You can read more about clearing as it relates to ILP in the [Interledger developer docs](https://interledger.org/developers/rfcs/peering-clearing-settling/). +- Las ASE que implementan el protocolo deben convertirse en [pares](/integration/requirements/peers) para realizar transacciones entre sí. Esto es comparable a la banca tradicional, donde las ASE deben utilizar la misma red de compensación. Una ASE no puede usar Interledger para realizar transacciones con otra ASE a menos que ambas hayan implementado el protocolo y se hayan interconectado. +- Las ASE interconectadas intercambian paquetes ILP, que son paquetes de valor que contienen información de las transacciones. Los paquetes ILP son similares a los mensajes intercambiados durante el proceso de compensación tradicional. +- El intercambio exitoso de paquetes ILP entre pares crea obligaciones entre ellos que deben liquidarse. La recepción de un paquete ILP cumplido es básicamente un pagaré condicional —una promesa de pago— que afecta los saldos contables financieros entre los pares. -Conceptually, Rafiki sits at the clearing level, but isn't a clearing network. It's software that makes implementing the Interledger protocol faster and easier. Rafiki uses ILP to [track liquidity](/overview/concepts/accounting) between assets, payments, and peers. An ASE must still connect Rafiki to their existing backend system and internal ledger for authentication, fetching exchange rates, and managing liquidity itself. For example, if an incoming payment completes in Rafiki, the ASE’s backend must credit the recipient’s account on their own system, however that might look. +Puede obtener más información sobre la compensación en relación con ILP en los documentos para desarrolladores de Interledger. -In any case, no movement of actual money has occurred yet. +Conceptualmente, Rafiki se sitúa en el nivel de compensación, pero no es una red de compensación. Es un software que permite implementar el Interledger Protocol de forma más rápida y sencilla. Rafiki utiliza ILP para [hacer un seguimiento de la liquidez](/es/overview/concepts/accounting) entre activos, pagos y pares. Una ASE aún debe conectar Rafiki con su sistema de backend existente y su libro mayor interno para la autenticación, la obtención de los tipos de cambio y la gestión de la liquidez. Por ejemplo, si un pago entrante se completa en Rafiki, el backend de la ASE debe acreditar los fondos en la cuenta del destinatario dentro de su propio sistema, independientemente de cómo lo implemente. -## Settlement +En cualquier caso, aún no se ha producido ningún movimiento de dinero real. -In traditional banking, settlement is the fulfillment of an obligation between ASEs. It turns the promise of payment into a real payment by moving actual money. This occurs over a shared settlement network, such as Fedwire in the United States. +## Liquidación -When a payer’s ASE settles with the payee’s ASE, there’s a high chance that the ASE isn’t physically handing over cash. There’s more likely to be an intermediary, like a reserve bank or central bank, that maintains accounts for both ASEs. The intermediary moves funds from one account to the other, crediting and debiting the accounts as necessary. +En la banca tradicional, la liquidación es el cumplimiento de una obligación entre las ASE. Convierte la promesa de pago en un pago real mediante la transferencia de fondos reales. Esto ocurre a través de una red de liquidación compartida, como Fedwire en los Estados Unidos. -With Interledger, the concept of settlement is not that different. Each [peer](/integration/requirements/peers) must agree on a settlement system to use to fulfill their obligations with one another. However, ILP itself is not a settlement system. This means peers must have some other way to fulfill their obligations and exchange value. Examples can include using a real-time gross settlement system like Fedwire, an automated clearing house (ACH) network, a money transfer service, or some other payment channel. You can read more about settling as it relates to ILP in the [Interledger developer docs](https://interledger.org/developers/rfcs/settlement-engines/). +Cuando la ASE del pagador liquida con la ASE del beneficiario, es muy probable que no esté transfiriendo dinero en efectivo de forma física. Lo más probable es que exista un intermediario, como un banco de reserva o un banco central, que mantenga cuentas para ambas ASE. El intermediario transfiere los fondos de una cuenta a la otra, acreditando y debitando las cuentas según sea necesario. -Rafiki is also not a settlement system. It [keeps track of liquidity](/overview/concepts/accounting) through the use of liquidity and settlement accounts. Liquidity accounts track deposit, withdrawal, and transfer amounts. Settlement accounts track the availability of funds, denominated in a single asset. A negative balance means funds are available. The closer a settlement account’s balance is to zero, the more likely it is that one peer needs to settle with the other over their agreed-upon settlement system. +Con Interledger, el concepto de liquidación no es tan diferente. Cada [par](/integration/requirements/peers) debe acordar un sistema de liquidación que se utilizará para cumplir con sus obligaciones mutuas. Sin embargo, ILP en sí mismo no es un sistema de liquidación. Esto significa que los pares deben tener alguna otra forma de cumplir con sus obligaciones e intercambiar valor. Los ejemplos pueden incluir el uso de un sistema de liquidación bruta en tiempo real, como Fedwire; una red de cámara de compensación automatizada (ACH); un servicio de transferencia de dinero o algún otro canal de pago. Puede obtener más información sobre la liquidación en relación con ILP en los documentos para desarrolladores de Interledger. + +Rafiki tampoco es un sistema de liquidación. [Realiza un seguimiento de la liquidez](/es/overview/concepts/accounting) a través de cuentas de liquidez y de liquidación. Las cuentas de liquidez registran los importes de los depósitos, los retiros y las transferencias. Las cuentas de liquidación registran la disponibilidad de fondos, denominados en un único activo. Un saldo negativo significa que hay fondos disponibles. Cuanto más se aproxima a cero el saldo de una cuenta de liquidación, mayor es la probabilidad de que un par deba realizar la liquidación con el otro a través del sistema de liquidación que hayan acordado. diff --git a/packages/documentation/src/content/docs/es/overview/concepts/interledger.mdx b/packages/documentation/src/content/docs/es/overview/concepts/interledger.mdx index 4882137bab..9b966d1e59 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/interledger.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/interledger.mdx @@ -4,64 +4,64 @@ title: Interledger import { LinkOut } from '@interledger/docs-design-system' -Building and maintaining your own connector to participate on the Interledger network can be a time consuming and complex undertaking. As a reference implementation of the Interledger stack, Rafiki gives you all the tools you need to quickly and easily join the network and enable Interledger capabilities on your users’ accounts. +Crear y mantener su propio conector para participar en la red de Interledger puede ser una tarea compleja y que requiere mucho tiempo. Como implementación de referencia de la pila de Interledger, Rafiki le ofrece todas las herramientas que necesita para unirse a la red y habilitar las capacidades de Interledger en las cuentas de sus usuarios. -## Packets +## Paquetes -At the core of Interledger is the Interledger Protocol (ILP). It’s a request/response protocol where requests and responses are ILP packets. +En el núcleo de Interledger se encuentra el Interledger Protocol (ILP). Es un protocolo de solicitud/respuesta en el que las solicitudes y las respuestas son paquetes ILP. -These packets of data carry information about a payment. Typically, information about a single aggregate payment from sender to receiver is split into multiple ILP packets. +Estos paquetes de datos contienen información sobre un pago. Por lo general, la información sobre un único pago agregado del remitente al destinatario se divide en varios paquetes ILP. -Each packet represents a conditional IOU which affects financial accounting balances between peers. Amounts adjust based on the sender's asset, the receiver's asset, and Rafiki's configured [exchange rates service](/integration/requirements/exchange-rates). Then, the amounts are used to update account liquidity in your accounting database (TigerBeetle or Postgres). +Cada paquete representa un pagaré condicional que afecta los saldos contables financieros entre pares. Los importes se ajustan en función del activo del remitente, el activo del destinatario y el [servicio de tipos de cambio](/integration/requirements/exchange-rates) configurado de Rafiki. Luego, los importes se utilizan para actualizar la liquidez de las cuentas en su base de datos contable (TigerBeetle o Postgres). -## Peers +## Pares -Interledger itself is a network of computers that enables sending payment messages across payment networks. Each computer on the network is a node. +Interledger en sí es una red de computadoras que permite enviar mensajes de pago a través de redes de pago. Cada computadora de la red es un nodo. -For two nodes on the Interledger network to exchange ILP packets with one another, the two nodes must be peers. There are a number of [requirements](/integration/requirements/peers#perform-prerequisites) that both you and your potential peer must meet to form a peering relationship. +Para que dos nodos de la red de Interledger intercambien paquetes ILP entre sí, los dos nodos deben ser pares. Hay una serie de [requisitos](/integration/requirements/peers#perform-prerequisites) que tanto usted como su posible par deben cumplir para establecer una relación de interconexión. -Since the purpose of peering is to facilitate payments, which often involves extending lines of credit, your peer should be someone you trust. We strongly recommend you and your potential peer define your expectations and outline your agreements in a legally binding document peering with one another. +Dado que el propósito de la interconexión es facilitar los pagos, lo que a menudo implica extender líneas de crédito, su par debe ser alguien en quien confíe. Recomendamos encarecidamente que usted y su posible par definan sus expectativas y describan sus acuerdos en un documento legalmente vinculante antes de iniciar una interconexión. -## Connectors +## Conectores -Each node on the Interledger network can take on the role of sender, connector, or receiver, depending on the payment. +Cada nodo de la red de Interledger puede asumir el papel de remitente, conector o destinatario, según el pago. -- Sender - Originates the payment by sending ILP packets. -- Connector - An intermediary between a sender and receiver that forwards ILP packets. Connectors can facilitate payments to or from anyone they’re peered with. -- Receiver - The final recipient of the ILP packets and, as such, the payment. +- Remitente: origina el pago mediante el envío de paquetes ILP. +- Conector: un intermediario entre un remitente y un destinatario que reenvía paquetes ILP. Los conectores pueden facilitar los pagos hacia o desde cualquier par con el que estén interconectados. +- Destinatario: el destinatario final de los paquetes ILP y, por lo tanto, del pago. -If the sender and receiver nodes are peers, then the payment flow is straightforward and no intermediary connector nodes are needed. However, if the sender and receiver aren’t peers, then the payment must route through one or more connectors. Rafiki’s [backend service](/integration/deployment/services/backend-service#interledger-connector) includes an Interledger connector for sending and receiving ILP packets. +Si los nodos remitente y destinatario son pares, el flujo de pago es directo y no se necesitan nodos conectores intermediarios. Sin embargo, si el remitente y el destinatario no son pares, el pago debe pasar por uno o más conectores. El [servicio de backend](/integration/deployment/services/backend-service#interledger-connector) de Rafiki incluye un conector de Interledger para enviar y recibir paquetes ILP. -In the image below, the sender node (A) and the receiver node (C) share a common peer (B). In payments from the sender to the receiver, node B performs the role of connector to facilitate payments between the two. +En la imagen a continuación, el nodo remitente (A) y el nodo destinatario (C) comparten un par común (B). En los pagos del remitente al destinatario, el nodo B desempeña el papel de conector para facilitar los pagos entre ambos. Peering relationship showing a sender, connector, and receiver -In reality, there can be multiple connectors between a sender node and a receiver node. As more nodes that support different assets peer with one another, the easier it becomes for payments to traverse the Interledger network. +En realidad, puede haber múltiples conectores entre un nodo remitente y un nodo destinatario. Cuantos más nodos compatibles con distintos activos se interconecten entre sí, más fácil será que los pagos puedan atravesar la red de Interledger. -## Payment pointer +## Payment Pointer -A payment pointer is a type of wallet address that serves as an SPSP endpoint to facilitate sending and receiving ILP packets. Rafiki will assign each of your customers' accounts with a payment pointer. +Un Payment Pointer es un tipo de wallet address que funciona como un punto final de SPSP para facilitar el envío y la recepción de paquetes ILP. Rafiki asignará un Payment Pointer a cada una de las cuentas de sus clientes. -Payment pointers must resolve to an HTTPS URL and can be written out using the `$` shorthand (for example, `$wallet.example.com/alice`) or as a URL (for example, `https://wallet.example.com/alice`). +Los Payment Pointers deben resolverse en una URL HTTPS y pueden representarse mediante la notación abreviada `$` (por ejemplo, `$wallet.example.com/alice`) o como una URL (por ejemplo, `https://wallet.example.com/alice`). -See [Payment pointers and wallet addresses](/overview/concepts/payment-pointers) for more information. +Consulte [Payment pointers y wallet addresses](/es/overview/concepts/payment-pointers) para obtener más información. -## Simple Payment Setup Protocol (SPSP) +## Protocolo de Configuración de Pago Simple (SPSP) -The Simple Payment Setup Protocol (SPSP) is an application layer protocol that uses HTTPS to exchange payment information. -Every payment pointer issued by Rafiki serves as an SPSP endpoint by default (`ENABLE_SPSP_PAYMENT_POINTERS`). +El Protocolo de Configuración de Pago Simple (SPSP) es un protocolo de la capa de aplicación que utiliza HTTPS para intercambiar información de pago. +Cada Payment Pointer emitido por Rafiki funciona como un punto final de SPSP de forma predeterminada (`ENABLE_SPSP_PAYMENT_POINTERS`). -When a `GET` request is made to a payment pointer, the response contains the ILP address of the destination account and a shared secret. These details are needed to set up a STREAM connection between two counterparties to facilitate direct payments over Interledger. +Cuando se realiza una solicitud `GET` a un Payment Pointer, la respuesta contiene la dirección ILP de la cuenta de destino y un secreto compartido. Estos detalles son necesarios para establecer una conexión STREAM entre dos contrapartes a fin de facilitar pagos directos a través de Interledger. -## STREAM Protocol +## Protocolo STREAM -The STREAM Protocol is the transport layer protocol in the Interledger Protocol stack. After SPSP communicates the ILP address of the destination account and the shared secret, the STREAM protocol uses these details to set up a STREAM connection between the -counterparties.{' '} +El protocolo STREAM es el protocolo de la capa de transporte en la pila del Interledger Protocol. Después de que SPSP comunica la dirección ILP de la cuenta de destino y el secreto compartido, el protocolo STREAM utiliza estos detalles para establecer una conexión STREAM entre las +contrapartes. -Rafiki’s `backend` service includes an Interledger connector for sending and receiving STREAM packets. STREAM packets are encoded, encrypted, and sent as the `data` field in ILP packets. The protocol uses the shared secret to authenticate and encrypt packets, and to generate conditions and fulfillments. +El servicio de `backend` de Rafiki incluye un conector de Interledger para enviar y recibir paquetes STREAM. Los paquetes STREAM se codifican, cifran y envían como el campo `data` en los paquetes ILP. El protocolo utiliza el secreto compartido para autenticar y cifrar los paquetes, y para generar las condiciones y los cumplimientos. -A critical function of STREAM is to determine the path exchange rate and handle any changes in the rate. Rafiki’s exchange rates service allows you to provide exchange rate information. +Una función fundamental de STREAM es determinar el tipo de cambio de la ruta y gestionar cualquier cambio en el tipo de cambio. El servicio de tipos de cambio de Rafiki le permite proporcionar información sobre los tipos de cambio. diff --git a/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx b/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx index f9afdaa898..d863b79d68 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx @@ -30,7 +30,7 @@ Los clientes se agregan a través de la API de administración del backend o de Un cliente es una ASE que se conecta a una instancia compartida de Rafiki en lugar de ejecutar su propio entorno. Para conectarse al entorno compartido, cada cliente debe instalar y ejecutar su propio servicio de integración. Los clientes son responsables de lo siguiente: -- Crear y administrar direcciones de billetera para sus usuarios (por ejemplo, sus consumidores). +- Crear y administrar wallet addresses para sus usuarios (por ejemplo, sus consumidores). - Enviar y recibir pagos. - Configurar ajustes específicos del cliente, como la URL del webhook y la URL de los tipos de cambio. - Administrar sus propios activos y su liquidez. diff --git a/packages/documentation/src/content/docs/es/overview/concepts/open-payments.mdx b/packages/documentation/src/content/docs/es/overview/concepts/open-payments.mdx index c3948bb885..091171d4e8 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/open-payments.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/open-payments.mdx @@ -1,38 +1,48 @@ --- -title: Pagos Abiertos +title: Open Payments tableOfContents: maxHeadingLevel: 2 --- import { LinkOut } from '@interledger/docs-design-system' -Rafiki follows the Open Payments standard to enable third-party clients to securely retrieve account information and initiate payments from your customers’ accounts with their consent. The standard describes a uniform way to create and manage grants and resources for incoming payments, quotes, and outgoing payments. +Rafiki sigue el estándar de Open Payments para permitir que los clientes externos recuperen de forma segura información de las cuentas y autoricen pagos desde las cuentas de sus clientes con su consentimiento. El estándar ofrece una forma uniforme de crear y gestionar concesiones y recursos para pagos entrantes, cotizaciones y pagos salientes. -### Example use case - retrieve account information +## Servicio de backend de Rafiki -Some of your customers use a third-party application that allows them to create budgets and monitor their spending. The application can call the Open Payments APIs, enabling it to communicate with any account servicing entity that implements the Open Payments standard. When your customers give the app permission to retrieve their transaction history, the app communicates with your Rafiki instance via the Open Payments APIs to obtain grants from your authorization server and transaction history from your resource server. +El servicio de [`backend`](/integration/deployment/services/backend-service) de Rafiki es el servicio principal para gestionar la lógica empresarial y la comunicación externa. El servicio es responsable, entre otras cosas, de exponer los puntos finales de las API de Open Payments para que los clientes realicen tareas de administración de cuentas. Todas las solicitudes y respuestas se validan conforme a la especificación de Open Payments. -### Further reading +## Servicio de autenticación de Rafiki -We strongly encourage you to familiarize yourself with the Open Payments standard. Extensive documentation is available on the Open Payments website. We recommend you start by reviewing all the pages within the _Intro to Open Payments_ section. Here are a few links to get you started. +El servicio de [`auth`](/integration/deployment/services/auth-service) de Rafiki es una implementación de referencia de un servidor de autorización de Open Payments con un diseño predefinido. El servidor de autorización es responsable de delegar la autorización (a través de concesiones) a los clientes para que puedan utilizar las API de Open Payments, resolver las claves públicas de los clientes para autenticar y autorizar las solicitudes entrantes, y crear pagos y cotizaciones en el backend. Open Payments aprovecha el Protocolo de Negociación y Autorización de Concesiones (GNAP) para delegar la autorización. Puede obtener más información sobre el protocolo revisando su especificación. + +## Ejemplos de casos de uso + +### Recuperar información de la cuenta + +Su cliente utiliza una aplicación de terceros que le permite crear presupuestos y controlar sus gastos. Para obtener la información que necesita, la aplicación utiliza las API de Open Payments para solicitar el historial de transacciones de su cliente. + +### Pagos de comercio electrónico + +Su cliente inicia una compra a un comerciante en línea. Dado que el comerciante ha implementado Open Payments, su cliente puede ingresar su wallet address en el formulario de pago del comerciante en lugar de los datos de su tarjeta de crédito. El servidor del comerciante utiliza las API de Open Payments para comunicarse con usted a fin de configurar el pago y obtener el consentimiento de su cliente para la compra. + +### Pagos entre pares (por ejemplo, remesas) + +Su cliente utiliza una aplicación de remesas de un tercero para enviar dinero desde EE. UU. a su familia en México. Quiere que su padre reciba una cantidad exacta en pesos mexicanos, independientemente de cuánto cueste en USD. Como el desarrollador de la aplicación ha implementado Open Payments, su cliente puede ingresar el wallet address tanto propio como de su padre, en lugar de ingresar los datos de sus cuentas bancarias. La aplicación utiliza las API de Open Payments para comunicarse con usted a fin de configurar el pago y obtener el consentimiento de su cliente para el pago. + +### Lecturas adicionales + +Le recomendamos encarecidamente que se familiarice con el estándar de Open Payments. Hay una amplia documentación disponible en el sitio web de Open Payments. Le recomendamos que comience revisando todas las páginas de la sección _Introducción a Open Payments_. A continuación, encontrará algunos enlaces para comenzar. - - Getting started with Open Payments + Primeros pasos con Open Payments - - Client keys + Claves de cliente - - HTTP message signatures + Firmas de mensajes HTTP - - Grant negotiation and authorization + Negociación y autorización de las concesiones - -## Rafiki's backend service - -Rafiki’s [`backend`](/integration/deployment/services/backend-service) service is the main service for handling business logic and external communication. The service is responsible for, among other things, exposing the endpoints of the Open Payments APIs for clients to perform account management tasks. Every request and response is validated against the Open Payments specification. - -## Rafiki's auth service - -Rafiki’s [`auth`](/integration/deployment/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving clients’ public keys to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its specification. diff --git a/packages/documentation/src/content/docs/es/overview/concepts/payment-pointers.mdx b/packages/documentation/src/content/docs/es/overview/concepts/payment-pointers.mdx index 1adc69050e..61e35375bc 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/payment-pointers.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/payment-pointers.mdx @@ -1,55 +1,57 @@ --- -title: Apuntadores de pago y direcciones de billeteras +title: Payment pointers y wallet addresses --- ## Payment pointers -A payment pointer is a standardized identifier for a payment account that supports Interledger payments. Each payment pointer must resolve to an HTTPS URL that serves as an [SPSP](/overview/concepts/interledger#simple-payment-setup-protocol-spsp) endpoint to facilitate sending and receiving ILP packets. +Un Payment pointer es un identificador estandarizado para una cuenta de pago que admite pagos mediante Interledger. Cada Payment pointer debe resolverse en una URL HTTPS que funcione como un punto final [SPSP](/es/overview/concepts/interledger#protocolo-de-configuración-de-pago-simple-spsp) para facilitar el envío y la recepción de paquetes ILP. -You can determine whether a URL is a payment pointer by sending a `GET` request to the URL with an `accept: application/spsp4+json` header. +Puede determinar si una URL es un Payment pointer enviando una solicitud `GET` a la URL con un encabezado `accept: application/spsp4+json`. -```http title="Example request" +```http title="Ejemplo de solicitud" curl --request GET \ --url https://wallet.example.com/alice/ \ --header 'accept: application/spsp4+json' ``` -A response from an SPSP server means the URL is a payment pointer. +Si un servidor SPSP devuelve una respuesta, significa que la URL es un Payment pointer. -```http title="Example response" +```http title="Ejemplo de respuesta" { "destination_account":"example.0.cloudnine.ind.alice.cdfa5e16-e759", "shared_secret":"7h0s7EpQDqcgzqmX-mwrNHFHinPvJq8Jw", } ``` -Payment pointers are often written out using the `$` shorthand. For example, `$wallet.example.com/alice`, which resolves to `https://wallet.example.com/alice/`. +Los Payment pointers suelen representarse mediante la notación abreviada `$`. Por ejemplo, `$wallet.example.com/alice`, que se resuelve en `https://wallet.example.com/alice/`. -Rafiki assigns each of your customers' accounts with a payment pointer. This payment pointer is also a wallet address because Rafiki supports both Interledger and Open Payments. +Rafiki asigna un Payment pointer a cada una de las cuentas de sus clientes. Este Payment pointer también es un wallet address, ya que Rafiki es compatible tanto con Interledger como con Open Payments. ## Wallet addresses -A wallet address is a secure, unique URL for a payment account that supports Open Payments. It acts as an entry point into the Open Payments APIs, facilitating interactions like sending and receiving payments. +Un wallet address es una URL segura y única de una cuenta de pago compatible con Open Payments. Funciona como un punto de entrada a las API de Open Payments, y facilita interacciones como el envío y la recepción de pagos. -You can determine whether a URL is a wallet address by sending a `GET` request to the URL with an `accept: application/json` header. +Puede determinar si una URL es un wallet address enviando una solicitud `GET` a la URL con un encabezado `accept: application/json`. -```http title="Example request" +```http title="Ejemplo de solicitud" curl --request GET \ --url https://wallet.example.com/alice \ --header 'accept: application/json' ``` -A valid response means the URL is a wallet address. +Una respuesta válida significa que la URL es un wallet address. -```http title="Example response" +```http title="Ejemplo de respuesta" { "id": "https://wallet.example.com/alice", "publicName": "Alice", "assetCode": "USD", "assetScale": 2, - "authServer": "https://auth.wallet.example.com", - "resourceServer": "https://wallet.example.com", + "authServer": "https://auth.wallet.example.com/123e4567-e89b-12d3-a456-426614174000", + "resourceServer": "https://wallet.example.com/123e4567-e89b-12d3-a456-426614174000", } ``` -Rafiki assigns each of your customers' accounts with a wallet address. This wallet address is also a payment pointer because Rafiki supports Open Payments and Interledger. See the integration requirements for [wallet addresses](/integration/requirements/wallet-addresses) for more information. +Las URL `authServer` y `resourceServer` incluyen el identificador del tenant (UUID v4) como un segmento de ruta para garantizar que las solicitudes de Open Payments se dirijan al tenant correcto. + +Rafiki asigna un wallet address a cada una de las cuentas de sus clientes. Este wallet address también es un Payment pointer porque Rafiki es compatible con Open Payments e Interledger. Consulte los requisitos de integración para [wallet addresses](/integration/requirements/wallet-addresses) para obtener más información. diff --git a/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx b/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx index 30022300bf..73864b54e8 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx @@ -4,196 +4,197 @@ title: Telemetría import { LinkOut } from '@interledger/docs-design-system' -The objective of the telemetry feature is to gather metrics and establish an infrastructure for visualizing valuable network insights. Some of the metrics that we at the Interledger Foundation collect include: +El objetivo de la función de telemetría es recopilar métricas y establecer una infraestructura para visualizar información valiosa de la red. Algunas de las métricas que recopilamos en Interledger Foundation incluyen las siguientes: -- The total amount of money transferred via packet data within a specified time frame (daily, weekly, monthly) -- The number of transactions that have been at least partially successful -- The number of ILP packets flowing through the network -- The average amount of money held within the network per transaction -- The average time it takes for an outgoing payment to complete +- La cantidad total de dinero transferido a través de paquetes de datos en un tiempo específico (diario, semanal, mensual). +- El número de transacciones que han sido al menos parcialmente exitosas. +- El número de paquetes ILP que fluyen a través de la red. +- La cantidad promedio de dinero retenido en la red por transacción. +- El tiempo promedio que tarda en completarse un pago saliente. -Our goals are to: +Nuestros objetivos son: -- Track the growth of the network in terms of transaction sizes and the number of transactions processed -- Use the data for our own insights -- Enable you to gain your own insights +- Hacer un seguimiento del crecimiento de la red en términos del tamaño de las transacciones y la cantidad de transacciones procesadas. +- Utilizar los datos para nuestros propios análisis. +- Permitirle obtener sus propios análisis. -### Privacy and optionality +### Privacidad y opcionalidad -Privacy is a paramount concern for the Interledger Foundation. Rafiki’s telemetry feature is designed to provide valuable network insights without violating privacy or aiding malicious ASEs. Review the [Privacy](#privacy) section below for more information. +La privacidad es una preocupación primordial para Interledger Foundation. La función de telemetría de Rafiki está diseñada para proporcionar información valiosa de la red sin vulnerar la privacidad ni facilitar actividades maliciosas por parte de las ASE. Consulte la sección [Privacidad](#privacidad) a continuación para obtener más información. -The telemetry feature is currently enabled by default on test environments (environments not dealing with real money). When active, the feature transmits metrics to the testnet collector. You can opt in to sharing your metrics with a livenet collector when operating in a production livenet environment (with real money). Regardless of environment, you can also opt-out of telemetry completely. Review the [telemetry environment variables](#telemetry-environment-variables) for more information. +Actualmente, la función de telemetría está habilitada de forma predeterminada en los entornos de prueba (entornos que no manejan dinero real). Cuando está activa, la función transmite métricas al recopilador de testnet. Puede optar por compartir sus métricas con un recopilador de livenet cuando opere en un entorno de livenet de producción (con dinero real). Independientemente del entorno, también puede optar por desactivar la telemetría por completo. Revise las [variables de entorno de telemetría](#variables-de-entorno-de-telemetría) para obtener más información. -### Architecture +### Arquitectura -![Architecture diagram for Rafiki telemetry](/img/concepts-telemetry-architecture.png) +![Diagrama de arquitectura para la telemetría de Rafiki](/img/concepts-telemetry-architecture.png) ### OpenTelemetry (OTEL) -The Interledger Foundation has adopted OpenTelemetry (OTEL) to ensure compliance with a standardized framework that is compatible with a variety of tool suites. OTEL allows you to use your preferred tools for data analysis, while Rafiki is instrumented and observable through a standardized metrics format. +Interledger Foundation ha adoptado OpenTelemetry (OTEL) para garantizar el cumplimiento de un marco estandarizado compatible con una variedad de conjuntos de herramientas. OTEL permite utilizar las herramientas de análisis de datos que prefiera, mientras que Rafiki está instrumentado y puede observarse mediante un formato de métricas estandarizado. -### Telemetry Elastic Container Service (ECS) cluster +### Clúster de Elastic Container Service (ECS) de telemetría -The Telemetry Replica service is hosted on AWS ECS Fargate and is configured for availability and load balancing of custom ADOT (AWS Distro for OpenTelemetry) Collector ECS tasks. +El servicio de réplica de telemetría está alojado en AWS ECS Fargate y está configurado para la disponibilidad y el equilibrio de carga de las tareas de ECS personalizadas del recopilador ADOT (AWS Distro for OpenTelemetry). -When you opt for telemetry, metrics are sent to our Telemetry service. To enable you to build your own telemetry solutions, instrumented Rafiki can send data to multiple endpoints. This allows for the integration of a local OTEL Collector container that can support custom requirements. Metrics communication is facilitated through gRPC. +Cuando opta por la telemetría, las métricas se envían a nuestro servicio de Telemetría. Para que pueda crear sus propias soluciones de telemetría, Rafiki instrumentado puede enviar datos a múltiples puntos finales. Esto permite integrar un contenedor local de OTEL Collector que puede admitir requisitos personalizados. La comunicación de métricas se facilita a través de gRPC. -### OTEL SDK - Rafiki instrumentation +### SDK de OTEL - Instrumentación de Rafiki -The OTEL SDK is integrated into Rafiki to create, collect, and export metrics. The SDK integrates seamlessly with the OTEL Collector. +El SDK de OTEL está integrado en Rafiki para crear, recopilar y exportar métricas. El SDK se integra a la perfección con el OTEL Collector. ### Prometheus - AMP -The Interledger Foundation uses Amazon Managed Service for Prometheus (AMP) to collect data from the telemetry cluster. +Interledger Foundation utiliza Amazon Managed Service para Prometheus (AMP) para recopilar datos del clúster de telemetría. :::note -AMP offers limited configuration options and cannot crawl data outside of AWS. This limitation led us to adopt a push model, using `prometheusRemoteWrite`, instead of a pull model. For future development, we may consider hosting our own Prometheus. +AMP ofrece opciones de configuración limitadas y no puede recopilar datos fuera de AWS. Esta limitación nos llevó a adoptar un modelo push, utilizando `prometheusRemoteWrite`, en lugar de un modelo pull. Para el desarrollo futuro, podemos considerar alojar nuestro propio Prometheus. ::: ### Grafana - Grafana Cloud -Grafana Cloud is used for data visualization dashboards and offers multiple tools that extend Prometheus Promql. +Grafana Cloud se utiliza para paneles de visualización de datos y ofrece múltiples herramientas que amplían Promql de Prometheus. :::note -The Interledger Foundation initially used Amazon-hosted Grafana which did not meet our needs for embedding dashboards. Grafana Cloud offers a feature called _public dashboards_ which allows us to share dashboards. However, embedding may still pose a challenge. +Interledger Foundation inicialmente utilizó Grafana alojado en Amazon, pero no cumplía con nuestras necesidades de incrustación de paneles. Grafana Cloud ofrece una función llamada _paneles públicos_ que nos permite compartir paneles. Sin embargo, la incrustación aún puede representar un desafío. ::: -### Exchange rates +### Tipos de cambio -For telemetry purposes, all amounts collected by instrumented Rafiki should be converted to a base currency. +Para fines de telemetría, todos los importes recopilados por Rafiki instrumentado deben convertirse a una moneda base. -:::caution[Privacy reasoning] -If only two ASEs are peered over a non-USD currency and we collect data in that currency, it would be easy to determine the volumes moved between those two ASEs. To maintain privacy, we convert all amounts to a base currency. +:::caution[Justificación de privacidad] +Si solo dos ASE están interconectadas mediante una moneda distinta del USD y recopilamos datos en esa moneda, sería fácil determinar los volúmenes transferidos entre esas dos ASE. Para mantener la privacidad, convertimos todos los importes a una moneda base. ::: -If an ASE does not provide the necessary exchange rate for a transaction, the telemetry solution still converts the amount to the base currency using external exchange rates. A Lambda function on AWS retrieves and stores the external exchange rates. The function is triggered by a daily `CloudWatch` event and stores the rates in a public S3 bucket. The S3 bucket does not have versioning, and the data is overwritten daily to further ensure privacy. +Si una ASE no proporciona el tipo de cambio necesario para una transacción, la solución de telemetría igualmente convierte el importe a la moneda base utilizando tipos de cambio externos. Una función Lambda en AWS recupera y almacena los tipos de cambio externos. La función se activa mediante un evento diario de `CloudWatch` y almacena los tipos de cambio en un bucket público de S3. El bucket de S3 no tiene control de versiones, y los datos se sobrescriben diariamente para garantizar aún más la privacidad. -### Instrumentation +### Instrumentación -Rafiki has the following metrics. All data points (counter increases) are exported to collection endpoints at a configurable interval. The default interval is 15 seconds. +Rafiki tiene las siguientes métricas. Todos los puntos de datos (incrementos del contador) se exportan a los puntos finales de recopilación en un intervalo configurable. El intervalo predeterminado es de 15 segundos.
-| Metric | Type | Description | Behavior | -| ------------------------- | --------- | ------------------------------------------ | ------------------------------------------------------------------------------ | -| `transactions_total` | Counter | Count of funded outgoing transactions | Increases by 1 for each successfully funded outgoing payment resource | -| `packet_count_prepare` | Counter | Count of ILP Prepare packets that are sent | Increases by 1 for each Prepare packet that's sent | -| `packet_count_fulfill` | Counter | Count of ILP Fulfill packets | Increases by 1 for each Fulfill packet that's received | -| `packet_count_reject` | Counter | Count of ILP Reject packets | Increases by 1 for each Reject packet that's received | -| `packet_amount_fulfill` | Counter | Amount sent through the network | Increases by the amount sent in each ILP packet | -| `transaction_fee_amounts` | Counter | Fee amount sent through network | Increases by the amount sent minus the amount received for an outgoing payment | -| `ilp_pay_time_ms` | Histogram | Time to complete an ILP payment | Records the time taken to make an ILP payment | +| Métrica | Tipo | Descripción | Comportamiento | +| ------------------------- | ---------- | ------------------------------------------------ | ------------------------------------------------------------------------------- | +| `transactions_total` | Contador | Cantidad de transacciones salientes financiadas | Aumenta en 1 por cada recurso de pago saliente financiado correctamente | +| `packet_count_prepare` | Contador | Cantidad de paquetes ILP Prepare enviados | Aumenta en 1 por cada paquete Prepare enviado | +| `packet_count_fulfill` | Contador | Cantidad de paquetes ILP Fulfill | Aumenta en 1 por cada paquete Fulfill recibido | +| `packet_count_reject` | Contador | Cantidad de paquetes ILP Reject | Aumenta en 1 por cada paquete Reject recibido | +| `packet_amount_fulfill` | Contador | Importe enviado a través de la red | Aumenta según el importe enviado en cada paquete ILP | +| `transaction_fee_amounts` | Contador | Importe de comisiones enviado a través de la red | Aumenta según el importe enviado menos el importe recibido por un pago saliente | +| `ilp_pay_time_ms` | Histograma | Tiempo para completar un pago ILP | Registra el tiempo necesario para realizar un pago ILP |
-The current implementation only collects metrics on the SENDING side of a transaction. Metrics for external Open Payments transactions RECEIVED by a Rafiki instance in the network are not collected. +La implementación actual solo recopila métricas en el lado de ENVÍO de una transacción. No se recopilan las métricas de las transacciones externas de Open Payments RECIBIDAS por una instancia de Rafiki en la red. -## Privacy +## Privacidad -Rafiki telemetry is designed with a strong emphasis on privacy. The system anonymizes user data and refrains from collecting identifiable information. Since transactions can originate from any user to a Rafiki instance, the privacy measures are implemented directly at the source (each Rafiki instance). This means that at the individual level, the data is already anonymous as single Rafiki instances service transactions for multiple users. +La telemetría de Rafiki está diseñada con un fuerte énfasis en la privacidad. El sistema anonimiza los datos de los usuarios y se abstiene de recopilar información identificable. Dado que las transacciones pueden originarse desde cualquier usuario hacia una instancia de Rafiki, las medidas de privacidad se implementan directamente en el origen (cada instancia de Rafiki). Esto significa que, a nivel individual, los datos ya son anónimos, ya que las instancias individuales de Rafiki procesan transacciones de múltiples usuarios. -### Differential privacy and local differential privacy (LDP) +### Privacidad diferencial y privacidad diferencial local (LDP) -Differential privacy is a system for publicly sharing information about a dataset by describing the patterns of groups within the dataset while withholding information about individuals in the dataset. Local differential privacy (LDP) is a variant of differential privacy where noise is added to each individual’s data point before the data point is sent to the server. This ensures that the server never sees the actual data, providing a strong privacy guarantee. +La privacidad diferencial es un sistema para compartir públicamente información sobre un conjunto de datos mediante la descripción de los patrones de los grupos en el conjunto de datos, sin revelar información sobre las personas incluidas en el conjunto de datos. La privacidad diferencial local (LDP) es una variante de la privacidad diferencial en la que se agrega ruido al punto de datos de cada persona antes de que este se envíe al servidor. Esto garantiza que el servidor nunca vea los datos reales, lo que proporciona una garantía de privacidad sólida. -### Rounding technique and bucketing +### Técnica de redondeo y agrupación por intervalos -Rafiki’s telemetry implementation uses a rounding technique that essentially aggregates multiple transactions into the same value, making them indistinguishable. This is achieved by dividing the transaction values into buckets and rounding the values to the nearest bucket. +La implementación de telemetría de Rafiki utiliza una técnica de redondeo que básicamente agrega múltiples transacciones en un mismo valor, lo que las hace indistinguibles. Esto se logra dividiendo los valores de las transacciones en intervalos y redondeando los valores al intervalo más cercano. -The bucket size is calculated based on the raw transaction value. For lower value transactions, which are expected to occur more frequently, the bucket sizes are determined linearly for higher granularity. However, after a certain threshold, the bucket size calculation switches to a logarithmic function to ensure privacy for higher value transactions (which are less frequent but pose greater privacy concerns). +El tamaño del intervalo se calcula en función del valor bruto de la transacción. Para las transacciones de menor valor, que se espera que ocurran con mayor frecuencia, los tamaños de los intervalos se determinan de forma lineal para lograr una mayor granularidad. Sin embargo, después de un determinado umbral, el cálculo del tamaño del intervalo cambia a una función logarítmica para garantizar la privacidad de las transacciones de mayor valor (que son menos frecuentes pero suponen mayores preocupaciones de privacidad). -To handle outliers, a clipping technique is implemented, capping the buckets. Any value that exceeds a given threshold is placed in a single bucket. Conversely, any value that falls below a certain minimum is also placed in a single bucket. This ensures that both high and low outliers do not disproportionately affect the overall data, providing further privacy guarantees for these transactions. +Para gestionar los valores atípicos, se implementa una técnica de recorte que limita los intervalos. Cualquier valor que supere un umbral determinado se coloca en un único intervalo. Asimismo, cualquier valor que se encuentre por debajo de un mínimo determinado también se coloca en un único intervalo. Esto garantiza que tanto los valores atípicos altos como los bajos no afecten de manera desproporcionada los datos generales, lo que proporciona mayores garantías de privacidad para estas transacciones. -### Laplacian distribution +### Distribución de Laplace -The Laplacian distribution is often used in differential privacy due to its double exponential decay property. This property ensures that a small change in the data does not significantly affect the probability distribution of the output, providing a strong privacy guarantee. +La distribución de Laplace se utiliza con frecuencia en la privacidad diferencial debido a su propiedad de doble decaimiento exponencial. Esta propiedad garantiza que un pequeño cambio en los datos no afecte significativamente la distribución de probabilidad del resultado, lo que proporciona una garantía de privacidad sólida. -To achieve local differential privacy (LDP), noise is selected from the Laplacian distribution and added to the rounded values. The noise is generated based on a privacy parameter, which is calculated using the sensitivity of the function. +Para lograr la privacidad diferencial local (LDP), se selecciona ruido de la distribución de Laplace y se agrega a los valores redondeados. El ruido se genera en función de un parámetro de privacidad, que se calcula utilizando la sensibilidad de la función. -The sensitivity of a function in differential privacy is the maximum amount that any single observation can change the output of the function. In this case, the sensitivity is considered to be the maximum of the rounded value and the bucket size. +La sensibilidad de una función en la privacidad diferencial es la cantidad máxima en la que una única observación puede modificar el resultado de la función. En este caso, se considera que la sensibilidad es el valor máximo entre el valor redondeado y el tamaño del intervalo. -The privacy parameter is computed as one-tenth of the sensitivity. This parameter controls the trade-off between privacy and utility: a smaller privacy parameter means more privacy but less utility, and a larger privacy parameter means less privacy but more utility. +El parámetro de privacidad se calcula como una décima parte de la sensibilidad. Este parámetro controla el equilibrio entre privacidad y utilidad: un parámetro de privacidad más pequeño significa mayor privacidad pero menor utilidad, mientras que un parámetro de privacidad más grande significa menor privacidad pero mayor utilidad. -The noise, selected from the Laplacian distribution, is then generated using this privacy parameter and added to the rounded value. If the resulting value is zero, the value is set to half the bucket size to ensure that the noise does not completely obscure the transaction value. +El ruido, seleccionado de la distribución de Laplace, se genera utilizando este parámetro de privacidad y luego se agrega al valor redondeado. Si el valor resultante es cero, se establece en la mitad del tamaño del intervalo para garantizar que el ruido no oculte por completo el valor de la transacción. -### Currency conversion +### Conversión de moneda -Another factor that obscures sensitive data is currency conversion. In cross-currency transactions, exchange rates are provided by you, as the ASE, internally. As such, the exchange rates cannot be correlated to an individual transaction. If you don’t or can’t provide the necessary rates, an external API for exchange rates is used. The obtained exchange rates are overwritten frequently in this case, with no versioning or history access. This introduces an additional layer of noise and further protects the privacy of the transactions. +Otro factor que oculta los datos confidenciales es la conversión de moneda. En las transacciones entre distintas monedas, usted, como ASE, proporciona los tipos de cambio internamente. De este modo, los tipos de cambio no se pueden correlacionar con una transacción individual. Si no proporciona o no puede proporcionar los tipos de cambio necesarios, se utiliza una API externa para los tipos de cambio. En este caso, los tipos de cambio obtenidos se sobrescriben con frecuencia, sin control de versiones ni acceso al historial. Esto introduce una capa adicional de ruido y protege aún más la privacidad de las transacciones. -### Experimental transaction values when using the algorithm +### Valores experimentales de las transacciones al utilizar el algoritmo -The following table shows the values in the algorithm when running transactions for different amounts. The raw value increases as you move down the rows of the table. All values are in scale 4. +La siguiente tabla muestra los valores del algoritmo al ejecutar transacciones por diferentes importes. El valor bruto aumenta a medida que se desciende por las filas de la tabla. Todos los valores están en la escala 4.
-| Raw value | Bucket size | Rounded value | Privacy parameter | Laplace noise | Final value | -| --------- | ----------- | ------------- | ----------------- | ------------- | ----------- | -| 8300 | 10000 | 10000 | 1000 | 2037 | 12037 | -| 13200 | 15000 | 15000 | 1500 | 1397 | 16397 | -| 147700 | 160000 | 160000 | 16000 | -27128 | 132872 | -| 1426100 | 2560000 | 2560000 | 256000 | -381571 | 2178429 | -| 1788200 | 2560000 | 2560000 | 256000 | 463842 | 3023842 | -| 90422400 | 10000000 | 90000000 | 1000000 | 2210649 | 92210649 | -| 112400400 | 10000000 | 100000000 | 1000000 | 407847 | 100407847 | -| 222290500 | 10000000 | 100000000 | 1000000 | -686149 | 99313851 | +| Valor bruto | Tamaño del intervalo | Valor redondeado | Parámetro de privacidad | Ruido de Laplace | Valor final | +| ----------- | -------------------- | ---------------- | ----------------------- | ---------------- | ----------- | +| 8300 | 10000 | 10000 | 1000 | 2037 | 12037 | +| 13200 | 15000 | 15000 | 1500 | 1397 | 16397 | +| 147700 | 160000 | 160000 | 16000 | -27128 | 132872 | +| 1426100 | 2560000 | 2560000 | 256000 | -381571 | 2178429 | +| 1788200 | 2560000 | 2560000 | 256000 | 463842 | 3023842 | +| 90422400 | 10000000 | 90000000 | 1000000 | 2210649 | 92210649 | +| 112400400 | 10000000 | 100000000 | 1000000 | 407847 | 100407847 | +| 222290500 | 10000000 | 100000000 | 1000000 | -686149 | 99313851 |
-### References +### Referencias -Rafiki’s telemetry solution is a combination of techniques described in various white papers on privacy-preserving data collection. More information can be found in the following papers: +La solución de telemetría de Rafiki es una combinación de técnicas descritas en diversos documentos técnicos sobre la recopilación de datos con preservación de la privacidad. Se puede obtener más información en los siguientes documentos: - - Local differential privacy for human-centered computing + Privacidad diferencial local para la computación centrada en el ser humano - - Collecting telemetry data privately + Recopilación de datos de telemetría de forma privada - - RAPPOR: Randomized aggregatable privacy-preserving ordinal response + RAPPOR: Respuesta ordinal aleatorizada, agregable y con preservación de la + privacidad -## Deploy custom telemetry +## Implementación de telemetría personalizada -Rafiki allows you to build your own telemetry solution based on the OpenTelemetry (OTEL) standardized metrics format that Rafiki exposes. +Rafiki le permite crear su propia solución de telemetría basada en el formato de métricas estandarizado de OpenTelemetry (OTEL) que expone Rafiki. -You must deploy your own OTEL Collector that acts as a sidecar container to Rafiki, then provide the OTEL Collector’s ingest endpoint so that Rafiki can begin sending metrics to the collector. +Debe implementar su propio OTEL Collector que actúe como un contenedor sidecar para Rafiki, y luego proporcionar el punto final de ingesta del OTEL Collector para que Rafiki pueda comenzar a enviar métricas al recopilador. -### Telemetry environment variables +### Variables de entorno de telemetría -#### Required +#### Obligatorio -When the `ENABLE_TELEMETRY` variable is `true`, the following are required. +Cuando la variable `ENABLE_TELEMETRY` está establecida en `true`, se requiere lo siguiente.
-| Variable name | Type | Description | -| --------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `INSTANCE_NAME` | String | Your Rafiki instance's name used to communicate for telemetry and auto-peering. For telemetry, it's used to distinguish between the different instances pushing data to the telemetry collector. | +| Nombre de la variable | Tipo | Descripción | +| --------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `INSTANCE_NAME` | Cadena | Nombre de la instancia de Rafiki utilizado para comunicarse con fines de telemetría e interconexión automática. Para la telemetría, se utiliza para distinguir entre las diferentes instancias que envían datos al recopilador de telemetría. |
-#### Optional +#### Opcional
-| Variable name | Type | Description | -| -------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ENABLE_TELEMETRY` | Boolean | Enables the telemetry service on Rafiki. Defaults to `true`. | -| `LIVENET` | Boolean | Determines where to send metrics. Defaults to `false`, resulting in metrics being sent to the testnet OTEL Collector.

Set to `true` on production environments dealing with real money.

| -| `OPEN_TELEMETRY_COLLECTOR_URLS` | String | A CSV of URLs for OTEL Collectors (e.g., `http://otel-collector-NLB-e3172ff9d2f4bc8a.elb.eu-west-2.amazonaws.com:4317,http://happy-life-otel-collector:4317`). | -| `OPEN_TELEMETRY_EXPORT_INTERVAL` | Number | Indicates, in milliseconds, how often the instrumented Rafiki instance should send metrics. Defaults to`15000`. | -| `TELEMETRY_EXCHANGE_RATES_URL` | String |

Defines the endpoint Rafiki queries for exchange rates. Used as a fallback if/when [exchange rates](/integration/requirements/exchange-rates) aren’t provided.

When set, the response format of the external exchange rates API should be of type `rates`, as is expected by the rate service.

Defaults to `https://telemetry-exchange-rates.s3.amazonaws.com/exchange-rates-usd.json`, which points to a public S3 that has the previously mentioned required format, updated daily.

| +| Nombre de la variable | Tipo | Descripción | +| -------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ENABLE_TELEMETRY` | Booleano | Habilita el servicio de telemetría en Rafiki. El valor predeterminado está establecido en `true`. | +| `LIVENET` | Booleano | Determina el destino al que se enviarán las métricas. El valor predeterminado está establecido en `false`, lo que hace que las métricas se envíen al OTEL Collector de testnet.

Establezca este valor en `true` en entornos de producción que gestionan dinero real.

| +| `OPEN_TELEMETRY_COLLECTOR_URLS` | Cadena | Un CSV de URL para OTEL Collectors (por ejemplo, `http://otel-collector-NLB-e3172ff9d2f4bc8a.elb.eu-west-2.amazonaws.com:4317,http://happy-life-otel-collector:4317`). | +| `OPEN_TELEMETRY_EXPORT_INTERVAL` | Número | Indica, en milisegundos, con qué frecuencia la instancia instrumentada de Rafiki debe enviar métricas. El valor predeterminado está establecido en `15000`. | +| `TELEMETRY_EXCHANGE_RATES_URL` | Cadena |

Define el punto final que Rafiki consulta para obtener los tipos de cambio. Se utiliza como alternativa si/cuando no se proporcionan los [tipos de cambio](/integration/requirements/exchange-rates).

Cuando se establece, el formato de respuesta de la API externa de tipos de cambio debe ser del tipo `rates`, tal como lo espera el servicio de tipos de cambio.

Está establecido de forma predeterminada en `https://telemetry-exchange-rates.s3.amazonaws.com/exchange-rates-usd.json`, que apunta a un bucket público de S3 que tiene el formato requerido mencionado anteriormente, actualizado diariamente.

|
-### Example Docker OTEL Collector image and configuration +### Ejemplo de imagen Docker de OTEL Collector y su configuración -Below is an example of a Docker OTEL Collector image and configuration that integrates with Rafiki and sends data to a Prometheus remote write endpoint. +A continuación, se muestra un ejemplo de una imagen Docker de OTEL Collector y su configuración, que se integra con Rafiki y envía datos a un punto final de escritura remota de Prometheus. -You can test the configuration in our [Local Playground](/integration/playground/overview) by providing the environment variables in the preceding table to `happy-life-backend` in the `docker-compose.yml` file. +Puede probar la configuración en nuestro [Local Playground](/integration/playground/overview) agregando las variables de entorno indicadas en la tabla anterior a `happy-life-backend` en el archivo `docker-compose.yml`. -#### Docker Compose config +#### Configuración de Docker Compose ```yaml # Serves as example for optional local collector configuration @@ -213,9 +214,9 @@ happy-life-otel-collector: - '13132:13133' # health_check extension ``` -#### OTEL Collector config +#### Configuración de OTEL Collector -Supplemental documentation is available in OTEL’s Collector Configuration documentation. +Encontrará documentación complementaria en la documentación de configuración de OTEL Collector. ```yaml wrap # Serves as example for the configuration of a local OpenTelemetry Collector that sends metrics to an AWS Managed Prometheus Workspace diff --git a/packages/documentation/src/content/docs/es/overview/overview.mdx b/packages/documentation/src/content/docs/es/overview/overview.mdx index c81eb5c470..bcb0def198 100644 --- a/packages/documentation/src/content/docs/es/overview/overview.mdx +++ b/packages/documentation/src/content/docs/es/overview/overview.mdx @@ -21,11 +21,11 @@ En el contexto de Rafiki, un par es otra ASE con la que se realizan transaccione ### Pagos de comercio electrónico -Si un comerciante acepta Interledger u Open Payments como método de pago, el consumidor puede pagar con su dirección de billetera en lugar de ingresar, por ejemplo, el número de una tarjeta de crédito y otros datos personales en el sitio del comerciante. Gracias a la implementación de Interledger y Open Payments por parte de Rafiki, los titulares de cuentas pueden utilizar sus direcciones de billetera tanto para compras únicas como para compras recurrentes, como suscripciones, en cualquier lugar donde Interledger u Open Payments sean métodos de pago aceptados. +Si un comerciante acepta Interledger u Open Payments como método de pago, el consumidor puede pagar con su wallet address en lugar de ingresar, por ejemplo, el número de una tarjeta de crédito y otros datos personales en el sitio del comerciante. Gracias a la implementación de Interledger y Open Payments por parte de Rafiki, los titulares de cuentas pueden utilizar sus wallet addresses tanto para compras únicas como para compras recurrentes, como suscripciones, en cualquier lugar donde Interledger u Open Payments sean métodos de pago aceptados. ### Web Monetization -Con Web Monetization, los visitantes del sitio web pueden pagar un monto de su elección a un sitio web participante con una interacción mínima o nula. Tanto el sitio como el visitante deben tener direcciones de billetera compatibles con Open Payments para recibir y enviar pagos. Gracias a la implementación por parte de Rafiki del Protocolo de Configuración de Pagos Simples (SPSP) de Interledger y del estándar de Open Payments, puede asignar una o más direcciones de billetera a las cuentas de sus titulares, lo que permite que estas cuentas admitan pagos entrantes y salientes mediante Web Monetization de forma inmediata. +Con Web Monetization, los visitantes del sitio web pueden pagar un monto de su elección a un sitio web participante con una interacción mínima o nula. Tanto el sitio como el visitante deben tener wallet addresses compatibles con Open Payments para recibir y enviar pagos. Gracias a la implementación por parte de Rafiki del Protocolo de Configuración de Pagos Simples (SPSP) de Interledger y del estándar de Open Payments, puede asignar uno o más wallet addresses a las cuentas de sus titulares, lo que permite que estas cuentas admitan pagos entrantes y salientes mediante Web Monetization de forma inmediata. ## Interledger diff --git a/packages/documentation/src/content/docs/es/v1-beta/overview/concepts/payment-pointers.mdx b/packages/documentation/src/content/docs/es/v1-beta/overview/concepts/payment-pointers.mdx index 006ab25b59..13460fda74 100644 --- a/packages/documentation/src/content/docs/es/v1-beta/overview/concepts/payment-pointers.mdx +++ b/packages/documentation/src/content/docs/es/v1-beta/overview/concepts/payment-pointers.mdx @@ -1,5 +1,5 @@ --- -title: Apuntadores de pago y direcciones de billeteras +title: Payment pointers y wallet addresses slug: es/v1-beta/overview/concepts/payment-pointers --- diff --git a/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx b/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx index 9592230894..2f8661193f 100644 --- a/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx +++ b/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx @@ -2,6 +2,8 @@ title: Clearing and settlement --- +import { LinkOut } from '@interledger/docs-design-system' + ## Clearing When a payment is made over traditional banking rails, the money doesn't move instantly. First, there are checks to confirm that the money exists and can be transferred. Clearing networks are responsible for exchanging messages between ASEs to facilitate these checks. This process is called clearing. When a payment successfully clears, it means the payer's ASE has an obligation to the payee's ASE. @@ -12,7 +14,7 @@ The [Interledger Protocol (ILP)](/overview/concepts/interledger) isn't a traditi - Peered ASEs exchange ILP packets, which are packets of value that contain transaction information. ILP packets are akin to the messages exchanged during the traditional clearing process. - The successful exchange of ILP packets between peers creates obligations between them that must be settled. The receipt of a fulfilled ILP packet is basically a conditional IOU—a promise to pay—that affects the financial accounting balances between the peers. -You can read more about clearing as it relates to ILP in the [Interledger developer docs](https://interledger.org/developers/rfcs/peering-clearing-settling/). +You can read more about clearing as it relates to ILP in the Interledger developer docs. Conceptually, Rafiki sits at the clearing level, but isn't a clearing network. It's software that makes implementing the Interledger protocol faster and easier. Rafiki uses ILP to [track liquidity](/overview/concepts/accounting) between assets, payments, and peers. An ASE must still connect Rafiki to their existing backend system and internal ledger for authentication, fetching exchange rates, and managing liquidity itself. For example, if an incoming payment completes in Rafiki, the ASE's backend must credit the recipient's account on their own system, however that might look. @@ -24,6 +26,6 @@ In traditional banking, settlement is the fulfillment of an obligation between A When a payer's ASE settles with the payee's ASE, there's a high chance that the ASE isn't physically handing over cash. There’s more likely to be an intermediary, like a reserve bank or central bank, that maintains accounts for both ASEs. The intermediary moves funds from one account to the other, crediting and debiting the accounts as necessary. -With Interledger, the concept of settlement isn't that different. Each [peer](/integration/requirements/peers) must agree on a settlement system to use to fulfill their obligations with one another. However, ILP itself isn't a settlement system. This means peers must have some other way to fulfill their obligations and exchange value. Examples can include using a real-time gross settlement system like Fedwire, an automated clearing house (ACH) network, a money transfer service, or some other payment channel. You can read more about settling as it relates to ILP in the [Interledger developer docs](https://interledger.org/developers/rfcs/settlement-engines/). +With Interledger, the concept of settlement isn't that different. Each [peer](/integration/requirements/peers) must agree on a settlement system to use to fulfill their obligations with one another. However, ILP itself isn't a settlement system. This means peers must have some other way to fulfill their obligations and exchange value. Examples can include using a real-time gross settlement system like Fedwire, an automated clearing house (ACH) network, a money transfer service, or some other payment channel. You can read more about settling as it relates to ILP in the Interledger developer docs. Rafiki is also not a settlement system. It [keeps track of liquidity](/overview/concepts/accounting) through liquidity and settlement accounts. Liquidity accounts track deposit, withdrawal, and transfer amounts. Settlement accounts track the availability of funds, denominated in a single asset. A negative balance means funds are available. The closer a settlement account's balance is to zero, the more likely it is that one peer needs to settle with the other over their agreed-upon settlement system. diff --git a/packages/documentation/src/content/versions/v1-beta.json b/packages/documentation/src/content/versions/v1-beta.json index a9251341e0..4597f89640 100644 --- a/packages/documentation/src/content/versions/v1-beta.json +++ b/packages/documentation/src/content/versions/v1-beta.json @@ -58,7 +58,7 @@ { "label": "Payment pointers and wallet addresses", "translations": { - "es": "Apuntadores de pago y direcciones de billeteras" + "es": "Payment pointers y wallet addresses" }, "link": "/overview/concepts/payment-pointers" },