"¿Cuánta eficiencia estoy sacrificando al hacer que mi aplicación sea criptográfica en lugar de dependiente de la confianza?" Aunque VB está hablando de algo diferente aquí, esta pregunta que plantea es realmente fundamental para el pensamiento de todos los constructores de aplicaciones de privacidad, incluido nosotros @fileverse. Sin embargo, hay un lado positivo en esto. Al perder "eficiencia" en tu aplicación al minimizar sus suposiciones de confianza y la recopilación de datos (por ejemplo, tener garantías de anonimato basadas en e2ee y zk), obtienes otras mejoras en la experiencia del usuario que realmente compensan esto. Algunas de mis favoritas: - incorporación más rápida. La identidad criptográfica para registros/inicios de sesión puede ser más rápida que los flujos de OAuth convencionales con diálogos de confianza y verificaciones que son una carga cognitiva. - portabilidad e interoperabilidad. Todo sigue tus claves, no experimentas los dolores de migración centralizados (como cambios de políticas arbitrarios). - operaciones básicas fuera de línea. Con menos coordinación de confianza y compartición de datos necesaria, tu aplicación puede funcionar parcialmente sin conexión. Actualizaciones del estado criptográfico local → sincronización cuando la conexión esté disponible.