Dos claves. La app solo respalda una.
En un espacio de trabajo de Hachiflow intervienen dos claves distintas. Tienen la misma forma, ambas empiezan con nsec y se confunden todo el tiempo. Una prueba que usted es usted. La otra prueba que el espacio es suyo. Antes de leer cualquier otra cosa en esta página, lea la tabla. Si lo que busca es la guía de instalación, está en conecte su app.
Una prueba quién es usted. La otra, qué le pertenece.
Buzz crea su clave de identidad personal en su propio dispositivo la primera vez que lo abre. Nuestro plano de control genera la clave de dueño del espacio cuando construye su espacio de trabajo. Ninguna sabe nada de la otra y no son intercambiables. Perder una es una molestia. Perder la otra, sin nada en custodia, termina con el espacio de trabajo.
| En qué difieren | Clave de identidad personal | Clave de dueño del espacio |
|---|---|---|
| Quién la genera | Su propio dispositivo, mediante Buzz, en el primer arranque. | Nuestro plano de control, cuando su espacio de trabajo se provisiona. |
| Qué prueba | Soy esta persona. | Este espacio de trabajo es mío. |
| Dónde vive | En el llavero de su sistema. | Nuestra custodia, que podemos leer, y donde usted la guarde después de reclamarla. |
| Si la pierde | Solo se recupera de lo que usted guardó al cerrar sesión. | Puede volver a pedírnosla en app.hachiflow.com/keys. |
| La respalda el aviso de Buzz al cerrar sesión | Sí. | No. |
El aviso respalda la clave equivocada
Buzz le pide guardar su clave cuando cierra sesión. Eso respalda su identidad personal, no su espacio de trabajo. El aviso es una red de seguridad real y es la forma más fácil de sacar su propia clave de una app en funcionamiento. También es la razón por la que alguien cuidadoso puede guardar una clave, archivarla como corresponde, sentirse cubierto y no tener ni una copia de la clave que de verdad confiere la propiedad.
Nuestra custodia es el único respaldo de la clave que confiere la propiedad. Ese es el contenido honesto de para qué existe la custodia.
Las dos claves son una cadena nsec1... y ninguna dice cuál es cuál. Etiquételas al guardarlas. Con «clave de dueño de yourteam» y «mi identidad de Buzz» alcanza.
La raíz de la autoridad, y guardamos una copia a propósito.
La clave de dueño de su espacio es un par de claves criptográficas real, generado cuando se construyó el espacio. Es la que su relay reconoce como dueña. Quien la tenga es el dueño, y por eso conviene cuidarla, y por eso guardamos una copia: para que una clave perdida no sea un espacio muerto.
¿Qué es la clave de dueño del espacio?
La credencial raíz de su espacio de trabajo. Prueba la propiedad ante el relay, permite actuar como administrador dentro del espacio sin nosotros, y es lo que necesita para mover el espacio a su propia infraestructura o entregárselo a otra persona.
Es suya, no nuestra. Somos una empresa de hosting, no un portero parado entre usted y su propio espacio de trabajo. Si desapareciéramos mañana, la clave de dueño más un respaldo es todo lo que necesita para levantar su espacio en otro lado.
¿Qué pasa cuando la reclamo?
La reclama en el panel, en app.hachiflow.com/keys. Hay dos pasos antes de que ocurra algo: una pantalla que explica a qué lo compromete reclamarla y otra que lo confirma. La clave se imprime después, en una sola pantalla. Tenga su gestor de contraseñas abierto antes de empezar, porque esa página no la vuelve a imprimir.
Reclamarla no destruye nada. Ninguna clave se rota, nada se revoca y su espacio sigue funcionando igual que antes. Nuestro plano de control registra cada entrega, repeticiones incluidas, así que el rastro muestra cada vez que la clave salió de aquí y a qué dirección fue. Si la pierde más adelante, podemos entregar de nuevo la copia en custodia una vez que verifiquemos quién es usted.
¿Guardan una copia, y pueden leerla?
Sí a las dos. Los secretos de su espacio están en almacenamiento de objetos privado al que solo llegan nuestras credenciales, en Cloudflare R2, que los cifra en reposo con sus propias claves y los mueve por TLS. Eso frena un disco robado y a cualquiera que no tenga nuestras credenciales. A nosotros no nos frena, y no vamos a insinuar lo contrario.
Que podamos leerla es el mecanismo, no una falla. Devolverle una clave que perdió solo es posible mientras exista una copia que podemos leer. Si prefiere que no podamos, dígalo y borramos nuestra copia. Una advertencia que preferimos decirle nosotros a que la descubra: también hay una copia en cada respaldo que conservamos, y guardamos los 14 más recientes, así que la última copia legible desaparece unas dos semanas después de pedirlo, no el mismo día. Dígalo y purgamos también los respaldos. Cuando ya no quede ninguna, perder la suya significa que nadie puede recuperar el espacio de trabajo, nosotros incluidos. Sin reinicio, sin excepción, sin puerta trasera. Muchos clientes quieren exactamente eso, es una elección legítima y no es reversible.
¿Dónde la guardo?
En un gestor de contraseñas. 1Password, Bitwarden, lo que su equipo ya use. No en un papelito, no en un mensaje a usted mismo, no en un archivo llamado key.txt en su laptop. Trátela como la contraseña de root de un servidor que no puede reconstruir.
¿Quién puede reclamarla?
El dueño de ese espacio con sesión iniciada, y nadie más. Un espacio que su dirección no posee responde exactamente como si no existiera, así que la página no sirve para averiguar si el espacio de otra persona es real. Cada reclamo queda registrado con la dirección a la que se entregó.
Su clave personal se crea en su propia máquina.
Buzz usa una clave de identidad en lugar de una cuenta. Cada miembro de un espacio, humano o agente, firma todo lo que hace con su propio par de claves, y eso es lo que hace que el rastro de auditoría valga algo. Su clave personal se crea localmente y queda en el llavero de su sistema. Nosotros nunca la vemos.
¿Qué es mi clave de identidad personal?
El par de claves que lo representa en cualquier espacio de Buzz. Buzz lo crea en el primer arranque, lo guarda en el llavero de su sistema operativo y firma sus mensajes con él. Su mitad pública es su ID público, seguro de compartir. Su mitad privada no debería salir nunca de su máquina.
Buzz me pidió guardar mi clave al cerrar sesión. ¿Cuál era esa clave?
Su clave de identidad personal. Ese aviso no toca en absoluto la clave de dueño del espacio, y guardarla no es un respaldo del espacio de trabajo. Si el espacio le importa, reclame la clave de dueño por separado y guárdela por separado.
Elegí «Create a new identity key» y me dio una clave que ya tenía
Lo reprodujimos en Buzz 0.5.2. En una instalación que ya tiene una identidad en el llavero, «Create a new identity key» puede informar que se creó una clave y devolver después la existente. Estamos preparando el reporte para el proyecto original.
Aquí importa por una razón. Si primero importó la clave de dueño del espacio y luego apretó ese botón esperando una identidad personal aparte, puede seguir teniendo la credencial raíz del espacio creyendo que no la tiene. Si no sabe qué identidad tiene una instalación, mándenos el ID público que muestra y le decimos si es su clave de dueño.
¿Debería pegar la clave de dueño en la app?
Funciona. La clave de dueño ya está inscrita en su relay, así que pegarla en «Use an existing key» y luego escribir la URL de su relay lo deja adentro con la condición de dueño. Recorrimos ese camino en un espacio recién provisionado.
Igual sugerimos el orden inverso: cree una identidad personal, mándenos su ID público para inscribirlo y reclame la clave de dueño después, a propósito, directo a un gestor de contraseñas. Importar la clave de dueño pone su credencial raíz en una laptop desde el primer día.
Dos puertas funcionan. Otras dos llevan a otro lado.
Block construye Buzz y también lo hospeda. Dos botones de la app son para ese hosting, y están rotulados justo como un dueño esperaría, así que un dueño los aprieta. Nuestra puerta es otra. Saber cuál es cuál antes de empezar le ahorra el desvío.
¿Qué botones me meten a un espacio de trabajo de Hachiflow?
En «Join or create a community», elija «Join a community» y pegue la URL de su relay. Si en cambio la app le pregunta su rol, elija «I'm a member or admin» y pegue la URL de su relay ahí. Su rol se restaura al conectarse, así que un dueño no necesita el botón rotulado para dueños.
¿Qué pasa si aprieto «Create a community» o «I own the community»?
Los dos abren Builderlab en su navegador. Builderlab es el servicio de hosting que Block ofrece para Buzz, y esos dos botones son la forma de iniciar sesión ahí. No tienen nada de malo y nada se rompe si aprieta uno. Son para el hosting de Block, no para un espacio que hospedamos nosotros, que es otra puerta con un rótulo menos obvio.
Si termina ahí, vuelva un paso atrás en la app y tome una de las dos puertas de arriba.
¿Siempre necesito la URL del relay?
Sí, en cualquier instalación nueva. Una clave es un par de claves y nada en ella apunta a un nombre de host, así que ninguna clave puede decirle a la app dónde está su espacio. Su URL de relay se ve así: https://yourteam.hachiflow.chat. Esa URL, o un enlace de invitación que la lleve, va en el campo «Invite link or community URL».
Pegué una clave y mi espacio apareció sin URL
Esa instalación ya se había conectado antes y la app restauró el estado local de una sesión anterior. En una máquina nueva no va a pasar. Guarde la URL del relay en algún lugar donde la encuentre en vez de confiar en ese comportamiento.
La app dice «Not a member yet»
Su relay admite las claves que fueron inscritas en él, y la identidad que Buzz acaba de crearle no lo está. La pantalla muestra su ID público con un botón de copiar y le dice que lo envíe a un administrador del relay. En un espacio que hospedamos nosotros, ese administrador somos nosotros.
Escriba a hello@hachiflow.com con su ID público y el nombre de su espacio. Inscribirlo toma segundos, y la app quita el bloqueo en cuanto usted aprieta «Try again». Mándenos el ID público antes de conectarse y no verá esa pantalla nunca. Nada de lo que nos manda para entrar es secreto.
La versión paso a paso de todo esto, de la descarga al primer mensaje, está en conecte su app.
Nunca le vamos a pedir su clave privada.
Una identidad pública se entrega sin riesgo. Una clave privada no, y no existe ninguna razón legítima para que alguien se la pida. Esta sección es corta, y es la parte que vale la pena recordar.
¿Por qué me piden mi ID público?
Porque es la mitad que se puede regalar sin riesgo. Su ID público, un npub, lo nombra sin concederle nada. Inscribirlo en su relay es lo que convierte «Not a member yet» en un espacio de trabajo. La app dice lo mismo en la pantalla donde lo ofrece: esta es su identidad pública, es seguro compartirla.
¿Hachiflow me va a pedir alguna vez mi clave privada?
No. Nunca, por ningún canal. Ni por correo, ni en un hilo de soporte, ni por teléfono, ni en un formulario de este sitio. No la necesitamos. Todo lo que hacemos por usted se hace con su ID público o con la clave de dueño en custodia que ya tenemos.
Nadie legítimo se la va a pedir. Ni nosotros, ni Block, ni un compañero de equipo, ni nadie que se presente como soporte. Trate cualquier pedido de una clave privada como un ataque, por normal que parezca, y mándelo a hello@hachiflow.com para que lo veamos con usted.
¿macOS se va a negar a abrir Buzz?
No. La app está firmada por Block, Inc. y notarizada, el ticket viene adjunto y spctl responde accepted. No hay muro de desarrollador no identificado, no hay ritual de clic derecho, no hay nada que quitarle a la descarga. Un hábito que vale la pena: arrastre Buzz a Aplicaciones y ábralo desde ahí en vez de correrlo desde la imagen de disco montada.
¿Todas las plataformas están así?
No, y no vamos a fingir lo contrario. La app dentro de la imagen de disco de macOS está firmada y notarizada, pero el envoltorio .dmg en sí no está firmado, así que quien revise la descarga con codesign lo va a ver y se va a preocupar con razón. La versión de Windows se publica hoy como una alfa sin firmar y SmartScreen avisa sobre ella.
Los agentes son ilimitados, y el motivo es estructural.
Usted paga por un espacio de trabajo, no por los miembros que hay en él. No contamos agentes ni los vendemos por cabeza, y no es generosidad: la parte cara de un agente corre de su lado de la línea, no del nuestro.
¿Cuántos agentes puedo correr?
Tantos como pida el trabajo. No hay cargo por agente ni complemento de agentes. Un agente es miembro de su relay: su propio par de claves, su propio acceso a canales, su propia historia firmada, así que usa almacenamiento y capacidad de relay como un compañero activo. Lo que no usa es nuestro cómputo.
¿Dónde corre realmente un agente?
En su máquina, por defecto. La app de escritorio arranca el runtime del agente como un proceso hijo local, y lo vimos hacer exactamente eso en una lista de procesos. La inferencia corre con sus propias claves de LLM, facturada a usted por su proveedor al costo. Nunca intermediamos ese tráfico y nunca le sumamos margen a la inferencia.
¿Mis agentes hay que inscribirlos por separado?
No. Un agente recibe su propio par de claves, y su relay lo admite por la fuerza de una atestación firmada con su clave. La app emite esa atestación y la pasa al runtime sin que usted haga nada. Lo verificamos contra un espacio en funcionamiento: la misma clave de agente fue rechazada sin la atestación y aceptada con ella, y nunca entró en la lista de miembros.
¿Dónde viven mis claves de proveedores de LLM?
No en el llavero, y nunca con nosotros. Buzz guarda las claves de identidad en el llavero de su sistema, pero las claves de API de proveedores las escribe en sus propios archivos de configuración dentro del directorio de datos de la app en su máquina, legibles solo por su cuenta de usuario. Una clave de proveedor nunca llega a nosotros: no está en nada que aprovisionemos, guardemos ni respaldemos. Conviene saberlo en los dos sentidos antes de que lo pregunte una revisión de seguridad.
Qué vuelve, y qué no.
La respuesta depende por completo de cuál clave perdió, y por eso el resto de esta página le dedica tanto espacio a la diferencia. Busque su caso.
Perdí mi clave de identidad personal
Si la guardó al cerrar sesión, impórtela otra vez en «Use an existing key». Si no, se fue: solo vivió en su llavero y nosotros nunca tuvimos copia. Nada de su espacio de trabajo se pierde. Cree una identidad nueva, mándenos el ID público nuevo y lo inscribimos. Sus mensajes viejos quedan donde están, en su relay, firmados por la clave vieja.
Perdí la clave de dueño del espacio
Pídanosla. Todavía tenemos la copia en custodia y la entregamos de nuevo una vez que verificamos quién es usted. Escriba a hello@hachiflow.com desde la dirección que es dueña del espacio. Mientras lo resuelve, su espacio no se ve afectado en nada: el uso diario no depende de que usted tenga esa clave.
Perdí las dos
Entonces está en el caso común. Genere una identidad personal nueva y mándenos su ID público, lo que lo devuelve al espacio de trabajo, y pida la clave de dueño de la custodia en el mismo correo. Lo primero son minutos. Lo segundo espera a que verifiquemos quién es usted, y no es urgente.
Les pedí borrar la copia en custodia y ahora no tengo mi clave
Entonces el espacio de trabajo no se puede volver a poseer. Ni usted, ni nosotros, ni nadie, y no vamos a fingir que hay una vuelta a lo que eligió a propósito. Sus datos siguen en un servidor que operamos y todavía podemos exportárselos por completo.
Antes de concluir que la clave se fue, busque en todos los lugares donde podría estar: el historial del gestor de contraseñas, una lista de elementos borrados, una laptop vieja, una copia impresa en una caja fuerte. Aparecen más seguido de lo que uno pensaría.
Respalde la clave que confiere la propiedad.
Reclámela, póngala en un gestor de contraseñas, etiquétela. Después díganos si quiere que nuestra copia se conserve o se borre. Escriba a hello@hachiflow.com con el nombre de su espacio y le responde una persona. Durante el acceso temprano, quienes responden son quienes operan su relay.
Escríbanos sobre claves