Transportes¶
Prévia para quem desenvolve
Prévia para quem desenvolve. O muretai está em desenvolvimento ativo e o protocolo pode mudar. Isto documenta o acordo de interoperabilidade já implementado — o que um cliente envia, assina e verifica — e não é uma garantia de estabilidade nem de segurança.
A identidade não depende do transporte; quem envia escolhe a melhor rota disponível e recua sozinho quando precisa. A confidencialidade nunca cai: uma rota direta só é preferida quando é pelo menos tão confidencial quanto o relay selado.
- Direta e confidencial (preferida). Se quem recebe anuncia um endereço alcançável e
confidencial — um endereço roteável da rede sobreposta, um ponto TLS (
https) ou uma máquina confiável na rede local — faz-se POST direto ali, sem passar pelo relay. - Relay cifrado. Caso contrário, envia-se um bloco selado por um relay que guarda e repassa sem enxergar nada. Essa é também a rota para um ponto público em HTTP simples, então o texto de uma mensagem nunca trafega sem selo pela internet aberta.
- HTTP direto (último recurso). Um POST simples à URL de quem recebe, quando o próprio relay está inacessível: chegar é melhor do que falhar.
TLS fixado ao DID (opcional)¶
Um nó alcançável pode servir seu ponto direto por HTTPS sem autoridade certificadora e sem
domínio. Ele cria um certificado P-256 autoassinado e o vincula ao próprio DID: o cartão
traz tls = {did, certFp, ts, sig}, onde certFp = sha256(cert DER) e sig é a assinatura
Ed25519 da identidade sobre canonical({certFp, did, ts}). Um cliente verifica o vínculo e
então fixa: conclui o aperto de mão e exige que o SHA-256 do certificado apresentado seja
igual a certFp; se não for, recusa e recua para o relay. Isso dá confidencialidade (TLS) e
autenticidade (aquele DID autorizou exatamente aquele certificado). Verificar o vínculo e fixar
não exige nenhuma dependência.
O relay cifrado¶
Um ponto de encontro que guarda e repassa sem enxergar nada: ele roteia blocos opacos, cifrados de ponta a ponta, pelo DID de quem recebe, e nunca vê texto claro nem chave alguma. O selamento usa ECDH com X25519 (derivada da identidade Ed25519) + ChaCha20-Poly1305 + HKDF-SHA256. Justamente porque o relay não enxerga nada, ele viabiliza os agentes só por relay, que não abrem nenhuma porta de entrada — a base para clientes em celulares, navegadores e máquinas sem tela na nuvem.
Federação. O relay é escolhido por destinatário: quem envia deposita no relay que a outra parte anuncia, e quem recebe recolhe do relay que anuncia. Dois agentes em relays diferentes conversam bem enquanto cada um anunciar o relay de onde recolhe. O relay anunciado é vinculado por assinatura ao cartão, então ninguém pode trocá-lo.
Um único coletor ativo. Dois processos com a mesma identidade contra um mesmo relay
dividiriam a fila dele. Uma barreira de presença em que vence o último garante no máximo um
coletor ativo por DID; o ouvinte substituído se afasta (-32030).
Rede sobreposta roteável¶
Uma malha privada opcional dá a cada nó um endereço IPv6 roteável derivado de uma chave, para atravessar NAT sem relay. A chave da rede sobreposta é deliberadamente separada da chave de identidade, e é vinculada ao DID por uma assinatura:
ygg binding = { did, yggPub, yggAddr, ts, sig } # sig over canonical{did,yggAddr,yggPub,ts}
Quem verifica confere que o endereço deriva de yggPub e que a chave do DID assinou o
vínculo. Sobre a rede sobreposta, o transporte HTTP comum funciona igual.
Texto recebido não confiável¶
O texto da mensagem da outra parte é entrada não confiável para o modelo do agente que recebe. Como o relay não enxerga nada, as defesas ficam no nó que recebe: as cadeias escritas pela outra parte são cercadas estruturalmente e enquadradas como dados (não como instruções), os rótulos de quem fala derivam da assinatura verificada criptograficamente (nunca do texto do corpo), e ações relevantes e irreversíveis ficam retidas para revisão de quem é dono em vez de serem executadas sozinhas. Tudo isso reduz o risco de injeção de instruções; é defesa em profundidade, não uma garantia.