1. Chad y Willem de Aha Labs discuten las actualizaciones del nuevo y mejorado stellar-cli
2. Algunos aspectos destacados incluyen el cambio del nombre 'soroban' a 'stellar' al usar la herramienta CLI y la adición de nuevos comandos.
3. They cover some cool functions like local network setup, account creation, and transaction signing. con los siguientes comandos:
   • stellar network container [start|logs]
   • stellar keys [generate|fund|ls]
   • stellar contract init para obtener un nuevo proyecto de Soroban
   • ¡y mucho más!
4. They also discuss expected future updates including support for more Stellar operations and integration with Stellar Lab V2!

1. Kirckz discute Meru, una aplicación de servicios financieros para freelancers y trabajadores remotos en América Latina.
2. Él comparte su experiencia integrando Meru con Blend, un protocolo de liquidez primitiva para Stellar.
3. Kirckz comparte los desafíos enfrentados durante la integración y cómo fueron superados.
4. Él comparte los sdks y bibliotecas que su equipo utilizó para facilitar la integración.

Sigue a Meru en X (anteriormente Twitter) para mantenerte actualizado: https://x.com/getmeru

1. Tyler creó Super Peach, una aplicación web3 que utiliza claves de acceso para firmar transacciones. Demostró cómo se pueden usar las claves de acceso en flujos de autorización y cómo se pueden usar para firmar transacciones.
   • Código: https://github.com/kalepail/superpeach
   • Demostración: https://superpeach.xyz
2. Se presentó passkey-kit. Un SDK de TypeScript para crear y gestionar billeteras inteligentes a través de claves de acceso (incluye la interfaz de billetera inteligente)
   • Código: https://github.com/kalepail/passkey-kit
   • Demostración: https://passkey-kit-demo.pages.dev
3. Se presentó Launchtube, un servicio para enviar transacciones en cadena cubriendo tanto la tarifa de transacción COMO el número de secuencia. ¡Increíble!
   • Código: https://github.com/kalepail/launchtube (pregunta en el canal #passkeys en Discord por un token de testnet)
4. Compartió su visión para impulsar la implementación de las claves de acceso hasta convertirse en un estándar para el ecosistema.

Únete al canal #passkeys en Discord para continuar la discusión

1. Tyler desarrolló una aplicación de votación utilizando claves de acceso para firmar la transacción, que es una implementación de la función de verificación secp256r1.
2. Mostró una implementación multiplataforma (web y móvil) y demostró que las claves de acceso son la interfaz perfecta entre los contratos web3 y los mecanismos de autenticación web2 a los que la mayoría de los usuarios finales están acostumbrados.
3. Los miembros del ecosistema discutieron el uso de billeteras inteligentes que utilizarían claves de acceso como firmantes. Se identificaron desafíos en torno a las tarifas requeridas para las billeteras inteligentes, la necesidad de una implementación común para una billetera inteligente, así como cómo podría interactuar con los administradores de contraseñas existentes.
4. La aplicación de votación se puede probar en passkey.sorobanbyexample.org/
5. El código para la demo está aquí github.com/kalepail/soroban-passkey

Hilo de Agenda de Discord

1. Fifo presentó Stellar Plus, que es una biblioteca de Javascript para simplificar el desarrollo de Stellar y Soroban.
2. Los miembros del ecosistema encontraron el diseño de Stellar Plus como composable e inclusivo de toda la funcionalidad relacionada con Stellar, incluyendo la gestión de activos, cuentas, operaciones relacionadas con wasm, así como utilidades RPC.
3. Los enlaces a la presentación de Fifo y Stellar Plus son:
   • Tablero de Miro mostrando la arquitectura de Stellar Plus
   • Repositorio de Stellar Plus
   • Repositorio de Ejemplos
   • Documentos

1. Garand discussed changes to the State Archival proposal based on feedback received at Meridian 2023. Los cambios propuestos son:

• Anteriormente, un sistema de downstream llamado el ESS (Almacenamiento de Estado Caducado) almacenaba entradas caducadas. En la nueva propuesta, no hay ESS. En la nueva propuesta, no hay ESS. Todas las entradas archivadas, así como toda la información requerida para generar pruebas de restauración para esas entradas, se almacena directamente en el Archivo de Historia.
• Los nodos RPC pueden generar pruebas para el estado archivado durante el pre-vuelo
• Captive-core puede ser consultado directamente para el estado archivado, lo que significa que las instancias RPC/Horizon pueden potencialmente atender consultas para el estado de archivo

2. La propuesta de borrador
3. Discusión en curso
4. El tamaño de la imagen está por determinar; es una función del tamaño de la lista de cubos, así como de la memoria y las demandas históricas impuestas al RPC.
5. Los filtros de Bloom son la solución probable para la prueba de inexistencia, aunque vienen con compensaciones. Permiten una búsqueda rápida y económica, pero son probabilísticos, no deterministas.
6. Se agradecen más comentarios.

Discord agenda thread

