@ 06639a38:655f8f71

• Worked on the https://nostr-php.dev docs
  • Introduction
  • Request events
  • Publish event
• Discussed a FOSDEM stand application with Jurjen and Tanja to attend that conference with Nostr
• Release version 1.4.2 of Nostr-PHP
  • https://github.com/nostrver-se/nostr-php/releases/tag/1.4.2
• Pre-release 2.0.0-alpha1
  • https://github.com/nostrver-se/nostr-php/releases/tag/2.0.0-alpha1

@ 06639a38:655f8f71

Week 40

• Added a page with my research findings around async concurrent websocket requests: https://nostr-php.dev/references/async-concurrent-requests

Week 41

I attended the Nostrdam meetup and helped as a volunteer at the Nostr booth at the Bitcoin Amsterdam 2024 conference. Here are some photo's:

I also wrote down my personal learned lessons from this expierence: https://nostrver.se/note/my-learned-nostr-lessons-nostr-booth-bitcoin-amsterdam-2024

@ aedd8f68:296cf1be

Note: This is not some fancy writing piece. this is just brain farting that I thought it was too long for a regular post.

Alex Gleason is always doing a lot of crazy interesting work. Ditto is a step in the right direction for an alternate type of relay ecosystem that runs alongside the standard globally focused community we all know.

While #Ditto is awesome, what I'd really like to see something similar, but more focused on a multi-community experience that simultaneously makes each community's viewing experience focused only on that community's content. Just for fun, to write down some ideas, below are the 2 big changes that I think would make ditto the ultimate "communities" system that could trounce Reddit.

1. Single relay experience on the domain:

By default, I think community sites should only show content from the built in relay (or a relay group for redundancy). Currently on ditto.pub, when you first sign in, it feels a lot like any other web nostr client. The default home just shows follows I have from other relays instead of being thrown into the community content. You have to click the local feed, to filter the community's content, but it's limited to people who registered a NIP-05 for that domain. I think that it would be great if you could contribute with any NIP-05 and it counts as community content. That could be accomplished by equate community content to content posted on the relay. There are countless apps to get a feed of your relays, so it doesn't benefit me to see it on a communty's domain.

2. Sister client giving multi-community aggregation experience:

I think communities should like pokemon and you grab the ones to identify with. Create a set of web and mobile app clients that manage viewing and switching single relays at a time. The client experience would be like reddit where you navigate ditto communities like subreddits. If a community is a pokemon, then this is the pokedex? OK I actually don't know shit about pokemon so that might not be the slam dunk I thought it was. Whoops.

Ideas / more particulars