1. Justin de ortege.ai hizo una demostración de Ortege, una plataforma de análisis de datos para Stellar y Soroban.
2. Ortege permite que cualquier persona en el ecosistema Stellar cree paneles de control para rastrear cualquier métrica deseada. Las consultas, widgets y paneles de control de Ortege son compartibles, lo que lo convierte en la plataforma perfecta para mostrar
3. Justin lanzará pronto una IA y habilitará la consulta y los conocimientos a través del lenguaje natural.
4. Todos están invitados a crear una cuenta gratuita y rastrear las métricas de éxito para su panel de control.

Piyal de Freighter discutió la propuesta para estandarizar la interfaz de billetera. Los puntos clave de la discusión se capturan a continuación. Para notas completas, por favor ve la grabación; y también consulta la propuesta y la publicación en las discusiones de github.

1. La propuesta borrador
2. Discusión en curso
3. Requerir la frase de paso de la red podría ser una complejidad innecesaria.
4. Tanto WalletConnect como las billeteras móviles probablemente tienen diferencias significativas respecto a la interfaz propuesta (que está dirigida a billeteras de extensiones de navegador); y por lo tanto es probable que requieran un SEP separado. Los SEPs mencionados deberían ser creados por equipos que trabajen en la integración de billeteras con las plataformas mencionadas.
5. ¿Cuál es el papel de Stellar Wallet Kit en el ecosistema y cómo interactúa con el estándar mismo?
6. Como próximos pasos, Piyal incorporará las sugerencias del ecosistema en la propuesta.

La grabación de hoy tiene dos partes. Los primeros 12 minutos son solo audio. Los próximos 45 minutos también tienen video. Ten en cuenta que las diapositivas se compartieron en el chat de discord mediante la pantalla compartida, debido a dificultades técnicas.

Parte 1 (solo audio):

Parte 2 (video):

Hilo de Agenda de Discord

1. Piyal propuso un Estándar de Billetera y solicitó retroalimentación.
2. Cubist, un proyecto del ecosistema, discutió CubeSigner, una API de baja latencia para generar claves y firmar transacciones dentro de hardware seguro.
3. Un ejemplo de CubeSigner basado en Stellar está disponible en el repositorio de Cubist Labs en Github
4. Los desarrolladores de Cubist pueden ser contactados a través del discord de Stellar o del formulario web.

Agenda thread

1. El Grupo de Trabajo de Normas propuso cambios al proceso SEP que empoderan al ecosistema al hacer que el proceso actual sea más descentralizado y amigable con el ecosistema.
2. El proceso ya ha sido utilizado para varias propuestas en los últimos tres meses.
3. Esteblock from Soroswap shared their journey of participating in the proposal for Asset List (SEP-42) and implementing the proposed standard
4. La discusión continúa en el documento de propuesta.
5. El siguiente paso es obtener más retroalimentación del ecosistema y luego actualizar el repositorio de SEP de Github con el proceso SEP actualizado.

Hilo de agenda de Discord

1. Hay una discusión sobre un cambio de meta TX que aumenta la visibilidad y los análisis dentro de la red Stellar. (https://github.com/stellar/stellar-xdr/pull/175)
2. Se explica que las invocaciones de solo lectura para contratos garantizan que ciertas funciones sigan siendo de solo lectura sin efectos secundarios. (https://github.com/stellar/stellar-protocol/discussions/1454) (https://github.com/stellar/stellar-protocol/discussions/1456) (https://github.com/stellar/stellar-protocol/discussions/1464)
3. Se introduce la habilitación del descubrimiento de contratos para mejorar la visibilidad y autenticidad de los contratos inteligentes dentro del ecosistema Stellar.
4. Se propone la implementación de un esquema de metadatos estándar de contrato para vincular contratos con código fuente y mejorar la capacidad de descubrimiento de contratos.(https://docs.rs/soroban-sdk/latest/soroban_sdk/macro.contractmeta.html)
5. Las incidencias relacionadas con las tarifas de inclusión en la red Stellar destacan la importancia de monitorear las tarifas de cerca y comprender las implicaciones de los precios de aumento. (https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#inclusion-fee)
6. Se discuten planes para diseñar un nuevo punto final RPC que brinde a los desarrolladores mejor visibilidad e información sobre el establecimiento de tarifas de inclusión, con el objetivo de mejorar la transparencia y la toma de decisiones respecto a las compensaciones de tarifas.

Discord agenda thread

1. El equipo principal de CAP deliberó sobre las últimas propuestas presentadas por el ecosistema Stellar para avanzar stellar-core.
2. Nicholas y David del equipo principal de CAP escucharon las siguientes propuestas y discutieron las propuestas con los autores. a. El equipo principal de CAP enviará su voto por correo electrónico.
3. Propuestas discutidas:
   a. CAP-51: agregar soporte para la verificación secp256r1; por @leigh
   b. CAP-53: crear funciones separadas para extender el tiempo de vida de la instancia de contrato y del código del contrato; por @tdep
   c. CAP-54: reducir los costos totales refinando el modelo de costos de Soroban utilizado para la creación de instancias de VM en varios costos separados y más precisos; por @graydon
   d. CAP-55: reducir los costos totales al vincular menos funciones host durante la creación de instancias de VM en Soroban; por @graydon
   e. CAP-56: reducir los costos totales almacenando en caché los módulos Wasm analizados dentro de una transacción de Soroban; por @graydon