• To see a community's content, you add a community relay subscribing to subreddit, or simply visit the domain.
• Another great feature would be customizing the relays that make up your home feed, and making other named combo-feeds (especially awesome if you are a part of 2 rival communities who's focus generally overlap)
• The client would use more globally used relays to handle settings like your list followed ditto communities, etc (configurable)
• Similarly, to help users find communities, ditto servers can optionally publish their relay info to a list on a "discovery" relay. Main popular discovery relays would be set by default (where communities publish discovery info to), but could be configured to other relays (if people wanted to set up custom curation relays or something.)
• Registering a domain handle (NIP-05) at the community domain can be more focused on people with relay moderation roles, or just people who really for some reason want that community to be their whole identity (i don't personally get that, which is why mastodon is not for me)
• Communities could work independently of the aggregator app(s) If people just wanted to visit the domain to post (from any NIP-05)

@ 599f67f7:21fb3ea9

Nostr proxy baten erabilera modu oso eraginkorra da internet banda-zabaleraren eta mugikorretan bateriaren kontsumoa optimizatzeko.

Proxy batek hainbat errelei-konexio konexio bakarrean biltzen dituenez, baliabideen erabilera nabarmen murrizten du, eta erabiltzailearen IP helbidea ezkutatuz pribatutasun-geruza bat gehitzen du.

Hona hemen nola funtzionatzen duen eta nola konfigura daitekeen:

Nola funtzionatzen du?

Nostr proxy batek hainbat erreleirekin konektatzen du. Errele horietara gertaerak eskuratu eta argitaratzen ditu. Bezeroaren aplikazioak WebSocket konexio bakarra ireki behar du proxy-ra, eta horren bidez proxy-ak konektatuta dituen errele guztiak eskuragarri izango ditu.

Irudiaren egiletza: Yonle 2023

Bezeroak konexio bakarra irekitzen duenez, datuak eta bateria aurrezten ditu.

Proxy-ak bezeroaren izenean erreleekin konektatzen denez, erreleek proxy-aren IP helbidea ikusten dute, eta ez bezeroarena. (Hala ere, proxy hornitzailearengan konfiantza izan behar duzu).

Erabiltzeko Modua

Nostr proxy bat erraz auto-ostata daiteke. Auto-ostatatzeko jarraibideak lortzeko, begiratu nostr:npub1x3azxuysp5vmfer4vgs4jn5tmfcx4ew8sh0qnev7gczljxsr7jwqa3g4el erabiltzailearen biltegi hau.

Auto-ostatzeko baliabiderik ez dutenentzat, Bitcoin Txoko-k komunitate-instantzia bat ostalaratzen du.

Erabiltzeko, gehitu besterik ez duzu:

wss://bostr.bitcointxoko.com

zure errele zerrendara.

Orain ez duzunez zuzeneko konexioak behar, errele bikoiztuak ezabatu ditzakezu.

Ikusiko dugu elkar Nostr-en!

@ 8cb60e21:5f2deaea

@ 4ba8e86d:89d32de4

O que é Cwtch? Cwtch (/kʊtʃ/ - uma palavra galesa que pode ser traduzida aproximadamente como “um abraço que cria um lugar seguro”) é um protocolo de mensagens multipartidário descentralizado, que preserva a privacidade, que pode ser usado para construir aplicativos resistentes a metadados.

Como posso pronunciar Cwtch? Como "kutch", para rimar com "butch".

Descentralizado e Aberto : Não existe “serviço Cwtch” ou “rede Cwtch”. Os participantes do Cwtch podem hospedar seus próprios espaços seguros ou emprestar sua infraestrutura para outras pessoas que buscam um espaço seguro. O protocolo Cwtch é aberto e qualquer pessoa é livre para criar bots, serviços e interfaces de usuário e integrar e interagir com o Cwtch.

Preservação de privacidade : toda a comunicação no Cwtch é criptografada de ponta a ponta e ocorre nos serviços cebola Tor v3.

Resistente a metadados : O Cwtch foi projetado de forma que nenhuma informação seja trocada ou disponibilizada a ninguém sem seu consentimento explícito, incluindo mensagens durante a transmissão e metadados de protocolo

Uma breve história do bate-papo resistente a metadados Nos últimos anos, a conscientização pública sobre a necessidade e os benefícios das soluções criptografadas de ponta a ponta aumentou com aplicativos como Signal , Whatsapp e Wire. que agora fornecem aos usuários comunicações seguras.

No entanto, essas ferramentas exigem vários níveis de exposição de metadados para funcionar, e muitos desses metadados podem ser usados ​​para obter detalhes sobre como e por que uma pessoa está usando uma ferramenta para se comunicar.

Uma ferramenta que buscou reduzir metadados é o Ricochet lançado pela primeira vez em 2014. Ricochet usou os serviços cebola Tor v2 para fornecer comunicação criptografada segura de ponta a ponta e para proteger os metadados das comunicações.

Não havia servidores centralizados que auxiliassem no roteamento das conversas do Ricochet. Ninguém além das partes envolvidas em uma conversa poderia saber que tal conversa está ocorrendo.

Ricochet tinha limitações; não havia suporte para vários dispositivos, nem existe um mecanismo para suportar a comunicação em grupo ou para um usuário enviar mensagens enquanto um contato está offline.

Isto tornou a adoção do Ricochet uma proposta difícil; mesmo aqueles em ambientes que seriam melhor atendidos pela resistência aos metadados, sem saber que ela existe.

Além disso, qualquer solução para comunicação descentralizada e resistente a metadados enfrenta problemas fundamentais quando se trata de eficiência, privacidade e segurança de grupo conforme definido pelo consenso e consistência da transcrição.

Alternativas modernas ao Ricochet incluem Briar , Zbay e Ricochet Refresh - cada ferramenta procura otimizar para um conjunto diferente de compensações, por exemplo, Briar procura permitir que as pessoas se comuniquem mesmo quando a infraestrutura de rede subjacente está inoperante, ao mesmo tempo que fornece resistência à vigilância de metadados.

O projeto Cwtch começou em 2017 como um protocolo de extensão para Ricochet, fornecendo conversas em grupo por meio de servidores não confiáveis, com o objetivo de permitir aplicativos descentralizados e resistentes a metadados como listas compartilhadas e quadros de avisos.

Uma versão alfa do Cwtch foi lançada em fevereiro de 2019 e, desde então, a equipe do Cwtch dirigida pela OPEN PRIVACY RESEARCH SOCIETY conduziu pesquisa e desenvolvimento em cwtch e nos protocolos, bibliotecas e espaços de problemas subjacentes.

Modelo de Risco.

Sabe-se que os metadados de comunicações são explorados por vários adversários para minar a segurança dos sistemas, para rastrear vítimas e para realizar análises de redes sociais em grande escala para alimentar a vigilância em massa. As ferramentas resistentes a metadados estão em sua infância e faltam pesquisas sobre a construção e a experiência do usuário de tais ferramentas.

https://nostrcheck.me/media/public/nostrcheck.me_9475702740746681051707662826.webp

O Cwtch foi originalmente concebido como uma extensão do protocolo Ricochet resistente a metadados para suportar comunicações assíncronas de grupos multiponto por meio do uso de infraestrutura anônima, descartável e não confiável.

Desde então, o Cwtch evoluiu para um protocolo próprio. Esta seção descreverá os vários riscos conhecidos que o Cwtch tenta mitigar e será fortemente referenciado no restante do documento ao discutir os vários subcomponentes da Arquitetura Cwtch.

Modelo de ameaça.

É importante identificar e compreender que os metadados são omnipresentes nos protocolos de comunicação; é de facto necessário que tais protocolos funcionem de forma eficiente e em escala. No entanto, as informações que são úteis para facilitar peers e servidores também são altamente relevantes para adversários que desejam explorar tais informações.

Para a definição do nosso problema, assumiremos que o conteúdo de uma comunicação é criptografado de tal forma que um adversário é praticamente incapaz de quebrá-lo veja tapir e cwtch para detalhes sobre a criptografia que usamos, e como tal nos concentraremos em o contexto para os metadados de comunicação.

Procuramos proteger os seguintes contextos de comunicação:

• Quem está envolvido em uma comunicação? Pode ser possível identificar pessoas ou simplesmente identificadores de dispositivos ou redes. Por exemplo, “esta comunicação envolve Alice, uma jornalista, e Bob, um funcionário público”.

• Onde estão os participantes da conversa? Por exemplo, “durante esta comunicação, Alice estava na França e Bob estava no Canadá”.

• Quando ocorreu uma conversa? O momento e a duração da comunicação podem revelar muito sobre a natureza de uma chamada, por exemplo, “Bob, um funcionário público, conversou com Alice ao telefone por uma hora ontem à noite. Esta é a primeira vez que eles se comunicam.” *Como a conversa foi mediada? O fato de uma conversa ter ocorrido por meio de um e-mail criptografado ou não criptografado pode fornecer informações úteis. Por exemplo, “Alice enviou um e-mail criptografado para Bob ontem, enquanto eles normalmente enviam apenas e-mails de texto simples um para o outro”.

• Sobre o que é a conversa? Mesmo que o conteúdo da comunicação seja criptografado, às vezes é possível derivar um contexto provável de uma conversa sem saber exatamente o que é dito, por exemplo, “uma pessoa ligou para uma pizzaria na hora do jantar” ou “alguém ligou para um número conhecido de linha direta de suicídio na hora do jantar”. 3 horas da manhã."

Além das conversas individuais, também procuramos defender-nos contra ataques de correlação de contexto, através dos quais múltiplas conversas são analisadas para obter informações de nível superior:

• Relacionamentos: Descobrir relações sociais entre um par de entidades analisando a frequência e a duração de suas comunicações durante um período de tempo. Por exemplo, Carol e Eve ligam uma para a outra todos os dias durante várias horas seguidas.

• Cliques: Descobrir relações sociais entre um grupo de entidades que interagem entre si. Por exemplo, Alice, Bob e Eva se comunicam entre si.

• Grupos vagamente conectados e indivíduos-ponte: descobrir grupos que se comunicam entre si através de intermediários, analisando cadeias de comunicação (por exemplo, toda vez que Alice fala com Bob, ela fala com Carol quase imediatamente depois; Bob e Carol nunca se comunicam).

• Padrão de Vida: Descobrir quais comunicações são cíclicas e previsíveis. Por exemplo, Alice liga para Eve toda segunda-feira à noite por cerca de uma hora. Ataques Ativos

Ataques de deturpação.

O Cwtch não fornece registro global de nomes de exibição e, como tal, as pessoas que usam o Cwtch são mais vulneráveis ​​a ataques baseados em declarações falsas, ou seja, pessoas que fingem ser outras pessoas:

O fluxo básico de um desses ataques é o seguinte, embora também existam outros fluxos:

•Alice tem um amigo chamado Bob e outro chamado Eve

• Eve descobre que Alice tem um amigo chamado Bob

• Eve cria milhares de novas contas para encontrar uma que tenha uma imagem/chave pública semelhante à de Bob (não será idêntica, mas pode enganar alguém por alguns minutos)

• Eve chama essa nova conta de "Eve New Account" e adiciona Alice como amiga.

• Eve então muda seu nome em "Eve New Account" para "Bob"

• Alice envia mensagens destinadas a "Bob" para a conta falsa de Bob de Eve Como os ataques de declarações falsas são inerentemente uma questão de confiança e verificação, a única maneira absoluta de evitá-los é os usuários validarem absolutamente a chave pública. Obviamente, isso não é o ideal e, em muitos casos, simplesmente não acontecerá .

Como tal, pretendemos fornecer algumas dicas de experiência do usuário na interface do usuário para orientar as pessoas na tomada de decisões sobre confiar em contas e/ou distinguir contas que possam estar tentando se representar como outros usuários.

Uma nota sobre ataques físicos A Cwtch não considera ataques que exijam acesso físico (ou equivalente) à máquina do usuário como praticamente defensáveis. No entanto, no interesse de uma boa engenharia de segurança, ao longo deste documento ainda nos referiremos a ataques ou condições que exigem tal privilégio e indicaremos onde quaisquer mitigações que implementámos falharão.

Um perfil Cwtch.

Os usuários podem criar um ou mais perfis Cwtch. Cada perfil gera um par de chaves ed25519 aleatório compatível com Tor.

Além do material criptográfico, um perfil também contém uma lista de Contatos (outras chaves públicas do perfil Cwtch + dados associados sobre esse perfil, como apelido e (opcionalmente) mensagens históricas), uma lista de Grupos (contendo o material criptográfico do grupo, além de outros dados associados, como apelido do grupo e mensagens históricas).

Conversões entre duas partes: ponto a ponto

https://nostrcheck.me/media/public/nostrcheck.me_2186338207587396891707662879.webp

Para que duas partes participem de uma conversa ponto a ponto, ambas devem estar on-line, mas apenas uma precisa estar acessível por meio do serviço Onion. Por uma questão de clareza, muitas vezes rotulamos uma parte como “ponto de entrada” (aquele que hospeda o serviço cebola) e a outra parte como “ponto de saída” (aquele que se conecta ao serviço cebola).

Após a conexão, ambas as partes adotam um protocolo de autenticação que:

• Afirma que cada parte tem acesso à chave privada associada à sua identidade pública.

• Gera uma chave de sessão efêmera usada para criptografar todas as comunicações futuras durante a sessão.

Esta troca (documentada com mais detalhes no protocolo de autenticação ) é negável offline , ou seja, é possível para qualquer parte falsificar transcrições desta troca de protocolo após o fato e, como tal - após o fato - é impossível provar definitivamente que a troca aconteceu de forma alguma.

Após o protocolo de autenticação, as duas partes podem trocar mensagens livremente.

Conversas em Grupo e Comunicação Ponto a Servidor

Ao iniciar uma conversa em grupo, é gerada uma chave aleatória para o grupo, conhecida como Group Key. Todas as comunicações do grupo são criptografadas usando esta chave. Além disso, o criador do grupo escolhe um servidor Cwtch para hospedar o grupo. Um convite é gerado, incluindo o Group Key, o servidor do grupo e a chave do grupo, para ser enviado aos potenciais membros.

Para enviar uma mensagem ao grupo, um perfil se conecta ao servidor do grupo e criptografa a mensagem usando a Group Key, gerando também uma assinatura sobre o Group ID, o servidor do grupo e a mensagem. Para receber mensagens do grupo, um perfil se conecta ao servidor e baixa as mensagens, tentando descriptografá-las usando a Group Key e verificando a assinatura.

Detalhamento do Ecossistema de Componentes

O Cwtch é composto por várias bibliotecas de componentes menores, cada uma desempenhando um papel específico. Algumas dessas bibliotecas incluem:

• abertoprivacidade/conectividade: Abstração de rede ACN, atualmente suportando apenas Tor.
• cwtch.im/tapir: Biblioteca para construção de aplicativos p2p em sistemas de comunicação anônimos.
• cwtch.im/cwtch: Biblioteca principal para implementação do protocolo/sistema Cwtch.
• cwtch.im/libcwtch-go: Fornece ligações C para Cwtch para uso em implementações de UI.

TAPIR: Uma Visão Detalhada

Projetado para substituir os antigos canais de ricochete baseados em protobuf, o Tapir fornece uma estrutura para a construção de aplicativos anônimos.

Está dividido em várias camadas:

• Identidade - Um par de chaves ed25519, necessário para estabelecer um serviço cebola Tor v3 e usado para manter uma identidade criptográfica consistente para um par.

• Conexões – O protocolo de rede bruto que conecta dois pares. Até agora, as conexões são definidas apenas através do Tor v3 Onion Services.

• Aplicativos - As diversas lógicas que permitem um determinado fluxo de informações em uma conexão. Os exemplos incluem transcrições criptográficas compartilhadas, autenticação, proteção contra spam e serviços baseados em tokens. Os aplicativos fornecem recursos que podem ser referenciados por outros aplicativos para determinar se um determinado peer tem a capacidade de usar um determinado aplicativo hospedado.

• Pilhas de aplicativos - Um mecanismo para conectar mais de um aplicativo, por exemplo, a autenticação depende de uma transcrição criptográfica compartilhada e o aplicativo peer cwtch principal é baseado no aplicativo de autenticação.

Identidade.

Um par de chaves ed25519, necessário para estabelecer um serviço cebola Tor v3 e usado para manter uma identidade criptográfica consistente para um peer.

InitializeIdentity - de um par de chaves conhecido e persistente:i,I

InitializeEphemeralIdentity - de um par de chaves aleatório: ie,Ie

Aplicativos de transcrição.

Inicializa uma transcrição criptográfica baseada em Merlin que pode ser usada como base de protocolos baseados em compromisso de nível superior

O aplicativo de transcrição entrará em pânico se um aplicativo tentar substituir uma transcrição existente por uma nova (aplicando a regra de que uma sessão é baseada em uma e apenas uma transcrição).

Merlin é uma construção de transcrição baseada em STROBE para provas de conhecimento zero. Ele automatiza a transformação Fiat-Shamir, para que, usando Merlin, protocolos não interativos possam ser implementados como se fossem interativos.

Isto é significativamente mais fácil e menos sujeito a erros do que realizar a transformação manualmente e, além disso, também fornece suporte natural para:

• protocolos multi-round com fases alternadas de commit e desafio;

• separação natural de domínios, garantindo que os desafios estejam vinculados às afirmações a serem provadas;

• enquadramento automático de mensagens, evitando codificação ambígua de dados de compromisso;

• e composição do protocolo, usando uma transcrição comum para vários protocolos.

Finalmente, o Merlin também fornece um gerador de números aleatórios baseado em transcrição como defesa profunda contra ataques de entropia ruim (como reutilização de nonce ou preconceito em muitas provas). Este RNG fornece aleatoriedade sintética derivada de toda a transcrição pública, bem como dos dados da testemunha do provador e uma entrada auxiliar de um RNG externo.

Conectividade Cwtch faz uso do Tor Onion Services (v3) para todas as comunicações entre nós.

Fornecemos o pacote openprivacy/connectivity para gerenciar o daemon Tor e configurar e desmontar serviços cebola através do Tor.

Criptografia e armazenamento de perfil.

Os perfis são armazenados localmente no disco e criptografados usando uma chave derivada de uma senha conhecida pelo usuário (via pbkdf2).

Observe que, uma vez criptografado e armazenado em disco, a única maneira de recuperar um perfil é recuperando a senha - como tal, não é possível fornecer uma lista completa de perfis aos quais um usuário pode ter acesso até inserir uma senha.

Perfis não criptografados e a senha padrão Para lidar com perfis "não criptografados" (ou seja, que não exigem senha para serem abertos), atualmente criamos um perfil com uma senha codificada de fato .

Isso não é o ideal, preferiríamos confiar no material de chave fornecido pelo sistema operacional, de modo que o perfil fosse vinculado a um dispositivo específico, mas esses recursos são atualmente uma colcha de retalhos - também notamos, ao criar um perfil não criptografado, pessoas que usam Cwtch estão explicitamente optando pelo risco de que alguém com acesso ao sistema de arquivos possa descriptografar seu perfil.

Vulnerabilidades Relacionadas a Imagens e Entrada de Dados

Imagens Maliciosas

O Cwtch enfrenta desafios na renderização de imagens, com o Flutter utilizando Skia, embora o código subjacente não seja totalmente seguro para a memória.

Realizamos testes de fuzzing nos componentes Cwtch e encontramos um bug de travamento causado por um arquivo GIF malformado, levando a falhas no kernel. Para mitigar isso, adotamos a política de sempre habilitar cacheWidth e/ou cacheHeight máximo para widgets de imagem.

Identificamos o risco de imagens maliciosas serem renderizadas de forma diferente em diferentes plataformas, como evidenciado por um bug no analisador PNG da Apple.

Riscos de Entrada de Dados

Um risco significativo é a interceptação de conteúdo ou metadados por meio de um Input Method Editor (IME) em dispositivos móveis. Mesmo aplicativos IME padrão podem expor dados por meio de sincronização na nuvem, tradução online ou dicionários pessoais.

Implementamos medidas de mitigação, como enableIMEPersonalizedLearning: false no Cwtch 1.2, mas a solução completa requer ações em nível de sistema operacional e é um desafio contínuo para a segurança móvel.

Servidor Cwtch.

O objetivo do protocolo Cwtch é permitir a comunicação em grupo através de infraestrutura não confiável .

Ao contrário dos esquemas baseados em retransmissão, onde os grupos atribuem um líder, um conjunto de líderes ou um servidor confiável de terceiros para garantir que cada membro do grupo possa enviar e receber mensagens em tempo hábil (mesmo que os membros estejam offline) - infraestrutura não confiável tem o objetivo de realizar essas propriedades sem a suposição de confiança.

O artigo original do Cwtch definia um conjunto de propriedades que se esperava que os servidores Cwtch fornecessem:

• O Cwtch Server pode ser usado por vários grupos ou apenas um.

• Um servidor Cwtch, sem a colaboração de um membro do grupo, nunca deve aprender a identidade dos participantes de um grupo.

• Um servidor Cwtch nunca deve aprender o conteúdo de qualquer comunicação.

• Um servidor Cwtch nunca deve ser capaz de distinguir mensagens como pertencentes a um grupo específico. Observamos aqui que essas propriedades são um superconjunto dos objetivos de design das estruturas de Recuperação de Informações Privadas.

Melhorias na Eficiência e Segurança

Eficiência do Protocolo

Atualmente, apenas um protocolo conhecido, o PIR ingênuo, atende às propriedades desejadas para garantir a privacidade na comunicação do grupo Cwtch. Este método tem um impacto direto na eficiência da largura de banda, especialmente para usuários em dispositivos móveis. Em resposta a isso, estamos ativamente desenvolvendo novos protocolos que permitem negociar garantias de privacidade e eficiência de maneiras diversas.

Os servidores, no momento desta escrita, permitem o download completo de todas as mensagens armazenadas, bem como uma solicitação para baixar mensagens específicas a partir de uma determinada mensagem. Quando os pares ingressam em um grupo em um novo servidor, eles baixam todas as mensagens do servidor inicialmente e, posteriormente, apenas as mensagens novas.

Mitigação de Análise de Metadados

Essa abordagem permite uma análise moderada de metadados, pois o servidor pode enviar novas mensagens para cada perfil suspeito exclusivo e usar essas assinaturas de mensagens exclusivas para rastrear sessões ao longo do tempo. Essa preocupação é mitigada por dois fatores:

1. Os perfis podem atualizar suas conexões a qualquer momento, resultando em uma nova sessão do servidor.
2. Os perfis podem ser "ressincronizados" de um servidor a qualquer momento, resultando em uma nova chamada para baixar todas as mensagens. Isso é comumente usado para buscar mensagens antigas de um grupo.

Embora essas medidas imponham limites ao que o servidor pode inferir, ainda não podemos garantir resistência total aos metadados. Para soluções futuras para esse problema, consulte Niwl.

Proteção contra Pares Maliciosos

Os servidores enfrentam o risco de spam gerado por pares, representando uma ameaça significativa à eficácia do sistema Cwtch. Embora tenhamos implementado um mecanismo de proteção contra spam no protótipo do Cwtch, exigindo que os pares realizem alguma prova de trabalho especificada pelo servidor, reconhecemos que essa não é uma solução robusta na presença de um adversário determinado com recursos significativos.

Pacotes de Chaves

Os servidores Cwtch se identificam por meio de pacotes de chaves assinados, contendo uma lista de chaves necessárias para garantir a segurança e resistência aos metadados na comunicação do grupo Cwtch. Esses pacotes de chaves geralmente incluem três chaves: uma chave pública do serviço Tor v3 Onion para o Token Board, uma chave pública do Tor v3 Onion Service para o Token Service e uma chave pública do Privacy Pass.

Para verificar os pacotes de chaves, os perfis que os importam do servidor utilizam o algoritmo trust-on-first-use (TOFU), verificando a assinatura anexada e a existência de todos os tipos de chave. Se o perfil já tiver importado o pacote de chaves do servidor anteriormente, todas as chaves são consideradas iguais.

Configuração prévia do aplicativo para ativar o Relé do Cwtch.

No Android, a hospedagem de servidor não está habilitada, pois essa opção não está disponível devido às limitações dos dispositivos Android. Essa funcionalidade está reservada apenas para servidores hospedados em desktops.

No Android, a única forma direta de importar uma chave de servidor é através do grupo de teste Cwtch, garantindo assim acesso ao servidor Cwtch.

Primeiro passo é Habilitar a opção de grupo no Cwtch que está em fase de testes. Clique na opção no canto superior direito da tela de configuração e pressione o botão para acessar as configurações do Cwtch.

Você pode alterar o idioma para Português do Brasil.Depois, role para baixo e selecione a opção para ativar os experimentos. Em seguida, ative a opção para habilitar o chat em grupo e a pré-visualização de imagens e fotos de perfil, permitindo que você troque sua foto de perfil.

https://link.storjshare.io/raw/jvss6zxle26jdguwaegtjdixhfka/production/f0ca039733d48895001261ab25c5d2efbaf3bf26e55aad3cce406646f9af9d15.MP4

Próximo passo é Criar um perfil.

Pressione o + botão de ação no canto inferior direito e selecione "Novo perfil" ou aberta no botão + adicionar novo perfil.

• Selecione um nome de exibição

• Selecione se deseja proteger

este perfil e salvo localmente com criptografia forte: Senha: sua conta está protegida de outras pessoas que possam usar este dispositivo

Sem senha: qualquer pessoa que tenha acesso a este dispositivo poderá acessar este perfil.

Preencha sua senha e digite-a novamente

Os perfis são armazenados localmente no disco e criptografados usando uma chave derivada de uma senha conhecida pelo usuário (via pbkdf2).

Observe que, uma vez criptografado e armazenado em disco, a única maneira de recuperar um perfil é recuperando a chave da senha - como tal, não é possível fornecer uma lista completa de perfis aos quais um usuário pode ter acesso até inserir um senha.

https://link.storjshare.io/raw/jxqbqmur2lcqe2eym5thgz4so2ya/production/8f9df1372ec7e659180609afa48be22b12109ae5e1eda9ef1dc05c1325652507.MP4

O próximo passo é adicionar o FuzzBot, que é um bot de testes e de desenvolvimento.

Contato do FuzzBot: 4y2hxlxqzautabituedksnh2ulcgm2coqbure6wvfpg4gi2ci25ta5ad.

Ao enviar o comando "testgroup-invite" para o FuzzBot, você receberá um convite para entrar no Grupo Cwtch Test. Ao ingressar no grupo, você será automaticamente conectado ao servidor Cwtch. Você pode optar por sair do grupo a qualquer momento ou ficar para conversar e tirar dúvidas sobre o aplicativo e outros assuntos. Depois, você pode configurar seu próprio servidor Cwtch, o que é altamente recomendável.

https://link.storjshare.io/raw/jvji25zclkoqcouni5decle7if7a/production/ee3de3540a3e3dca6e6e26d303e12c2ef892a5d7769029275b8b95ffc7468780.MP4

Agora você pode utilizar o aplicativo normalmente. Algumas observações que notei: se houver demora na conexão com outra pessoa, ambas devem estar online. Se ainda assim a conexão não for estabelecida, basta clicar no ícone de reset do Tor para restabelecer a conexão com a outra pessoa.

Uma introdução aos perfis Cwtch.

Com Cwtch você pode criar um ou mais perfis . Cada perfil gera um par de chaves ed25519 aleatório compatível com a Rede Tor.

Este é o identificador que você pode fornecer às pessoas e que elas podem usar para entrar em contato com você via Cwtch.

Cwtch permite criar e gerenciar vários perfis separados. Cada perfil está associado a um par de chaves diferente que inicia um serviço cebola diferente.

Gerenciar Na inicialização, o Cwtch abrirá a tela Gerenciar Perfis. Nessa tela você pode:

• Crie um novo perfil.
• Desbloquear perfis.
• Criptografados existentes.
• Gerenciar perfis carregados.
• Alterando o nome de exibição de um perfil.
• Alterando a senha de um perfil Excluindo um perfil.
• Alterando uma imagem de perfil.

Backup ou exportação de um perfil.

Na tela de gerenciamento de perfil:

1. Selecione o lápis ao lado do perfil que você deseja editar

2. Role para baixo até a parte inferior da tela.

3. Selecione "Exportar perfil"

4. Escolha um local e um nome de arquivo.

5.confirme.

Uma vez confirmado, o Cwtch colocará uma cópia do perfil no local indicado. Este arquivo é criptografado no mesmo nível do perfil.

Este arquivo pode ser importado para outra instância do Cwtch em qualquer dispositivo.

Importando um perfil.

1. Pressione o +botão de ação no canto inferior direito e selecione "Importar perfil"

2. Selecione um arquivo de perfil Cwtch exportado para importar

3. Digite a senha associada ao perfil e confirme.

Uma vez confirmado, o Cwtch tentará descriptografar o arquivo fornecido usando uma chave derivada da senha fornecida. Se for bem-sucedido, o perfil aparecerá na tela Gerenciamento de perfil e estará pronto para uso.

OBSERVAÇÃO Embora um perfil possa ser importado para vários dispositivos, atualmente apenas uma versão de um perfil pode ser usada em todos os dispositivos ao mesmo tempo. As tentativas de usar o mesmo perfil em vários dispositivos podem resultar em problemas de disponibilidade e falhas de mensagens.

Qual é a diferença entre uma conexão ponto a ponto e um grupo cwtch?

As conexões ponto a ponto Cwtch permitem que 2 pessoas troquem mensagens diretamente. As conexões ponto a ponto nos bastidores usam serviços cebola Tor v3 para fornecer uma conexão criptografada e resistente a metadados. Devido a esta conexão direta, ambas as partes precisam estar online ao mesmo tempo para trocar mensagens.

Os Grupos Cwtch permitem que várias partes participem de uma única conversa usando um servidor não confiável (que pode ser fornecido por terceiros ou auto-hospedado). Os operadores de servidores não conseguem saber quantas pessoas estão em um grupo ou o que está sendo discutido. Se vários grupos estiverem hospedados em um único servidor, o servidor não conseguirá saber quais mensagens pertencem a qual grupo sem a conivência de um membro do grupo. Ao contrário das conversas entre pares, as conversas em grupo podem ser conduzidas de forma assíncrona, para que todos num grupo não precisem estar online ao mesmo tempo.

Por que os grupos cwtch são experimentais? Mensagens em grupo resistentes a metadados ainda são um problema em aberto . Embora a versão que fornecemos no Cwtch Beta seja projetada para ser segura e com metadados privados, ela é bastante ineficiente e pode ser mal utilizada. Como tal, aconselhamos cautela ao usá-lo e apenas o fornecemos como um recurso opcional.

Como posso executar meu próprio servidor Cwtch? A implementação de referência para um servidor Cwtch é de código aberto . Qualquer pessoa pode executar um servidor Cwtch, e qualquer pessoa com uma cópia do pacote de chaves públicas do servidor pode hospedar grupos nesse servidor sem que o operador tenha acesso aos metadados relacionados ao grupo .

https://git.openprivacy.ca/cwtch.im/server

https://docs.openprivacy.ca/cwtch-security-handbook/server.html

Como posso desligar o Cwtch? O painel frontal do aplicativo possui um ícone do botão "Shutdown Cwtch" (com um 'X'). Pressionar este botão irá acionar uma caixa de diálogo e, na confirmação, o Cwtch será desligado e todos os perfis serão descarregados.

Suas doações podem fazer a diferença no projeto Cwtch? O Cwtch é um projeto dedicado a construir aplicativos que preservam a privacidade, oferecendo comunicação de grupo resistente a metadados. Além disso, o projeto também desenvolve o Cofre, formulários da web criptografados para ajudar mútua segura. Suas contribuições apoiam iniciativas importantes, como a divulgação de violações de dados médicos em Vancouver e pesquisas sobre a segurança do voto eletrônico na Suíça. Ao doar, você está ajudando a fechar o ciclo, trabalhando com comunidades marginalizadas para identificar e corrigir lacunas de privacidade. Além disso, o projeto trabalha em soluções inovadoras, como a quebra de segredos através da criptografia de limite para proteger sua privacidade durante passagens de fronteira. E também tem a infraestrutura: toda nossa infraestrutura é open source e sem fins lucrativos. Conheça também o Fuzzytags, uma estrutura criptográfica probabilística para marcação resistente a metadados. Sua doação é crucial para continuar o trabalho em prol da privacidade e segurança online. Contribua agora com sua doação

https://openprivacy.ca/donate/

onde você pode fazer sua doação em bitcoin e outras moedas, e saiba mais sobre os projetos. https://openprivacy.ca/work/

Link sobre Cwtch

https://cwtch.im/

https://git.openprivacy.ca/cwtch.im/cwtch

https://docs.cwtch.im/docs/intro

https://docs.openprivacy.ca/cwtch-security-handbook/

Baixar #CwtchDev

cwtch.im/download/

https://play.google.com/store/apps/details?id=im.cwtch.flwtch

@ 8cb60e21:5f2deaea

@ 12cfc2ec:6967f1d9

this is in response to Shinobis recent piece occupy bitcoin found here

https://bitcoinmagazine.com/culture/occupy-bitcoin-bitcoin-is-not-just-libertarian?new

Occupy bitcoin is a thing every single one of us tries to do. There isn't a single one individual that doesn’t see bitcoin for what it is and have it not occupy all of them to varying degrees. There’s an innate fascination with coming upon previously unknown knowledge and become overtly obsessed with it and exploring all of the facets in which the new knowledge can be applied. When one does so, it normally can lead to finding previously unknown areas that you come to find with the more that you learn you find out just how much you truly don’t understand.

Now with this being the foundation of what all of humans are doing. None of us, not ONE, know everything. Its a fallacious argument to claim to do. In the journey for the discovery that is truth one can happen to fall upon the political rabbit hole that can be called or dubbed Libertarianism/Anarchism/ AnCap/AnCom etc. I use these labels very lightly as they are just words at the end of the day words mean different things to different people. I cant know what these words mean to you dear reader but I can only know what they mean to me, and my journey specifically. What we as humans do is to come to an agreement upon to what does these words mean to the both of us when we are communicating them to each other. I do my best to not fall into being pigeon holed into believing or having to defend that when I say one of the aforementioned words that I should have to commit to whatever it is your preconceived understanding of what that is. We must remember that these words are collectivized terms, they are strictly USEFUL fictions that we humans use in order to better conceptualize the ideas to better understand. That to take any attribute pulled from any one of the above and blanket paint “some” or “most” individuals that claim to align with above ideologies/alignments/political beliefs that these individuals represent that is an absurd claim. One cannot claim that individuals acting in mean/harsh ways when facing others who don’t agree with them is the wrong way to act.

We are humans we disagree, were free to act as we please to anyone we wish to do so. We’re NEVER free to ignore the consequences of those actions. One could characterize the vehement disdain for the acceptance all ideas, and letting others have their own opinions, is how we as individuals got here in the first place. It was the ideas of society being more important than the whole that had legitimized the aggression sanctified by the state as an omnipotent entity free from doing no wrong in lieu of the greater good. Individuals can do as such with their minds as they please but your actions of freedom stop at the point of my nose begins. The individuals that understand freedom and its core philosophy understand this. Treating one side as an evil and the other side as some glorified good is a cop out of intellectual dishonesty.

In the realm of bitcoin there can be disagreements and even out right hostility towards any number of ideas/opinions. This is the nature of freedom itself. As I’ve seen it and as I have championed it myself do with freedom what you will, but whatever you do if I think its stupid I’m going to tell you its stupid. Social pressures have been with human civilizations for thousands of years to think that the idea of attacks to your ideas not being a thing because we should accept all ideas and be kind to differing opinions is a farce at best and some unicorn fart huffing at worst. It was the individuals that were unwavering IN SPITE of the social attacks, the public slandering, the outright social ostracization, the being called dumb and stupid that paved the way for the best and most historical moments in history Ideas don’t care about these passing affronts. If your viewpoint/idea needs soft corners to gain traction then maybe you should reassess your idea in the first place. The battleground that is the societal/accepted norm isn't one that’s for the faint of heart. Everyone has limited time and resources available to them if they are choosing not to hear you then its probably time to seek out others to speak to. In the realm of freedom everyone CAN choose any ideas they wish to follow and interact with others that agree, where that stops is you can NO LONGER force everyone else to participate in your own shared delusions with the others you associate with. The freedom to EXCLUDE is one of the core tenets of freedom principles. We DO NOT have to be accepting of everyone if we do not wish to do so, the belief that everyone should ALWAYS accept everyone and everything is a communistic one. No one individual has the time and resources to accept every person and accept or contemplate every single idea presented to him. What freedom DOES allow for is for YOU to find the individuals that ARE accepting of your views/beliefs and do with that what you wish.

By trying to call out one group of individuals as being too “tribal” in what they view as the best course of action for themselves while SIMULTANEOUSLY praising another group for their favored tenets of “acceptance” is a laughable and down right sad view that “everyone should be more like the accepting crowd”. It is only through the choices we make that we get to where we are going on this journey. Those choices are inherently going to REQUIRE dissociation, omission, & exclusion.

The ideologies/beliefs mentioned at the beginning of this article are only a starting point to the journey. They are in no way shape or from a claim to be a complete set of knowledge's that allow everyone to be able to navigate this earth. Are some things flawed? Probably. Do some things work for some and not others? Absolutely. But the major core belief at all of them is the belief that violence is never permitted, in all its facets to the individual liberty of the person. Its the only morally justifiable way to navigate life. This is in and of itself the most open and accepting philosophy of all life choices.

Individuals can do with their lives as they please, nobody is stopping you from doing that, but you because someone said some mean things to me about what I believe. Its about time some individuals get that we must remain steadfast in our mission. We don’t get there by being nice to everyone. We only get there by allowing everyone to do what they wish and not expecting others to bend to our will because you hurt my feelings.

The ultimate arbiter for what you should pick and choose is you the individual, don’t let others decide that for you. Don’t be a passenger in your own life, take that wheel and choose for yourself where you are headed. But if you're going to let someone who was mean to you stop you from using probably the greatest tool that a human has ever invented, then maybe there isn't hope for humanity after all. The one thing that I know for sure is that there is one thing that that can hinder you or augment you, that thing is choice. Embrace it.

@ 7e538978:a5987ab6

Chain Duel, a fast paced PvP game that takes inspiration from the classic snake game and supercharges it with Bitcoin’s Lightning Network. Imagine battling another player for dominance in a race to collect blocks, where the length of your chain isn’t just a visual cue. It represents real, staked satoshis. The player with the most Proof of Work wins, but it’s not just about gameplay; it’s about the seamless integration of the Lightning Network and real-time payments.

But how does Chain Duel manage these instant transactions with such efficiency? That’s where LNbits comes in. LNbits, an open-source wallet and payment infrastructure, handles all in-game payments making it easy for developers to focus on gameplay while LNbits takes care of everything from microtransactions to automated splits for developers and designers. In this article, we’ll dive deep into how Chain Duel leverages LNbits to streamline in-game payments and how other developers can take advantage of this powerful toolset to build the future of Lightning-powered gaming.

Let’s explore how LNbits transforms payment processing and why it’s quickly becoming a must-have for game developers working in the Bitcoin space.

Overview of Chain Duel

Chain Duel is a unique Lightning Network-inspired game that reimagines the classic snake game with a competitive twist, integrating real-time payments. Two players face off in real-time, racing to "catch" blocks and extend their chains. Each block added to the chain represents Proof of Work, and the player with the most Proof of Work wins the duel. The stakes are high, as the game represents satoshis (small units of Bitcoin) as points, with the winner taking home the prize.

The game is designed to be Lightning-native, meaning all payments within Chain Duel are processed through the Lightning Network. This ensures fast payments, reducing latency and making gameplay smooth. With additional features like practice mode, tournaments and highscores, Chain Duel creates an engaging and competitive environment for Bitcoin enthusiasts and gamers alike.

One of the standout aspects of Chain Duel is its deeper integration with the Lightning Network even at a design level. For example, actual Bitcoin blocks can appear on screen during matches, offering bonus points when mined in sync with the game. The game’s current version, still in beta, has already drawn attention within the Bitcoin community, gaining momentum at conferences and with a growing user base through its social networks. With its innovative combination of gaming, the Lightning Network, and competitive play, Chain Duel offers a glimpse into the future of Lightning-based gaming.

How LNbits is Used in Chain Duel

Seamless Integration with LNbits

At the core of Chain Duel’s efficient payment processing is LNbits, which handles in-game transactions smoothly and reliably. Chain Duel uses the LNbits LNURL-pay and LNURL-withdraw extensions to manage payments and rewards between players. Before each match, players send satoshis using LNURL-pay, which generates a static QR code or link for making the payment. LNURL-pay allows users to attach a note to the payment, which Chain Duel creatively uses as a way to insert the player name in-game. The simplicity of LNURL-pay ensures that users can quickly and easily initiate games, with fresh invoices being issued for every game. When players win, LNURL-withdraw enables them to seamlessly pull their earnings from the game, providing a quick payout system.

These extensions make it easy for players to send and receive Bitcoin with minimal latency, fully leveraging the power of the Lightning Network for fast and low-cost payments. The flexibility of LNbits’ tools means that game developers don’t need to worry about building custom payment systems from scratch—they can rely on LNbits to handle all financial transactions with precision.

Lightning Tournaments

Chain Duel tournaments leverage LNbits and its LNURL extensions to create a seamless and efficient experience for players. In Chain Duel tournaments, LNbits plays a crucial role in managing the overall economics. LNbits facilitates the generation of LNURL QR codes that participants can scan to register quickly or withdraw their winnings. LNbits allows Chain Duel to automatically handle multiple registrations through LNURL-pay, enabling players to participate in the tournament without additional steps. The Lightning Network's speed ensures that these payments occur in real-time, reducing wait times and allowing for a smoother flow in-game.

Splitting Payments

LNbits further simplifies revenue-sharing within Chain Duel. This feature allows the game to automatically split the satoshis sent by players into different shares for the game’s developer, designer, and host. Each time a payment is made to join a match, LNbits is used to automattically pay each of the contributors, according to pre-defined rules. This automated process ensures that everyone involved in the development and running of the game gets their fair share without manual intervention or complex bookkeeping.

Nostr Integration

Chain Duel also integrates with Nostr, a decentralized protocol for social interactions. Players can join games using "Zaps", small tips or micropayments sent over the Lightning Network within the Nostr ecosystem. Through NIP-57, which enables Nostr clients to request Zap invoices, players can use LNURL-pay enabled Zaps to register in P2P matches, further enhancing the Chain Duel experience. By using Zaps as a way to register in-game, Chain Duel automates the process of fetching players' identity, creating a more competitive and social experience. Zaps are public on the Nostr network, further expanding Chain Duel's games social reach and community engagement.

Game and Payment Synchronization

One of the key reasons Chain Duel developers chose LNbits is its powerful API that connects directly with the game’s logic. LNbits allows the game to synchronize payments with gameplay in real-time, providing a seamless experience where payments are an integrated part of the gaming mechanics.

With LNbits managing both the payment process and the Lightning Network’s complex infrastructure, Chain Duel developers are free to concentrate on enhancing the competitive and Lightning Network-related aspects of the game. This division of tasks is essential for streamlining development while still providing an innovative in-game payment experience that is deeply integrated with the Bitcoin network.

LNbits proves to be an indispensable tool for Chain Duel, enabling smooth in-game transactions, real-time revenue sharing, and seamless integration with Nostr. For developers looking to build Lightning-powered games, LNbits offers a powerful suite of tools that handle everything from micropayments to payment distribution—ensuring that the game's focus remains on fun and competition rather than complex payment systems.

LNBits facilitating Education and Adoption

This system contributes to educating users on the power of the Lightning Network. Since Chain Duel directly involve real satoshis and LNURL for registration and rewards, players actively experience how Lightning can facilitate fast, cheap, and permissionless payments. By incorporating LNbits into Chain Duel, the game serves as an educational tool that introduces users to the benefits of the Lightning Network. Players gain direct experience using Lightning wallets and LNURL, helping them understand how these tools work in real-world scenarios. The near-instant nature of these payments showcases the power of Lightning in a practical context, highlighting its potential beyond just gaming. Players are encouraged to set up wallets, explore the Lightning ecosystem, and eventually become familiar with Bitcoin and Lightning technology. By integrating LNbits, Chain Duel transforms in-game payments into a learning opportunity, making Bitcoin and Lightning more approachable for users worldwide.

Tools for Developers

LNbits is a versatile, open-source platform designed to simplify and enhance Bitcoin Lightning Network wallet management. For developers, particularly those working on Lightning-native games like Chain Duel, LNbits offers an invaluable set of tools that allow for seamless integration of Lightning payments without the need to build complex custom solutions from scratch. LNbits is built on a modular and extensible architecture, enabling developers to easily add or create functionality suited to their project’s needs.

Extensible Architecture for Customization

At the core of LNbits is a simple yet powerful wallet system that developers can access across multiple devices. What makes LNbits stand out is its extensible nature—everything beyond the core functionality is implemented as an extension. This modular approach allows users to customize their LNbits installation by enabling or building extensions to suit specific use cases. This flexibility is perfect for developers who want to add Lightning-based services to their games or apps without modifying the core codebase.

• Extensions for Every Use Case
  LNbits comes with a wide array of built-in extensions created by contributors, offering various services that can be plugged into your application. Some popular extensions include:
• Faucets: Distribute small amounts of Bitcoin to users for testing or promotional purposes.
• Paylinks: Create shareable links for instant payments.
• Points-of-sale (PoS): Allow users to set up shareable payment terminals.
• Paywalls: Charge users to access content or services.
• Event tickets: Sell tickets for events directly via Lightning payments.
• Games and services: From dice games to jukeboxes, LNbits offers entertaining and functional tools.

These ready-made solutions can be adapted and used in different gaming scenarios, for example in Chain Duel, where LNURL extensions are used for in game payments. The extensibility ensures developers can focus on building engaging gameplay while LNbits handles payment flows.

Developer-Friendly Customization

LNbits isn't just a plug-and-play platform. Developers can extend its functionality even further by creating their own extensions, giving full control over how the wallet system is integrated into their games or apps. The architecture is designed to make it easy for developers to build on top of the platform, adding custom features for specific requirements.

Flexible Funding Source Management

LNbits also offers flexibility in terms of managing funding sources. Developers can easily connect LNbits to various Lightning Network node implementations, enabling seamless transitions between nodes or even different payment systems. This allows developers to switch underlying funding sources with minimal effort, making LNbits adaptable for games that may need to scale quickly or rely on different payment infrastructures over time.

A Lean Core System for Maximum Efficiency

Thanks to its modular architecture, LNbits maintains a lean core system. This reduces complexity and overhead, allowing developers to implement only the features they need. By avoiding bloated software, LNbits ensures faster transactions and less resource consumption, which is crucial in fast-paced environments like Chain Duel where speed and efficiency are paramount.

LNbits is designed with developers in mind, offering a suite of tools and a flexible infrastructure that makes integrating Bitcoin payments easy. Whether you’re developing games, apps, or any service that requires Lightning Network transactions, LNbits is a powerful, open-source solution that can be adapted to fit your project.

Conclusion

Chain Duel stands at the forefront of Lightning-powered gaming, combining the excitement of competitive PvP with the speed and efficiency of the Lightning Network. With LNbits handling all in-game payments, from microtransactions to automated revenue splits, developers can focus entirely on crafting an engaging gaming experience. LNbits’ powerful API and extensions make it easy to manage real-time payments, removing the complexity of building payment infrastructure from scratch.

LNbits isn’t just a payment tool — it’s a flexible, developer-friendly platform that can be adapted to any gaming model. Whether you're developing a fast-paced PvP game like Chain Duel or any project requiring seamless Lightning Network integration, LNbits provides the ideal solution for handling instant payments with minimal overhead.

For developers interested in pushing the boundaries of Lightning-powered gaming, Chain Duel is a great example of how LNbits can enhance your game, letting you focus on the fun while LNbits manages real-time transactions.

Find out more

Curious about how Lightning Network payments can power your next game? Explore the following:

• Learn more about Chain Duel: Chain Duel
• Learn how LNbits can simplify payment handling in your project: LNbits
• Dive into decentralized communication with Nostr: Nostr

@ c4f5e7a7:8856cac7

Best viewed on Habla, YakiHonne or Highlighter.

TL;DR

This article explores the links between public, community-driven data sources (such as OpenStreetMap) and private, cryptographically-owned data found on networks such as Nostr.

The following concepts are explored:

1. Attestations: Users signalling to their social graph that they believe something to be true by publishing Attestations. These social proofs act as a decentralised verification system that leverages your web-of-trust.
2. Proof of Place: An oracle-based system where physical letters are sent to real-world locations, confirming the corresponding digital ownership via cryptographic proofs. This binds physical locations in meatspace with their digital representations in the Nostrverse.
3. Check-ins: Foursquare-style check-ins that can be verified using attestations from place owners, ensuring authenticity. This approach uses web-of-trust to validate check-ins and location ownership over time.

The goal is to leverage cryptographic ownership where necessary while preserving the open, collaborative nature of public data systems.

Open Data in a public commons has a place and should not be thrown out with the Web 2.0 bathwater.

Cognitive Dissonance

Ever since discovering Nostr in August of 2022 I've been grappling with how BTC Map - a project that helps bitcoiners find places to spend sats - should most appropriately use this new protocol.

I am assuming, dear reader, that you are somewhat familiar with Nostr - a relatively new protocol for decentralised identity and communication. If you don’t know your nsec from your npub, please take some time to read these excellent posts: Nostr is Identity for the Internet and The Power of Nostr by @max and @lyn, respectively. Nostr is so much more than a short-form social media replacement.

The social features (check-ins, reviews, etc.) that Nostr unlocks for BTC Map are clear and exciting - all your silos are indeed broken - however, something fundamental has been bothering me for a while and I think it comes down to data ownership.

For those unfamiliar, BTC Map uses OpenStreetMap (OSM) as its main geographic database. OSM is centred on the concept of a commons of objectively verifiable data that is maintained by a global community of volunteer editors; a Wikipedia for maps. There is no data ownership; the data is free (as in freedom) and anyone can edit anything. It is the data equivalent of FOSS (Free and Open Source Software) - FOSD if you will, but more commonly referred to as Open Data.

In contrast, Notes and Other Stuff on Nostr (Places in this cartographic context) are explicitly owned by the controller of the private key. These notes are free to propagate, but they are owned.

How do we reconcile the decentralised nature of Nostr, where data is cryptographically owned by individuals, with the community-managed data commons of OpenStreetMap, where no one owns the data?

Self-sovereign Identity

Before I address this coexistence question, I want to talk a little about identity as it pertains to ownership. If something is to be owned, it has to be owned by someone or something - an identity.

All identities that are not self-sovereign are, by definition, leased to you by a 3rd party. You rent your Facebook identity from Meta in exchange for your data. You rent your web domain from your DNS provider in exchange for your money.

Taken to the extreme, you rent your passport from your Government in exchange for your compliance. You are you at the pleasure of others. Where Bitcoin separates money from the state; Nostr separates identity from the state.

Or, as @nvk said recently: "Don't build your house on someone else's land.".

https://i.nostr.build/xpcCSkDg3uVw0yku.png

While we’ve had the tools for self-sovereign digital identity for decades (think PGP keys or WebAuthN), we haven't had the necessary social use cases nor the corresponding social graph to elevate these identities to the mainstream. Nostr fixes this.

Nostr is PGP for the masses and will take cryptographic identities mainstream.

Full NOSTARD?

Returning to the coexistence question: the data on OpenStreetMap isn’t directly owned by anyone, even though the physical entities the data represents might be privately owned. OSM is a data commons.

We can objectively agree on the location of a tree or a fire hydrant without needing permission to observe and record it. Sure, you could place a tree ‘on Nostr’, but why should you? Just because something can be ‘on Nostr’ doesn’t mean it should be.

https://i.nostr.build/s3So2JVAqoY4E1dI.png

There might be a dystopian future where we can't agree on what a tree is nor where it's located, but I hope we never get there. It's at this point we'll need a Wikifreedia variant of OpenStreetMap.

While integrating Nostr identities into OpenStreetMap would be valuable, the current OSM infrastructure, tools, and community already provide substantial benefits in managing this data commons without needing to go NOSTR-native - there's no need to go Full NOSTARD. H/T to @princeySOV for the original meme.

https://i.nostr.build/ot9jtM5cZtDHNKWc.png

So, how do we appropriately blend cryptographically owned data with the commons?

If a location is owned in meatspace and it's useful to signal that ownership, it should also be owned in cyberspace. Our efforts should therefore focus on entities like businesses, while allowing the commons to manage public data for as long as it can successfully mitigate the tragedy of the commons.

The remainder of this article explores how we can:

1. Verify ownership of a physical place in the real world;
2. Link that ownership to the corresponding digital place in cyberspace.

As a side note, I don't see private key custodianship - or, even worse, permissioned use of Places signed by another identity's key - as any more viable than the rented identities of Web 2.0.

And as we all know, the Second Law of Infodynamics (no citation!) states that:

"The total amount of sensitive information leaked will always increase over time."

This especially holds true if that data is centralised.

Not your keys, not your notes. Not your keys, not your identity.

Places and Web-of-Trust

@Arkinox has been leading the charge on the Places NIP, introducing Nostr notes (kind 37515) that represent physical locations. The draft is well-crafted, with bonus points for linking back to OSM (and other location repositories) via NIP-73 - External Content IDs (championed by @oscar of @fountain).

However, as Nostr is permissionless, authenticity poses a challenge. Just because someone claims to own a physical location on the Internet doesn’t necessarily mean they have ownership or control of that location in the real world.

Ultimately, this problem can only be solved in a decentralised way by using Web-of-Trust - using your social graph and the perspectives of trusted peers to inform your own perspective. In the context of Places, this requires your network to form a view on which digital identity (public key / npub) is truly the owner of a physical place like your local coffee shop.

This requires users to:

1. Verify the owner of a Place in cyberspace is the owner of a place in meatspace.
2. Signal this verification to their social graph.

Let's look at the latter idea first with the concept of Attestations ...

Attestations

A way to signal to your social graph that you believe something to be true (or false for that matter) would be by publishing an Attestation note. An Attestation note would signify to your social graph that you think something is either true or false.

Imagine you're a regular at a local coffee shop. You publish an Attestation that says the shop is real and the owner behind the Nostr public key is who they claim to be. Your friends trust you, so they start trusting the shop's digital identity too.

However, attestations applied to Places are just a single use case. The attestation concept could be more widely applied across Nostr in a variety of ways (key rotation, identity linking, etc).

Here is a recent example from @lyn that would carry more signal if it were an Attestation:

https://i.nostr.build/lZAXOEwvRIghgFY4.png

Parallels can be drawn between Attestations and transaction confirmations on the Bitcoin timechain; however, their importance to you would be weighted by clients and/or Data Vending Machines in accordance with:

1. Your social graph;
2. The type or subject of the content being attested and by whom;
3. Your personal preferences.

They could also have a validity duration to be temporally bound, which would be particularly useful in the case of Places.

NIP-25 (Reactions) do allow for users to up/downvote notes with optional content (e.g., emojis) and could work for Attestations, but I think we need something less ambiguous and more definitive.

‘This is true’ resonates more strongly than ‘I like this.’.

https://i.nostr.build/s8NIG2kXzUCLcoax.jpg

There are similar concepts in the Web 3 / Web 5 world such as Verified Credentials by tdb. However, Nostr is the Web 3 now and so wen Attestation NIP?

https://i.nostr.build/Cb047NWyHdJ7h5Ka.jpg

That said, I have seen @utxo has been exploring ‘smart contracts’ on nostr and Attestations may just be a relatively ‘dumb’ subset of the wider concept Nostr-native scripting combined with web-of-trust.

Proof of Place

Attestations handle the signalling of your truth, but what about the initial verification itself?

We already covered how this ultimately has to be derived from your social graph, but what if there was a way to help bootstrap this web-of-trust through the use of oracles? For those unfamiliar with oracles in the digital realm, they are simply trusted purveyors of truth.

Introducing Proof of Place, an out–of-band process where an oracle (such as BTC Map) would mail - yes physically mail- a shared secret to the address of the location being claimed in cyberspace. This shared secret would be locked to the public key (npub) making the claim, which, if unlocked, would prove that the associated private key (nsec) has physical access to the location in meatspace.

One way of doing this would be to mint a 1 sat cashu ecash token locked to the npub of the claimant and mail it to them. If they are able to redeem the token then they have cryptographically proven that they have physical access to the location.

Proof of Place is really nothing more than a weighted Attestation. In a web-of-trust Nostrverse, an oracle is simply a npub (say BTC Map) that you weigh heavily for its opinion on a given topic (say Places).

In the Bitcoin world, Proof of Work anchors digital scarcity in cyberspace to physical scarcity (energy and time) in meatspace and as @Gigi says in PoW is Essential:

"A failure to understand Proof of Work, is a failure to understand Bitcoin."

In the Nostrverse, Proof of Place helps bridge the digital and physical worlds.

@Gigi also observes in Memes vs The World that:

"In Bitcoin, the map is the territory. We can infer everything we care about by looking at the map alone."

https://i.nostr.build/dOnpxfI4u7EL2v4e.png

This isn’t true for Nostr.

In the Nostrverse, the map IS NOT the territory. However, Proof of Place enables us to send cryptographic drones down into the physical territory to help us interpret our digital maps. 🤯

Check-ins

Although not a draft NIP yet, @Arkinox has also been exploring the familiar concept of Foursquare-style Check-ins on Nostr (with kind 13811 notes).

For the uninitiated, Check-ins are simply notes that signal the publisher is at a given location. These locations could be Places (in the Nostr sense) or any other given digital representation of a location for that matter (such as OSM elements) if NIP-73 - External Content IDs are used.

Of course, not everyone will be a Check-in enjoyooor as the concept will not sit well with some people’s threat models and OpSec practices.

Bringing Check-ins to Nostr is possible (as @sebastix capably shows here), but they suffer the same authenticity issues as Places. Just because I say I'm at a given location doesn't mean that I am.

Back in the Web 2.0 days, Foursquare mitigated this by relying on the GPS position of the phone running their app, but this is of course spoofable.

How should we approach Check-in verifiability in the Nostrverse? Well, just like with Places, we can use Attestations and WoT. In the context of Check-ins, an Attestation from the identity (npub) of the Place being checked-in to would be a particularly strong signal. An NFC device could be placed in a coffee shop and attest to check-ins without requiring the owner to manually intervene - I’m sure @blackcoffee and @Ben Arc could hack something together over a weekend!

Check-ins could also be used as a signal for bonafide Place ownership over time.

Summary: Trust Your Bros

So, to recap, we have:

Places: Digital representations of physical locations on Nostr.

Check-ins: Users signalling their presence at a location.

Attestations: Verifiable social proofs used to confirm ownership or the truth of a claim.

You can visualise how these three concepts combine in the diagram below:

https://i.nostr.build/Uv2Jhx5BBfA51y0K.jpg

And, as always, top right trumps bottom left! We have:

Level 0 - Trust Me Bro: Anyone can check-in anywhere. The Place might not exist or might be impersonating the real place in meatspace. The person behind the npub may not have even been there at all.

Level 1 - Definitely Maybe Somewhere: This category covers the middle-ground of ‘Maybe at a Place’ and ‘Definitely Somewhere’. In these examples, you are either self-certifying that you have checked-in at an Attested Place or you are having others attest that you have checked-in at a Place that might not even exist IRL.

Level 2 - Trust Your Bros: An Attested Check-in at an Attested Place. Your individual level of trust would be a function of the number of Attestations and how you weigh them within your own social graph.

https://i.nostr.build/HtLAiJH1uQSTmdxf.jpg

Perhaps the gold standard (or should that be the Bitcoin standard?) would be a Check-in attested by the owner of the Place, which in itself was attested by BTC Map?

Or perhaps not. Ultimately, it’s the users responsibility to determine what they trust by forming their own perspective within the Nostrverse powered by web-of-trust algorithms they control. ‘Trust Me Bro’ or ‘Trust Your Bros’ - you decide.

As we navigate the frontier of cryptographic ownership and decentralised data, it’s up to us to find the balance between preserving the Open Data commons and embracing self-sovereign digital identities.

Thanks

With thanks to Arkinox, Avi, Ben Gunn, Kieran, Blackcoffee, Sebastix, Tomek, Calle, Short Fiat, Ben Weeks and Bitcoms for helping shape my thoughts and refine content, whether you know it or not!

@ 8cb60e21:5f2deaea

@ 8cb60e21:5f2deaea

@ 460c25e6:ef85065c

NIPs (Nostr Implementation Possibilities) are technical specifications that Nostr developers create to define how specific event types and tags are used. These can be written before or after the feature is implemented and often go through multiple revisions before becoming stable enough to matter. Once two or more clients fully implement the proposal, it is merged into the main repository. This process ensures that while new ideas are encouraged, they are also rigorously reviewed and tested.

There are generally two paths for NIPs: 1. New Ideas, when developers just have a hunch on a new solution and want to quickly write something up to gather feedback from the community. These are my favorite NIPs because they generally introduce a new way of thinking about a problem we are all having. And because they are not just a general solution, but a specific proposal, it allows us to see the entire picture in just a few paragraphs. Even though they are my favorite, they are quite "green" and usually spur 2-3 separate solutions in following PRs by different authors. 2. Existing implementations that need to explain what they are doing. These happen when a client is already running the code in production and simply wants to explain to the rest of the community how to generate and interpret the events the client is creating. These NIPs start much more stable than the former and allow for fewer changes, but because there is already an implementation available, it's a market-tested solution that might just need a few adjustments before others start implementing it.

Well-written specs ensure clarity, reduce ambiguity, and help developers implement the proposal consistently. The text should be VERY short, precise, prescriptive, and actionable by other devs. Start by introducing the new kind or tag in the first sentence and jump straight into a mockup of how the event looks like. The mockup should be self-explanatory and provide clues to what the remaining of the document will talk about. Some folks like to add long/verbose introductions, conclusions, and discussions of the reasons why the NIP is needed or why certain features are there. But those are largely unnecessary and are more appropriate to be placed in the body of the Pull Request descriptor.

Start your NIP with the following template:

``` NIP- ======