Cresci em cidade grande e embora tivesse uma vendinha bem perto de casa, que tinha aquelas jarras de vidro cheias de balas pra eu pedir pra mamãe quando eu passava por lá no caminho do colégio, no geral pra mim supermercado sempre foi uma coisa com “super” no nome. Aquela história: um grande espaço, mil corredores e um estoque infindável de todo tipo de coisa.

A maioria dos supermercados cooperativos se baseam na idéia do Park Slope Food Coop (abre em uma nova janela ), em Nova Iorque. O Park Slope Food Coop foi fundado em 1973 e opera em um sistema em que para fazer compras no supermercado, a pessoa precisa ser uma cooperadora. Pra se tornar uma cooperadora, as pessoas pagam um valor uma vez (comprando uma parte na cooperativa) e pra manter seu status ativo, fazem um turno de trabalho de 2h45 uma vez por mês no supermercado, em tarefas que fazem o supermercado funcionar (estoque, manutenção, administração, etc).

Nunca visitei o Park Slope, mas o primeiro supermercado cooperativo que eu visitei foi La Cagette (abre em uma nova janela ), em Montpellier, no início de 2019 e eu fiquei imediatamente encantado pela ideia. A atmosfera do lugar era bem diferente, mais próxima da vendinha que eu me lembrava quando era criança. Ao invés do ambiente cheio de propaganda, com alguns produtos sendo iluminados como se fossem sagrados, o ambiente era bem mais tranquilo, as pessoas que entravam e saíam se conheciam e conversavam no caixa ou enquanto estavam estocando uma prateleira.

Um supermercado tradicional tem todos os elementos do capitalismo moderno: o marketing agressivo, descontos risíveis se você der informações suas e sempre se identificar quando faz compras de modo que eles possam fazer um perfil seu, funcionários mal pagos executando funções repetitivas por horas a fio (e muitas vezes mais de uma função ao mesmo tempo). Além disso, supermercados tendem a ter uma margem de lucro variável nos produtos, muitas vezes legumes ou macarrão são muito baratos e tem uma margem de lucro bem pequena, e quando você compra algo como uma caneta ou uma pilha, ou um produto orgânico, é nesse tipo de coisa que tem uma margem gigantesca.

Quando voltei pra Bruxelas depois de conhecer La Cagette, fui procurar pra saber se algo do tipo existia por aqui. E encontrei a BEES coop (abre em uma nova janela ).

A BEES coop começou como um grupo de compras, as pessoas que participavam do grupo tomavam decisões sobre o que comprar e compravam coletivamente para obter preços reduzidos pro grupo. Mas a ideia foi se transformando até que, também se inspirando no Park Slope, se transformou no atual supermercado cooperativo que funciona desde 2017.

O supermercado lembra um supermercado tradicional: tem cestas e carrinhos e uma gama de produtos que vai de arroz e carnes até produtos de higiene de peças de bicicleta. A grande diferença é na escolha do que entra na loja: essa escolha é também feita de maneira participativa, e prioriza produtos orgânicos, locais ou de cooperativas; e muitas vezes prioridade para o pequeno produtor, mesmo que não tenha o selo “xyz”, ao invés do grande distribuidor. Além disso, também tem um monte de coisa que é disponível a granel: macarrão, arroz, lentilha, sabonete líquido, vinho e mesmo azeite. Dá pra levar seu saco, pote ou garrafa e encher por lá mesmo.

Além dos cooperadores, existem seis pessoas assalariadas que trabalham em tempo parcial. Elas também trabalham na loja, mas uma grande parte do seu trabalho é de fazer os pedidos de produtos, decidir o posicionamento de produtos na loja, recepcionar encomendas e repassar às cooperadoras no início do turno quais são as tarefas pendentes para o turno atual.

Toda pessoa cooperadora tem um cartão, que lhe identifica na entrada da loja e com o qual pode fazer suas compras. Além disso, tem direito a nomear duas outras pessoas de mais de 18 anos que vivem sob o mesmo teto, essas não precisam trabalhar, são “comedoras” e ganham seus próprios cartões para fazer compras.

Eu, como cooperador, trabalho 2h45 na loja por mês. Às vezes fico no caixa, outras vezes reabastecendo prateleiras, na entrada da loja ou arrumando o estoque. Tem também gente que trabalha no escritório, recebendo novos membros, atualizando os status dos membros atuais e outras tarefas do tipo; Tem gente que trabalha no corte de queijos; Tem gente que limpa a loja e guarda os legumes na câmara fria no fim do dia; E tem gente que faz trabalhos em comitês específicos, como o comitê que organiza a assembléia geral ou o comitê que seleciona os produtos.

Um turno normalmente tem uma pessoa “supercooperadora”, que faz um treinamento com as pessoas assalariadas para saber mais sobre o funcionamento da loja, além de ser o ponto de contato das outras cooperadoras para ausências inesperadas. Além disso, é para a supercooperadora que os funcionários explicam quais tarefas tem mais prioridade no turno atual. Além dos trabalhos de sempre, como caixa e entrada da loja, as vezes entregas precisam ser organizadas no estoque, novos produtos precisam ser registrados no sistema da loja, ou as prateleiras de cerveja estão quase vazias e precisam de uma atenção especial ;)

Cada turno de trabalho na loja começa com os membros se reunindo, recebendo da supercooperadora as tarefas para o turno e então se dividindo pra realizar as tarefas. E depois de umas horinhas, todo mundo se despede, com o novo turno acontecendo só dali a 4 semanas.

Trabalhar e fazer as compras na BEES é uma experiência agradável. Não só você conhece os rostos que dividem seus turnos com você, mas você começa a encontrar as mesmas pessoas que fazem compras em horários similares a você, e depois a encontrar essas pessoas nas assembléias gerais. O comitê de vinhos as vezes coloca um aviso caloroso dizendo que eles acharam um novo vinho super gostoso e que você devia experimentar. Quando você está no caixa é normal ver as pessoas conversando dizendo que tal e tal produto são novos e são tão bons por causa disso e daquilo. E nos corredores é comum ver gente se reconhecendo e começando a conversar.

Uma coisa importante, que me perguntam com frequência é: “tá, tudo muito bonito, seu Lond, mas e o preço das coisas?”. E a verdade é que depende. Como eu disse lá no alto, um supermercado tradicional trabalha com uma margem variável de lucro, cada produto tem uma margem diferente. Na BEES a margem é constante. Todo produto tem uma margem de 20%. A loja não tem fins lucrativos, a margem está lá para a manutenção da loja e salários dos funcionários.

A nossa experiência é que o preço médio do carrinho é bem próximo do que é no supermercado tradicional. A gente também começou a comprar mais coisas orgânicas, porque o preço é bem próximo do não-orgânico no supermercado normal. Tem produtos mais caros e algumas marcas tradicionais simplesmente não são vendidos por lá.

E a quantidade plástico que a gente traz pra casa diminuiu de maneira espetacular. Os produtos de supermercado aqui tendem a ter muito mais embalagem plástica do que no Brasil, tenho impressão. E na BEES tem um incentivo ativo a reutilização, então a gente começou a usar sacos laváveis de pano pra legumes e granel, dá preferência pra embalagens de vidro que são retornáveis (ou mesmo quando não são, por aqui tem lixeiras especiais pra vidro, que são reciclados) e pra coisas como óleo e azeite a gente enche os galões a granel, reusando as mesmas garrafas de vidro pra encher de azeite na cozinha no dia-a-dia.

O projeto não é perfeito, claro, mas é uma demonstração agrádavel de que é possível se organizar de maneiras diferentes dentro do capitalismo, enquanto não saímos dele. Que é possível encontrar formas alternativas de fazer coisas essenciais como suas compras de mês que operam de uma forma coletiva, com uma preocupação ambiental e uma preocupação com o aspecto humano, com o trabalhador do outro lado da produção, evitando os grandes conglomerados que infectam a vida do dia-a-dia e tem tanto poder.

Tentei buscar um pouco e não achei projetos similares no Brasil. Sei que existem lojas, como o Armazém do Campo do MST, que tentam aproximar o produtor do consumidor e vendem produtos de assentamentos e de pequenos agricultores. Mas não achei nada com o mesmo modelo participativo, como a BEES ou Park Slope.

Em todo caso, deixo algumas sugestões pra você lendo esse texto: preste atenção o quanto de coisas você compra no supermercado é por causa de propaganda. Pense em comprar mais coisas a granel, no Rio eu sei que existem lojas tradicionais de granel, não são nenhuma BEES, mas você vai sentir o quanto isso diminui o uso de plástico. E por fim, procure projetos que te conectem a pequenos produtores, enquanto a gente não tira do poder do agronegócio por maneiras diretas, a gente pode tirar o poder do agronegócio indo ao pequeno produtor quando possível.

Eu já tinha reclamado do facebook em 2015 (abre em uma nova janela ); na época a preocupação era mais em termos de como eu consumia informação na internet. Eu procurei alternativas ao Facebook que tinha se tornado meu modo de consumir notícias e de passar as notícias a frente.

As preocupações com privacidade começaram quase ao mesmo tempo, posts como esse do Splinter, de 2016 (abre em uma nova janela ) ou esse do Gizmodo, de 2017 (abre em uma nova janela ) mostravam que os algoritmos de recomendação de amigos do Facebook tinham muito mais informação do que eles deixavam transparecer.

Em seguida todo o escândalo da Cambridge Analytica ganhou força, e logo depois, uma montanha de revelações ainda piores e a campanha #DeleteFacebook começou a ganhar força. Um artigo do New York Times fala de como o Facebook lutou contra os escândalos usando de lobbying e de difamação contra outras empresas. (abre em uma nova janela ).

No entanto, uma coisa sempre necessária de lembrar é que o Facebook é dono do Instagram e do Whatsapp. Hoje em dia, já há quem diga que a compra do Instagram pelo Facebook foi a maior falha regulatória da última década. (abre em uma nova janela )

Sair do Facebook foi um passo importante, mas pra manter contato com outras pessoas, é sempre muito difícil fugir do Whatsapp e do Instagram. A verdade é que o ideal seria que o Facebook (e o Google, já que estamos falando do assunto), sofressem um processo semelhante ao que a Microsoft passou no fim dos anos 90 (abre em uma nova janela ), quando a empresa teve que ser dividida, e o resultado foi o fôlego dado a outros navegadores como Firefox e Chrome, que puderam finalmente causar uma mudança na internet, que antes era basicamente dedicada ao Internet Explorer.

No entanto, como estamos falando de aplicações sociais por natureza, ações individuais como o #DeleteFacebook podem sim ter efeitos que tiram o poder da rede como um todo, a prova disso é como o Facebook já começou a mover sua atenção para o Instagram de diversas formas, como quando notificações de que pessoas que você seguia tinham postado fotos no Facebook estavam sendo testadas no Instagram (abre em uma nova janela ). Ao mesmo tempo, o Whatsapp deve receber anúncios em breve. (abre em uma nova janela )

Tudo isso mostra como o Facebook pretende continuar extendendo sua influência para os outros apps, em uma tentativa de manter seu controle sobre o dados dos seus usuários.

Por isso, uma das minhas resoluções de 2019 é de tentar abandonar o Instagram. A minha idéia é começar a mover mais e mais para o Fediverso (abre em uma nova janela ), agora que o Pixelfed (abre em uma nova janela ), uma alternativa ao instagram, começa a tomar forma.

Resta ver se a mudança vai ser possível. Que tal também vir pro Fediverso comigo? 😉

Com a escalada do fascismo e o fato de que nossas vidas estão cada vez mais presentes online, é preciso tomar precauções para que nossas identidades digitais não caiam nas mãos erradas. Primeiro porque isso pode revelar informações valiosas nossas e de pessoas queridas à nossa volta. Segundo porque isso pode permitir que atacantes passem informações falsas usando nossas identidades.

Esse post está dividido em duas partes: uma parte de dicas mais gerais e uma parte de recomendações de apps pra substituir.

As recomendações estão num formato em que você pode passar rapidamente o olho e ver os apps recomendados, seguido pelo porque dos outros apps não serem recomendados e por fim uma pequena explicação do porque os apps recomendados estarem na lista.

No geral, ao longo desse guia, uma coisa é recorrente: evite os conglomerados tecnológicos. Google e Facebook sobrevivem de coletar seus dados e seus aplicativos coletam a maior quantidade de dados possíveis. Além disso, evite aplicativos e redes que não encriptam seus dados, porque seus dados podem ser divulgados tanto por causa de vulnerabilidades, quanto por outros meios (por exemplo, podem ser acessados por empregados das empresas e vendidos pra quem paga mais).

Segurança digital é uma luta constante e é preciso se acostumar a ter todos os ítens na cabeça. Mesmo que você resolva adotar todas as sugestões que eu comento por aqui, vai levar um tempo até isso estar naturalizado. Não desista porque uma coisa ou outra ainda não está de acordo com esse guia (ou com outros guias de segurança que você pode encontrar por aí).

Esse guia é mais um dentre outros guias que podem ser encontrados na internet. Posts como Um manual de segurança digital para tempos sombrios (abre em uma nova janela ) e livros como Queer Privacy: Essays From The Margins Of Society (abre em uma nova janela ) foram usados como referências para esse post.

Se quiser fazer uma correção nesse post ou discutir algum ponto, só entrar em contato por um dos meios disponíveis ali no link sobre, ou ainda, abrir uma discussão direto no github

Tenha em mente: esse post não é revisado com frequência, antes de usar cegamente um dos apps daqui, dê uma pesquisada rápida para ver o status atual do aplicativo. Muita coisa muda o tempo todo :) Uma outra boa fonte, em inglês, de recomendações que está bem alinhada com as recomendações nesse post é o Think Privacy (abre em uma nova janela ).

Dicas gerais

Webcam e microfone

Podem parecer dicas batidas, mas cubra a sua webcam quando não estiver usando. A solução barata é um post-it na frente da câmera, mas existem alguns adesivos especialmente para esse fim que facilitam caso você usa a sua câmera com frequência para chamadas, que deslizam pra cubrir a câmera, dá pra achar por uns R$10 pela internet.

No caso do microfone, as instruções variam de modelo pra modelo, mas o conselho é o mesmo, desligue quando não estiver usando. Alguns notebooks tem um botão pra dar mute no microfone, outros não são tão fáceis.

Nos dois casos a idéia é evitar capturas indesejadas.

Autenticação em dois passos

A autenticação em dois passos (conhecida como 2FA, do inglês 2-factor authentication) deve ser ligada para todos os serviços possíveis. Evite usar autenticação em dois passos que dependa de recepção de SMS, prefira aplicativos que gerem a autenticação baseada em tempo, como o FreeOTP (alguns gerenciadores de senha tem essa opção, também).

Com a autenticação em dois passos ativada, para alguém ter acesso à uma das suas contas, além de ter acesso a sua senha, o atacante também deve ter acesso ao seu aplicativo gerador, o que dificulta bastante o acesso.

A autenticação por SMS sofre do problema de estar vulnerável a clonagem de chip, o que é extremamente comum. A vice escreveu um artigo, em inglês, sobre a técnica (abre em uma nova janela ). De maneira curta: os atacantes fazem engenharia social para conseguir clonar os chips de dentro das operadoras. Com isso, conseguem os códigos de confirmação necessários para fazer login. Essa técnica foi usada para derrubar o grupo de facebook “Mulheres contra Bolsonaro”, por exemplo.

Gerenciador de senhas

Use: bitwarden (abre em uma nova janela ), KeePassXC (abre em uma nova janela )
Evite: Salvar suas senhas no navegador

Toda semana tem um site sendo invadido e uma lista de senhas é disponibilizada na internet, listas essas que normalmente são uma combinação de emails e senhas. Usar a mesma senha em diversos sites faz com que haja o risco de que quando um site é atacado, todos os outros sites em que usamos a mesma senha possam então ser invadidos sem esforço algum.

Existem diversas aplicações que geram senhas para nós. A idéia dessas aplicações é que nós mantemos somente uma senha, mais complexa, e não sabemos as outras senhas que utilizamos em outros sites, usando senhas geradas por esses aplicativos que são complexas e individuais para cada site.

Usar um gerenciador de senhas requer uma mudança de mentalidade, para que nunca usemos “aquela” senha que a gente usa em todos os sites pra novos cadastros e pra que pouco a pouco possamos mudar as nossas senhas existentes.

Recomendo começar a mudança com passos de formiguinha: escolha um site que você usa bastante e use o gerenciador de senhas para esse site, e somente para ele, por alguns meses. A ideia é acostumar com o fato de ter que desbloquear o gerenciador e se acostumar de que você não vai saber a senha do site de cabeça e que não há problema nisso. E aí, num segundo passo, é começar a ir mudando senhas em outros sites, sempre usando senhas geradas.

Eu recomendo o bitwarden (abre em uma nova janela ), disponível para a maioria dos sistemas operacionais e browsers, além de sincronizar automaticamente pela internet. Outra boa opção é o KeePassXC (abre em uma nova janela ), que usa um arquivo local e permite mais controle, necessitando de um pouco mais de trabalho no sentido de ter que sincronizar o arquivo semi-manualmente (usando a nuvem para sincronizar automaticamente, ou pendrive e similares).

Não é diretamente relacionado, mas vale lembrar: evite salvar suas senhas no navegador; em alguns casos como no Chrome/Chromium elas são sincronizadas pela internet e é muito fácil de ter acesso indevido à essas senhas, mesmo usando outros navegadores. Mesmo que você decida usar suas próprias senhas, use algum gerenciador de senha pra digitar as senhas automaticamente pra você ao invés de salvar no navegador.

Redes sem fio sem senha

Muito comum em aeroportos, hotéis e outros lugares públicos em geral, redes sem fio que não tenham senha devem ser evitadas. Todo o tráfego entre o seu computador (ou telefone) e a internet fica em aberto nessas redes. Qualquer um por perto pode capturar esse tráfego e saber os sites que você está acessando e caso o site não use https, pode inclusive capturar senhas e outros dados sensíveis.

Pra quando não dá pra escolher, o jeito é usar uma VPN.

VPNs

VPNs (em português: redes privadas virtuais) são uma camada extra de segurança em cima da sua rede. É como se você estabelecesse um túnel entre o seu dispositivo e o servidor da VPN, e para chegar à internet o tráfego tem de passar por esse túnel.

A vantagem desse tipo de túnel é que todo o tráfego é criptografado entre o seu dispositivo e o servidor, e o servidor pode estar em outros países (passando por bloqueios locais ou censuras a certos serviços). A desvantagem é que todo o seu tráfego vai passar por um servidor de terceiros.

Por esse motivo, VPNs gratuitas devem ser evitadas. Essas VPNs podem ser montadas com o propósito de coletar dados ou de servir malware.

Para uma lista completa, existe a lista do That One Privacy Site (abre em uma nova janela ), que tem detalhadas comparações entre VPNs comerciais. Algumas recomendações bem cotadas na comparação: SecureVPN.to (abre em uma nova janela ), Mullvad (abre em uma nova janela ), ProtonVPN (abre em uma nova janela ), VikingVPN (abre em uma nova janela ).

As assinaturas são meio caras mesmo, mas normalmente as VPNs permitem um número de conexões simultâneas, então dá pra rachar um pacote com pessoas próximas pra baratear.

Extensões para navegador

A internet atual é baseada em anúncios e redes de anunciantes adoram coletar todos os dados possíveis para cruzar o que nos mostrar. Para evitar esse tipo de rastreamento, o ideal é instalar algumas extensões que diminuem essa exposição, ao menos no computador:

• uBlock origin (abre em uma nova janela ): Bloqueia anúncios e coletores de informações mais comuns
• Privacy Badger (abre em uma nova janela ): Extensão da Eletronic Frontier Foundation, que também bloqueia anúncios e coletores de informações comuns

As duas extensões tem trabalhos semelhantes, mas com frequência bloqueiam coisas diferentes. Trabalhando em conjunto reduzem bastante o número de anúncios e informações que são coletadas por anunciantes.

Ligue a criptografia do seu celular e computador

Ligar a criptografia no seu celular vai ajudar no caso de perda ou furto, protegendo seus dados contra acesso indevido. Quase todo mundo bota uma senha pra desbloquear o celular, mas isso só protege contra um acesso direto. Encriptar o seu celular vai proteger contra acesso usando um computador e ferramentas para acessar o conteúdo do seu celular, sem nunca passar pela tela de desbloqueio.

Algumas notas:

1. ligar a criptografia pode fazer o seu celular ficar ligeiramente mais lento.
2. para desligar a criptografia é necessário retornar o celular às configurações de fábrica

É possível ligar a criptografia em quase todo telefone Android e em todos os iPhones. As instruções variam de aparelho para aparelho. No Android normalmente a configuração fica localizada na parte de segurança, enquanto no iPhone você precisar criar um código de acesso.

No computador também é possível ligar a criptografia para seus dados, os passos são bem diferentes dependendo da versão do seu sistema operacional, então é bom dar uma olhada na ajuda do seu sistema.

Celular e protestos

Se alguem tem acesso físico aos seus dispositivos, fica muito mais difícil de se proteger. Um agente mal intencionado pode forçar você a revelar sua senha e ter acesso ao seu dispotivo. Evitar de levar seu celular pra manifestações pode não ser prático ou desejado (afinal, gravar qualquer coisa que esteja acontecendo pode ser uma parada valiosa depois).

Além da dica da criptografia, evite usar sua digital para destravar seu celular (pelo menos, pela duração do protesto).

O que usar como…

Mecanismo de Busca

Use: DuckDuckGo (abre em uma nova janela ), Searx (abre em uma nova janela )
Evite: Google, Bing

O Google armazena todos seus dados de busca, você pode ver todas as buscas que você realizou no google através de um painel de controle localizado em My Activity (abre em uma nova janela ). O que isso quer dizer é que mais uma vez, seus dados podem ser acessados em caso de vulnerabilidade ou funcionários mal intencionados.

O Bing não está muito atrás, e embora tenha menos dados em sua posse, faz parte da Microsoft que não está muito melhor no quesito “gigante da tecnologia que guarda mais dados do que poderia”.

DuckDuckGo (abre em uma nova janela ) e Searx (abre em uma nova janela ) são dois serviços de buscas que tem a privacidade em mente, sem perder a qualidade das buscas.

Aplicativos de mensagem instantânea

Use: Threema (abre em uma nova janela ), Signal (abre em uma nova janela )
Evite: Whatsapp, Facebook Messenger, Google Hangouts, Google Chats, Telegram, Viber, WeChat, DMs no Twitter

Queremos evitar duas coisas no caso de mensagens instantâneas: armazenamento das mensagens nos servidores do aplicativo, porque podem ser recuperadas através de falhas de segurança ou de funcionários mal intencionados; criptografia ponto-a-ponto, para evitar que alguém possa ler as mensagens sem permissão.

O Whatsapp dispõe de criptografia ponto-a-ponto, mas é de propriedade do Facebook e não dá pra ter certeza de quantos metadados o Facebook armazena de todas as conversas.

O Messenger dispõe de “chats secretos”, mas o resto das conversas não é encriptada e é armazenada nos servidores do Facebook.

Hangouts e chats não dispõe de comunicação segura e toda a comunicação é armazenada nos servidores do Google.

Viber promete criptografia ponto-a-ponto, mas assim como o Whatsapp, não temos como saber o quão segura é a sua implementação.

Outros aplicativos, tais como WeChat não encriptam suas conversas e devem ser evitados.

O Telegram era minha primeira sugestão durante muito tempo. A interface é a melhor dentre os aplicativos de comunicação, mas o seu design faz com que por padrão as conversas não usem criptografia. Só as conversas criadas como “chat secreto” usam criptografia ponto-a-ponto, o que por consequência faz com que as mensagens de conversas normais sejam todas armazenadas nos servidores do Telegram.

Threema (abre em uma nova janela ) e Signal (abre em uma nova janela ) encriptam suas mensagens e tem código aberto disponível para inspeção.

Numa versão anterior desse post eu recomendava o Wire, que também é encriptado ponta-a-ponta. Porém, em 2019 o Wire mudou de mãos e agora pertence a uma companhia estadunidense. Essa mudança foi bastante criticada (abre em uma nova janela ) pela falta de transparência e por vir junto com mudanças suspeitas nos termos de uso (abre em uma nova janela ). Por isso, eu recomendo evitar o Wire se possível.

Email

Use: Protonmail (abre em uma nova janela ), Tutanota (abre em uma nova janela )
Evite: Gmail, Yahoo, Outlook

Assim como no caso de mensagens, queremos evitar que as mensagens estejam visíveis para a empresa que fornece o serviço. A única opção para isso são clientes de email que forneçam criptografia ponto-a-ponto, porque esses fazem seus emails serem criptografados no seu computador e somente o destinatário pode ver o email.

O Gmail tem umas funções que dão a impressão de que seus dados são criptografados, mas elas não são seguras.

As alternativas são Tutanota (abre em uma nova janela ) ou Protonmail (abre em uma nova janela ). Eu recomendo uma conta em cada um. Cada um implementa criptografia de uma maneira diferente e eles (ainda) não são compatíveis entre si. De modo que pra conseguir se comunicar com o máximo de gente possível de modo seguro, o ideal é ter uma conta em cada serviço. Pra quem ainda não usa o serviço, é possível enviar emails protegidos por senha, mas a senha tem que ser comunicada a quem vai receber de alguma forma segura.

Compartilhamento de dados / Nuvem

Use: Nextcloud (abre em uma nova janela )
Evite: Dropbox, iCloud, Google Drive, OneDrive

A grande maioria dos aplicativos de armazenamento de dados na nuvem não tem encriptação dos seus dados. O que quer dizer que os seus arquivos podem ser recuperados por terceiros, por falha de segurança ou funcionários mal intencionados.

Dropbox, iCloud, Google Drive, OneDrive, Box, todas essas soluções de armazenamento na nuvem tem acesso aos seus arquivos.

A recomendação aqui é o Nextcloud (abre em uma nova janela ). Além de ter código aberto, a partir da versão 14 possui uma opção para que os arquivos sejam criptografados localmente e enviados para o servidor criptografados. Ou seja, somente com a sua senha você pode ter acesso aos seus arquivos.

Redes Sociais

Evite: usar redes sociais pra fins de organização de movimentos, coletivos e afins

Aqui cabe um grande parenteses: no geral, redes sociais devem ser consideradas como veículos públicos. Grupos de facebook são ótimos pra trocar histórias, mas devem ser evitados como método de organização de movimentos, coletivos e qualquer outro tipo de luta, nenhuma informação nesses grupos é realmente privada. O mesmo é válido pra outras redes sociais como Twitter, mesmo se a sua conta for fechada, isso quer dizer que os seus seguidores, e os funcionários do Twitter, podem ler suas mensagens.

Um outro problema: Twitter, Facebook e afins usam algoritmos desconhecidos para mostrar ou não os posts para outras pessoas. Isso faz com que eles decidam o que é relevante ou não para ser lido e pode fazer informações importantes serem escondidas por não serem detectadas como “importantes” pelos algoritmos.

Uma nota: se for excluir suas redes sociais, mude os seus perfis para algum país da união européia por alguns dias antes, de preferência usando uma VPN. As leis de proteção de dados da união européia mudaram bastante com o GDPR (abre em uma nova janela ) e é mais garantido que seus dados sejam realmente removidos se o seu perfil for reconhecido como sendo da UE. Vale notar que depois de alguns escândalos o Facebook promete que remover sua conta faz com que ela seja permanentemente removida (abre em uma nova janela ).

Para substituir grupos de Facebook uma opção pode ser usar Matrix (abre em uma nova janela ), que permite a criação de grupos com criptografia inclusive para VoIP.

I still plan to write maybe a small demo on how to get your hands dirty on Mastodon’s codebase, maybe fixing a small bug, but before that we need to have the development environment up and working!

Now, as it’s the case with the guide on how to run your instance, this guide is very similar to the official guide (opens in a new window ), and when in doubt, you should double check the official guide because it’s more likely to be up-to-date. This guide is also very similar to how to run an instance, I mean, it’s the same software, right?

There is also an official guide to setting up your environment using vagrant (opens in a new window ) which might be easier if you have enough resources for a VM running side-by-side with your environment and/or does not run Linux.

This guide is focused on Mastodon, but most of the setup done here will work for other ruby on rails projects you might want to contribute to.

This was last updated on 31st of January, 2019.

Note on the choices made in this guide

The official guide recommends rbenv (opens in a new window ), but I’m more used to rvm (opens in a new window ). rbenv is likely to be more lightweight. So if you don’t have any preferences, you might want to stick to rbenv and ruby-build (opens in a new window ) when installing ruby.

Since this is a development setup, I’m not mentioning any security concerns.
⚠️ Do not use this guide for running a production instance. ⚠️
Refer to how to run a mastodon instance using Arch Linux instead.

Questions are super welcome, you can contact me using any of the methods listed in the about page. Also if you notice that something doesn’t seem right, don’t hesitate to hit me up.

As with the other guide, I tested the steps on this guide on a virtual machine and they should work if you copy-paste them. Things might not work well if your computer has less than 2GB of ram.

General Mastodon development tips

From the official guide:

You can use a localhost->world tunneling service like ngrok (opens in a new window ) if you want to test federation, however that should not be your primary mode of operation. If you want to have a permanently federating server, set up a proper instance on a VPS with a domain name, and simply keep it up to date with your own fork of the project while doing development on localhost.

Ngrok and similar services give you a random domain on each start up. This is good enough to test how the code you’re working on handles real-world situations. But as soon as your domain changes, for everybody else concerned you’re a different instance than before.

Generally, federation bits are tricky to work on for exactly this reason - it’s hard to test. And when you are testing with a disposable instance you are polluting the databases of the real servers you’re testing against, usually not a big deal but can be annoying. The way I have handled this so far was thus: I have used ngrok for one session, and recorded the exchanges from its web interface to create fixtures and test suites. From then on I’ve been working with those rather than live servers.

I advise to study the existing code and the RFCs before trying to implement any federation-related changes. It’s not that difficult, but I think “here be dragons” applies because it’s easy to break.

If your development environment is running remotely (e.g. on a VPS or virtual machine), setting the REMOTE_DEV environment variable will swap your instance from using “letter opener” (which launches a local browser) to “letter opener web” (which collects emails and displays them at /letter_opener ).

When trying to fix a bug or implement a new feature, it is a good idea to branch off the master branch with a new branch and then submit your pull request using that branch.

A good way to see that your environment is working as it should is to check out the latest stable release (for instance, at the time of writing the latest stable release is v2.7.1) and then run tests as suggested in the tests session. They should all pass because the tests in stable releases should always be working.

Dependencies

Since we’re trying to run the same software as in the production guide, we’ll need mostly the same dependencies, this is what we’ll need:

• postgresql: The SQL database used by Mastodon
• redis: Used by mastodon for in-memory data store
• ffmpeg: Used by mastodon for conversion of GIFs to MP4s.
• imagemagick: Used by mastodon for image related operations
• protobuf: Used by mastodon for language detection
• git: Used for version control.
• python2: Used by gyp, a node tool that builds native addons modules for node.js

Besides those, it’s a good idea to install the base-devel group, since it comes with gcc and some ruby modules need to compile native extensions.

Now, you can install those with:

sudo pacman -S postgresql redis ffmpeg imagemagick protobuf git python2 base-devel

PostgreSQL configuration

Take a look at Arch Linux’s wiki about PostgreSQL (opens in a new window ). The first thing to do is to initialize the database cluster. This is done by doing:

sudo -u postgres initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'

If you want to use a different language, there’s no problem.

After this completes, you can then do

sudo systemctl start postgresql # will start postgresql

You will need to start postgresql every time you want to use it for development. You could also enable it so it starts with your system if you prefer, but it will be running and using resources even when you don’t need it.

Now that postgresql is running, we can create your user in postgresql:

# Launch psql as the postgres user
sudo -u postgres psql

In the prompt that opens, you need to do the command below replacing the username you use on your setup.

-- Creates user with SUPERUSER permission level
CREATE USER <your username here> SUPERUSER;

The SUPERUSER level will let you do anything without having to change users. With great powers…

Redis

We also need to start redis. Same as postgresql:

sudo systemctl start redis # will start redis

As with postgres, you can enable it too to make it start with the system, but personally I prefer to start on demand.

Setting up ruby and node

This part is very similar to the production guide, so I’ll copy and paste a bit:

First step is that we install rvm that will be used for configuring ruby. For that we’ll follow the instructions at rvm.io (opens in a new window ). Before doing the following command, visit rvm.io (opens in a new window ) and check which keys need to be added with gpg --keyserver hkp://keys.gnupg.net --recv-keys.

\curl -sSL https://get.rvm.io | bash -s stable

After that, we’ll have rvm. You will see that to use rvm in the same session you need to execute additional commands:

source $HOME/.rvm/scripts/rvm

With rvm installed, we can then install the ruby version that Mastodon uses:

rvm install 2.6.1

Now, this will take some time, drink some water, stretch and come back.

Similarly, we will install nvm for managing which node version we’ll use.

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Refer to nvm github (opens in a new window ) for the latest version.

You will also need to run

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

And add these same lines to ~/.bash_profile

And then to install the node version we’re using:

nvm install 8.11.3

And to install yarn:

npm install -g yarn

While we’re at it, we also need to install bundler:

gem install bundler

And with that we have ruby and npm dependencies ready to go.

Cloning the repo and installing dependencies

You need to clone the repo somewhere on your computer. I usually clone my projects in a source folder in my home directory, if you do different, change the following instructions accordingly.

cd ~/source
git clone https://github.com/tootsuite/mastodon.git

And then, cd ~/source/mastodon and we will install the dependencies of the project:

bundle install # install ruby dependencies
yarn install --pure-lockfile # install node dependencies

This will also take a while, try to relax a bit, have you listened to your favorite song today? 🎶

Since we created the postgres user before, we can setup the development database using:

bundle exec rails db:setup

This will use the default development configuration to setup the database. Which means: no password, same user as your username, using a database named mastodon_development in localhost.

In development mode the database is setup with an admin account for you to test with. The email address will be admin@YOURDOMAIN (e.g. admin@localhost:3000) and the password will be mastodonadmin.

Now, you have two options.

Run each service separately

If you checked out the guide to run an instance, you probably noticed that mastodon has three parts: A web service, a sidekiq service to run background jobs and a streaming service. In development you need those three components too, plus the webpack development server, which will compile assets (javascript, css) as needed. In production we don’t need webpack running all the time because we compile the assets only once after we update Mastodon.

To run those separately, you will need one window for each, since each of those holds your terminal while it’s running.

To run the web server:

bundle exec puma -C config/puma.rb

To run sidekiq:

bundle exec sidekiq

To run the streaming service:

PORT=4000 yarn run start

And to run webpack:

./bin/webpack-dev-server --listen-host 0.0.0.0

All of those should start immediately, except for the webpack server, which compiles the assets before starting.

To check that everything is working as expected, if you open your browser window at http://localhost:3000 you should see Mastodon landing page!

Run everything using Foreman

Now, most of the time this method is more practical. Running each service by itself is good if one is not starting to see what is the error, but most of the time you’ll want to start everything so that you can start coding away. In which case, first you’ll want to install foreman

gem install foreman

And then, when you need to start your dev environment you can do:

foreman start -f Procfile.dev

Working on master

When working on master, the steps are similar to when updating an instance, but they happen much more frequently since master changes much more frequently.

This means, every time you pull changes into your computer (for instance, when you do git pull origin master), you might need to:

# Update any gems that were changed
bundle install
# Update any node packages that were changed
yarn install --pure-lockfile
# Update the database to the latest version
bin/rails db:migrate RAILS_ENV=development

Now, you don’t need to run them all the time, you will notice if one of them is not working as it should. How?

Bundler complains like this:

Could not find proper version of railties (5.2.0) in any of the sources
Run `bundle install` to install missing gems.

The name of the gem and version will change, but this means that one of your dependencies is not up to date and you need to run bundle install again.

If the database is missing a migration, rails will complain with:

ActiveRecord::PendingMigrationError - Migrations are pending. To resolve this issue, run:

        bin/rails db:migrate RAILS_ENV=development

This will appear on your console, but also on your browser.

If the ruby being used in the project is updated, you will also see some complaints from rvm (in this example, with a hypothetical ruby 2.6.2):

$ cd .
Required ruby-2.6.2 is not installed.
To install do: 'rvm install "ruby-2.6.2"'

In that case we need to do the same as we did to install it the first time, that is:

rvm install 2.6.2

And since rvm manages gems by ruby version, you’ll need to install the dependencies again using bundle install.

Tests

Tests in the mastodon project live in the spec folder. Tests also use migrations, so if the database was updated since you last ran tests, you will need to run something like this:

bin/rails db:migrate RAILS_ENV=test

But when you try to run tests with a database missing migrations, you’ll get an error from Rails that will explain exactly that.

To run all the tests, you need to do:

rspec

To run only one test, you can run it like so:

rspec spec/validators/status_length_validator_spec.rb

Other useful commands

If you add a new string that needs to be translated, you can run

yarn manage:translations

To update the localization files. This is needed so that weblate (opens in a new window ) can inform translators that there are new strings to be translated in other languages.

You can check code quality using

rubocop

Have in mind that it might complain about code violations that you did not introduce, but you should always try not to introduce new violations.

Troubleshooting

RVM says it’s not a function

Follow recommended instructions at https://rvm.io/integration/gnome-terminal (opens in a new window )

Mastodon has no css

If mastodon has no css and you see something like #<Errno::ECONNREFUSED: Failed to open TCP connection to localhost:3035 (Connection refused - connect(2) for "::1" port 3035)> in your console, the issue is where webpacker is trying to connect. You can fix it by changing config/webpacker.yml. Instead of

  dev_server:
    host: localhost

Use

  dev_server:
    host: 127.0.0.1

This was last updated on 31st of January, 2019.

Notes about some choices made in this guide

The official guide recommends rbenv, but I’m more used to rvm. rbenv is likely to be more lightweight. So if you don’t have any preferences, you might want to stick to rbenv and ruby-build when installing ruby.

There’s also choices made regarding firewall. You do not need to follow those exact ones if you already have another firewall on your server or if you want to use a different one. However, do use some firewall. :)

Like the official guide, this guide assumes you’re using Let’s Encrypt for the certificates. If it’s not the case, you can ignore let’s encrypt references and configure your own certificate in Nginx.

Also note that the SSL configurations for nginx are slightly different than the ones in the official guide. They are aimed at being compatible with older android phones and were generated using Mozilla SSL Configuration Generator with the intermediate configuration and HSTS enabled. Have in mind that HSTS disables non-secure traffic and gets cached on the client side, so if you are unsure, generate a new configuration without HSTS.

Questions are super welcome, you can contact me using any of the methods listed in the about page. Also if you notice that something doesn’t seem right, don’t hesitate to hit me up.

I tested this guide using a digital ocean droplet with 1GB memory and 1vCPU. I had to enable swap to be able to compile the assets. There’s more information about this in the relevant section.

Before starting the guide

You need:

• A server running at least a base install of Arch Linux
• Root access
• A domain or sub-domain to use for the instance.

What is assumed:

• There’s no service running in the same ports as Mastodon. If that’s the case, adjustments will need to be made throughout the guide.
• You’re not using root as your base user. You do have a user configured with sudo access.
• You already configured NTP or something similar. Some operations, like 2-Factor Authentication need the correct time on your server.

What you should have by the end of this

You should have an instance running with a basic firewall, a valid https certificate and prepared to be upgraded when needed. All the services needed will be on the same machine. Basic monitoring to know if your instance is up or not.

General suggestions

If you have no experience with Linux systems administrations, it’s a good idea to read a bit about it. You will need to keep this system up to date since it will be facing the internet.

Do not reuse passwords and force public key for your SSH user. Use sudo instead of running everything as root and disable root login over ssh.

The official guide already recommends this, but I’ll go one step further: Always use tmux or screen when doing operations on your server. You will need to learn the basic commands but it’s well worth it to avoid losing things if your connection go down and also for long operations in which you can disconnect and leave it running.

If you have 1GB it’s quite likely that asset compilation will fail. Remember to setup a swap partition or use systemd-swap

DNS

The domain you’re planning to use should have DNS records pointing to your server. If your server has a IPv6 address, you should also configure an AAAA record, otherwise, only the A record should be enough.

Now, this guide will not get into serving a different domain. Just have in mind that:

• The domain will be part of the identifier of your instance users. Once it’s defined, you cannot change it anymore or you’ll get all kinds of federation weirdness.
• Because of that, avoid using “temporary” domains, like the ones coming from ngrok or similar.

Dependencies

• ufw: An easy-to-use firewall
• certbot and certbox-nginx: used for generating the certificates from Let’s Encrypt.
• nginx: Frontend web server that will be used in this setup
• jemalloc: Different memory management library that improves memory usage for this setup.
• postgresql: The SQL database used by Mastodon
• redis: Used by mastodon for in-memory data store
• ffmpeg: Used by mastodon for conversion of GIFs to MP4s.
• imagemagick: Used by mastodon for image related operations
• protobuf: Used by mastodon for language detection
• git: Used for version control.
• python2: Used by gyp, a node tool that builds native addons modules for node.js
• libxslt, libyaml: I don’t know. They were in the official guide so I’m installing them, but I have to say: I do not have they installed in other instances and never noticed an issue 🤷🏽‍♂️

Besides those, it’s a good idea to install the base-devel group. It comes with sudo and other tools which might come in handy.

Now, you can install those with:

sudo pacman -S ufw certbot nginx jemalloc postgresql redis ffmpeg imagemagick protobuf git base-devel python2 libxslt libyaml
sudo pacman -S --asdeps certbot-nginx

Configuring ufw

🛑WARNING: Configuring a firewall is quite important, but if something goes wrong you might lose connectivity to your server. Make sure you have other ways of reaching your server if something goes wrong. 🛑

Now, Mastodon runs a couple of different services and to support it we will be running different services too, but since we will have everything in the same server, the only ports that should be available for the outside world are the HTTP/HTTPS ports that will be used to connect to the instance. Also, we want the SSH port open so that we can connect remotely to the server.

You should read into Arch Linux’s wiki about ufw. For this guide what you want is to do:

sudo ufw allow SSH # this allows SSH traffic to your server
sudo ufw allow WWW # this allows traffic on port 80 to your server
sudo ufw allow "WWW Secure" # this allows traffic on port 443 to your server

And then you can do:

sudo ufw enable
sudo systemctl enable ufw # Enables ufw to be started at startup
sudo systemctl start ufw # starts ufw

And with this the firewall should be up :)

Configuring Nginx

You should read into Arch Linux’s wiki about nginx, but again, what you want to do is something along these lines:

First, you want to edit nginx.conf. To remove the “welcome to nginx” page, you want to change the beginning of your server block to something like this:

    server {
        listen       80 default_server;
        server_name  '';

        return 444;

And at the very end of the http block, add:

    types_hash_max_size 4096; # sets the maximum size of the types hash tables
    include sites-enabled/*; # Includes any configuration located in /etc/nginx/sites-enabled

And then create these two directories:

sudo mkdir /etc/nginx/sites-available # All domain configurations will live here
sudo mkdir /etc/nginx/sites-enabled # The enabled ones will be linked here

Now, let’s say we’re using my.instance.com as the instance domain/sub-domain. You will need to replace this accordingly throughout this next steps.

Create a new file /etc/nginx/sites-available/my.instance.com.conf, replacing my.instance.com by your domain, and then add to it the following content:

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  listen [::]:80;
  server_name my.instance.com;
  root /home/mastodon/live/public;
  # Useful for Let's Encrypt
  location /.well-known/acme-challenge/ { allow all; }
  location / { return 301 https://$host$request_uri; }
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name my.instance.com;

  ssl_certificate     /etc/letsencrypt/live/my.instance.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/my.instance.com/privkey.pem;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:10m;
  ssl_session_tickets off;

  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
  ssl_prefer_server_ciphers on;

  add_header Strict-Transport-Security max-age=15768000;

  ssl_stapling on;
  ssl_stapling_verify on;

  ssl_trusted_certificate /etc/letsencrypt/live/my.instance.com/chain.pem;

  resolver 8.8.8.8 8.8.4.4 valid=300s;
  resolver_timeout 5s;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 8m;

  root /home/mastodon/live/public;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location ~ ^/(emoji|packs|system/accounts/avatars|system/media_attachments/files) {
    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files $uri @proxy;
  }

  location /sw.js {
    add_header Cache-Control "public, max-age=0";
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://127.0.0.1:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

⚠️ It’s a good idea to take a look if something changed in relation to the official guide ⚠️

At this point nginx still doesn’t know about our instance (because we’re including files from /etc/nginx/sites-enabled and we created the file in /etc/nginx/sites-available), however, we should be able to start nginx already.

For that, we need to do:

sudo systemctl start nginx # Starts the nginx service
sudo systemctl enable nginx # Makes the service start automatically at boot

If you do curl -v <your server ip> now, you should see something like this:

$ curl -v <your server's ip>
* Rebuilt URL to: <your server's ip>/
*   Trying <your server's ip>...
* TCP_NODELAY set
* Connected to <your server's ip> (<your server's ip>) port 80 (#0)
> GET / HTTP/1.1
> Host: <your server's ip>
> User-Agent: curl/7.60.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host <your server's ip> left intact
curl: (52) Empty reply from server

And that means nginx was correctly started and that ufw is allowing connections as expected. We will now get our certificates from Let’s Encrypt before jumping back to nginx configuration

Intermission: Configuring Let’s Encrypt

Now, for Let’s Encrypt we will use certbot, that we installed previously. For more information about it you can take a look at Arch Linux’s wiki about Certbot. For this guide, you need to run the following command:

sudo certbot --nginx certonly -d my.instance.com

As usual, remind to change the url to the url for your actual instance. You will need to follow the instructions on screen.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel:

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
-------------------------------------------------------------------------------
(Y)es/(N)o:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for my.instance.com
Using default address 80 for authentication.
2018/07/13 18:28:47 [notice] 4617#4617: signal process started
Waiting for verification...
Cleaning up challenges
2018/07/13 18:28:53 [notice] 4619#4619: signal process started

If everything goes as expected, you should see something like this:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/my.instance.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/my.instance.com/privkey.pem
   Your cert will expire on 2018-10-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"

This means that now we have a valid certificate and that we can go back to nginx. Double check that the path informed by certbot (in this example /etc/letsencrypt/live/my.instance.com/fullchain.pem) matches the one in your nginx file.

Let’s Encrypt certificates only last for 90 days, so we will still come back to this. But for now, let’s go back to nginx.

If you have an error like

Saving debug log to /var/log/letsencrypt/letsencrypt.log
An unexpected error occurred:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 10453: ordinal not in range(128)
Please see the logfiles in /var/log/letsencrypt for more details.

Check that you have set up correctly your locale! If your locale is set to C, certbot will fail.

Finishing off nginx configuration

At this point the certificate should be working. Since this configuration is using HSTS, we also need to generate a dhparam. You can do that by doing (might take a little while!)

openssl dhparam -out dhparam.pem 2048
sudo mv dhparam.pem /etc/ssl/certs/dhparam.pem

What is left for us to do is to enable the instance configuration and reload nginx. We should do this (remember to replace with your instance config!):

sudo ln -s /etc/nginx/sites-available/my.instance.com.conf /etc/nginx/sites-enabled/ # creates a softlink of the configuration we created previously to the enabled sites directory
sudo systemctl reload nginx

Now, if everything went fine, your nginx should reload. Otherwise, it will throw some error like this:

$ sudo systemctl reload nginx
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

In that case, you need to execute one of the commands and try to see what went wrong.

However, if everything went right until now, if you do curl -v my.instance.com replacing for your domain, you should see something like this:

$ curl -v my.instance.com
* Rebuilt URL to: my.instance.com/
*   Trying <your server's ip>...
* TCP_NODELAY set
* Connected to my.instance.com (<your server's ip>) port 80 (#0)
> GET / HTTP/1.1
> Host: my.instance.com
> User-Agent: curl/7.60.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.14.0
< Date: Fri, 13 Jul 2018 18:41:17 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Location: https://my.instance.com/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.14.0</center>
</body>
</html>
* Connection #0 to host my.instance.com left intact

And if you curl or visit the https address you should get a 502 Bad Gateway.

Mastodon user setup

We need to create the Mastodon user:

sudo useradd -m mastodon # create the user

Then, we will start using this user for the following commands:

sudo su - mastodon

First step is that we install rvm that will be used for configuring ruby. For that we’ll follow the instructions at rvm.io. Before doing the following command, visit rvm.io and check which keys need to be added with gpg --keyserver hkp://keys.gnupg.net --recv-keys.

\curl -sSL https://get.rvm.io | bash -s stable

After that, we’ll have rvm. You will see that to use rvm in the same session you need to execute additional commands:

source /home/mastodon/.rvm/scripts/rvm

With rvm installed, we can then install the ruby version that Mastodon uses:

rvm install 2.6.1 -C --with-jemalloc

Note that the -C --with-jemalloc parameter is there so that we use jemalloc instead the standard memory allocation library, since it’s more efficient in Mastodon’s case. Now, this will take some time, drink some water, stretch and come back.

Similarly, we will install nvm for managing which node version we’ll use.

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Refer to nvm github for the latest version.

You will also need to run

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

And add these same lines to ~/.bash_profile

And then to install the node version we’re using:

nvm install 8.11.4

And to install yarn:

npm install -g yarn

And with that we have our mastodon user ready.

Cloning mastodon repository and installing dependencies

For these next instructions we still need to be logged in Mastodon’s user. First, we will clone the repo:

# Return to mastodon user's home directory
cd ~
# Clone the mastodon git repository into ~/live
git clone https://github.com/tootsuite/mastodon.git live

Now, it’s highly recommended to run a stable release. Why? Stable releases are bundles of finished features, if you’re running an instance for day-to-day use, they are the most recommended for being the less likely to have breaking bugs.

The stable release is the latest on tootsuite’s releases without any “rc”. At the time of writing the latest one is v2.7.1. With that in mind, we will do:

# Change directory to ~/live
cd ~/live
# Checkout to the latest stable branch
git checkout v2.7.1

And then, we will install the dependencies of the project:

# Install bundler
gem install bundler
# Use bundler to install the rest of the Ruby dependencies
bundle install -j$(getconf _NPROCESSORS_ONLN) --without development test
# Use yarn to install node.js dependencies
yarn install --pure-lockfile

After this finishes you can go back to the user you were using before. This will also take a while, try to relax a bit, have you listened to your favorite song today? 🎶

PostgreSQL configuration

Now, once more, check out Arch Linux’s wiki about PostgreSQL. The first thing to do is to initialize the database cluster. This is done by doing:

sudo -u postgres initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'

If you want to use a different language, there’s no problem.

After this completes, you can then do

sudo systemctl enable postgresql # will enable postgresql to start together with the system
sudo systemctl start postgresql # will start postgresql

Now that postgresql is running, we can create mastodon’s user in postgresql:

# Launch psql as the postgres user
sudo -u postgres psql

In the prompt that opens, create the mastodon user with:

-- Creates mastodon user with CREATEDB permission level
CREATE USER mastodon CREATEDB;

Okay, after this we’re done with postgresql. Let’s move on!

Redis configuration

The last service we need to start is redis. Check out Arch Linux’s wiki about Redis.

We need to start redis and enable it on initialization:

sudo systemctl enable redis
sudo systemctl start redis

Mastodon application configuration

We’re approaching the end, I promise!

We need to go back to Mastodon user:

sudo su - mastodon

Then we change to the live directory and run the setup wizard:

cd ~/live
RAILS_ENV=production bundle exec rake mastodon:setup

This will do the instance setup: ask you about some options, generate needed secrets, setup the database and precompile the assets.

For PostgreSQL host, port and etc, you can just press enter and it will use default values. The same goes for redis. For email options, refer to the email section. You will want to allow the setup to prepare the database and compile the assets.

Precompiling the assets will take a little while! Also, pay attention to the output. It might output:

That failed! Maybe you need swap space?

All done! You can now power on the Mastodon server 🐘

Which means the asset compilation failed and you will need to try again with more memory. You can try again using RAILS_ENV=production bundle exec rails assets:precompile

Intermission: Mastodon directory permissions

The mastodon user folder cannot be accessed by nginx. The path /home/mastodon/live/public needs to be accessed by nginx because it’s where images and css are served from.

You have some options, the one I chose for this guide is:

sudo chmod 751 /home/mastodon/ # Makes mastodon home folder executable by all users in the server and readable and executable by the user group
sudo chmod 755 /home/mastodon/live/public # Makes mastodon public folder readable and executable by all users in the server
sudo chmod 640 /home/mastodon/live/.env.production # Gives read access only to the user/group for the file with production secrets

Other subfolders will also be readable by other users if they know what to search for.

Mastodon systemd service files

Now, you can go back to your user and we’ll create service files for Mastodon. You again should compare with the official guide to see if something changed, but have in mind that since we’re using rvm and nvm in this guide the final result will be a bit different.

This is what our services will look like, first the one in /etc/systemd/system/mastodon-web.service, responsible for Mastodon’s frontend and API:

[Unit]
Description=mastodon-web
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="RAILS_ENV=production"
Environment="PORT=3000"
Environment="WEB_CONCURRENCY=3"
ExecStart=/bin/bash -lc "bundle exec puma -C config/puma.rb"
ExecReload=/bin/kill -SIGUSR1 $MAINPID
TimeoutSec=15
Restart=always

[Install]
WantedBy=multi-user.target

Then, the one in /etc/systemd/system/mastodon-sidekiq.service, responsible for running background jobs:

[Unit]
Description=mastodon-sidekiq
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=5"
ExecStart=/bin/bash -lc "bundle exec sidekiq -c 5 -q default -q push -q mailers -q pull"
TimeoutSec=15
Restart=always

[Install]
WantedBy=multi-user.target

Lastly, the one in /etc/systemd/system/mastodon-streaming.service, responsible for sending new content to users in real time:

[Unit]
Description=mastodon-streaming
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="NODE_ENV=production"
Environment="PORT=4000"
ExecStart=/bin/bash -lc "npm run start"
TimeoutSec=15
Restart=always

[Install]
WantedBy=multi-user.target

Now, you can enable these services using:

sudo systemctl enable /etc/systemd/system/mastodon-*.service

And then run them using

sudo systemctl start mastodon-*.service

Check that they are running as they should using:

systemctl status mastodon-*.service

At this point, if everything is as it should, going to https://my.instance.com should give you the Mastodon landing page! 🐘

Emails

Now, you’ll probably want to send emails, since new users get an email to confirm their emails.

You should really follow the official guide on this one, because there’s no difference in this case.

Monitoring with uptime robot

I’m giving an example with Uptime Robot because they have a free tier, but you can use other services if you prefer. The idea is just to be pinged if your instance goes down and also to have an independent page where your users can be sure if everything is working as expected.

After creating an UptimeRobot account, you can create a HTTP(s) type monitor pointing to your instance full url: https://my.instance.com, don’t forget to change accordingly.

If you have IPv6, you should also create another monitor with the Ping type, in which you should use your server’s IPv6 as the IP.

Now, in the settings page, you can click on “add public status page”, then you select “for selected monitors” and select the ones you just created. You can create a CNAME DNS entry, so that for instance status.my.instance.com would show the this new status page. There’s more instructions in Uptime Robot’s page.

Now if your instance goes down or your IPv6 stops working, you should get an email.

Remote media attachment cache cleanup

Mastodon downloads media from other instances and caches them locally. If you don’t clean this from time to time, this will only keep growing. Using mastodon user, you can add a cron job that cleans it up daily using crontab -e and adding:

0 2 * * * /bin/bash -lc "cd live; RAILS_ENV=production bundle exec bin/tootctl media remove" 2>&1 /home/mastodon/remove_media.output

If you don’t have any cron installed in your server, you need to take a look in Arch Linux’s wiki page about cron.

Renew Let’s Encrypt certificates

The best way for this is to follow Arch Linux’s wiki about Certbot automatic renewal, which is:

Create a file /etc/systemd/system/certbot.service:

[Unit]
Description=Let's Encrypt renewal

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --agree-tos

The nginx plugin should take care of making sure the server is reloaded automatically after renewal.

Then, create a second file /etc/systemd/system/certbot.timer:

[Unit]
Description=Daily renewal of Let's Encrypt's certificates

[Timer]
OnCalendar=03:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Now, enable and start the timer service:

sudo systemctl start certbot.timer
sudo systemctl enable certbot.timer

Updating between Mastodon versions

Okay, you set it all up, everything is running and then Mastodon v2.8.0 comes out. What do you do?

Do not despair, dear reader, all is well.

Remember our tip about tmux? When updating is always a good idea to be running tmux. Database migrations can take some time and tmux will help to avoid losing data if your connection fails in the meantime.

First, we will go to the Mastodon user once again:

sudo su - mastodon

Okay, first things first, let’s go into the live directory and get the new version:

cd ~/live
git fetch origin --tags
git checkout v2.8.0
cd . # This is to force rvm to check if we're in the right ruby version

Now, suppose the ruby version changed, since the last time you were here and instead of 2.6.1 is now 2.6.2. After you do cd ., rvm will complain:

$ cd .
Required ruby-2.6.2 is not installed.
To install do: 'rvm install "ruby-2.6.2"'

In this case, we will need to use rvm to install the new version. The command is the same as last time:

rvm install 2.6.2 -C --with-jemalloc

Everything will take some time and at the end you will be ready to follow through. Notice that this won’t happen very often. Also, after you make sure everything is running as expected, you can remove the old ruby version with rvm remove <version>. Wait for you to be sure that the new version is running, though!

Now, you’ll always want to make sure that you look at the releases notes for the release you’re going to. Sometimes there’s special tasks that need to be done before following.

If there was dependencies updated, you need to do:

bundle install --without development test # if you need to update ruby dependencies or if you installed a new ruby
yarn install --pure-lockfile # if you need to update node dependencies

In most of the updates you will need to update the assets:

RAILS_ENV=production bundle exec rails assets:precompile

For comparison: in the digital ocean droplet I tested this guide on, compiling assets on v2.4.3 took around 5 minutes.

If the update includes database migrations that you’ll need to do:

RAILS_ENV=production bundle exec rails db:migrate

Sometimes database migrations will change the database in a way that the instance will stop working for a little bit until you restart the services, that’s why I usually leave them for last to reduce downtime.

⚠️ Backup your database regularly ⚠️

After the migration is finished running, you can leave the mastodon user and then restart the services:

sudo systemctl restart mastodon-sidekiq
sudo systemctl restart mastodon-streaming
sudo systemctl reload mastodon-web

Now, if there was some database changes you need to restart mastodon-web instead of reload.

Alrite, you should be in the last version of Mastodon now!

Upgrading Arch Linux

Some special notes about upgrading Arch Linux itself. If you haven’t yet, read through the Arch Linux’s wiki on Upgrading the system. Since Arch Linux is rolling, there’s some differences if you’re coming from other distros.

Ruby uses native modules in some of the gems, that is, modules compiled against local libraries. This means that if your system changes radically from one version to the other, you might have issues starting services.

However, to make your life a bit easier, you can re-compile native modules by doing (using mastodon user):

cd ~/live
bundle pristine

This will take a little while but will recompile needed gems. When in doubt, do that after a system upgrade.

I had issues in the past with gems that Mastodon uses which have native extensions and are being installed straight from git, namely posix-spawn and http_parser.rb. They were not reinstalled with bundle pristine and I had to manually rebuild them. This seems to fixed in the most recent rvm, but in case you need to do that, find where they are installed doing:

bundle show posix-spawn

With the output of that (which will be something like /home/mastodon/.rvm/gems/ruby-2.5.1/bundler/gems/posix-spawn-58465d2e2139, do:

rm -rf /home/mastodon/.rvm/gems/ruby-2.5.1/bundler/gems/posix-spawn-58465d2e2139 /home/mastodon/.rvm/gems/ruby-2.5.1/bundler/gems/extensions/x86_64-linux/2.5.0/posix-spawn-58465d2e2139

This is just an example and you will have to replace this with the output of your bundle show command, and then find the equivalent path in the gems/extensions folder. Do it for both posix-spawn and http_parser.rb (and any other gem that comes from git if it gives you trouble).

And after that you can do bundle install --without development test to install them again.

Now, second thing to take note: Postgresql minor version are compatible between themselves. This means that 9.6.8 is compatible with 9.6.9 and after version 10 they adopted a two number versioning, which means that 10.3 is compatible with 10.4. However, 9.6 is not compatible with 10. And 10 will not be compatible with 11. This means that: when upgrading from 10 to 11 you need to follow the official documentation and Arch Linux’s wiki orientation. With that in mind, be careful when upgrading.

🛑 Upgrading wrongly may cause data loss. 🛑

(Optional) Adding elasticsearch for searching authorized statuses

Since Mastodon v2.3.0, you can enable full text search for authorized statuses. That means toots you have written, boosted, favourited or were mentioned in. For this functionality, Mastodon uses Elasticsearch. As usual, you should take a look in Arch Linux’s wiki about Elasticsearch.

Note: I was able to run elasticsearch on my test instance using the 1GB/1vCPU droplet from Digital Ocean with 1GB of Swap by using the memory configurations suggested at the Arch Linux’s wiki about Elasticsearch, that is, -Xms128m -Xmx512m. However, I don’t have any load and I don’t know how the system would behave with more real loads.

To install elasticsearch do:

sudo pacman -S elasticsearch

Pacman then will ask which version of jdk you want to use. After installed, you can start Elasticsearch by doing:

sudo systemctl enable elasticsearch # Enables elasticsearch to be started at startup
sudo systemctl start elasticsearch # starts elasticsearch

Then you need to switch to Mastodon user, cd ~/live and edit .env.production, to add configuration related to Elasticsearch, look for the commented configs and change them:

ES_ENABLED=true
ES_HOST=localhost
ES_PORT=9200

Then, you need to build the index. This might take a while if your database is big!

RAILS_ENV=production bundle exec rails chewy:deploy

When this is finished, you need to restart all mastodon services.

The official docs have some tips on how to tune Elasticsearch.

(atualizado pela última vez em 4 de dezembro de 2018)

Talvez você tenha ouvido falar do Mastodon, há alguns meses atrás a rede social bombou na mídia internacional como a rede que veio pra sacudir o Twitter. Mas talvez não, porque a cobertura na mídia nacional foi bem pequena. Ainda assim, a rede está chegando na versão 2.7 e está chegando aos 1.7 milhão de usuários, além de mais de 2400 servidores ativos.

O Mastodon é uma rede social de microblogging, semelhante ao Twitter. A sua proposta é ser local onde os seus usuários podem postar status de até 500 caracteres. Até aí, tudo bem igual ao Twitter.

A diferença começa no modelo da rede, que é mais semelhante ao serviço de email, com vários servidores que se comunicam, do que ao modelo do twitter de um grande servidor com todo mundo dentro.

Começando pela parte difícil: como funcionam os servidores?

O Mastodon é composto por vários servidores. Tem o mastodon.social (abre em uma nova janela ), que é mantido pelo líder do projeto, o Eugen Rochko (abre em uma nova janela ). Ou mesmo o Mastodon(te) (abre em uma nova janela ), mantido por mim mesmo. Os dois estão em lugares diferentes, controlados por pessoas diferentes, mas ainda assim, eles falam entre si. Se eu quero mandar uma mensagem pro Eugen, basta eu mandar uma mensagem pra @gargron@mastodon.social e ele vai receber ela por lá e se ele quiser me responder ele vai responder pra @renatolond@masto.donte.com.br e eu vou receber ela de cá. Ou seja, em vez de ser só uma arroba, você é uma arroba em um endereço, que nem email.

Assim como no Twitter no início dos tempos, é possível acompanhar uma timeline especial, a timeline local, que tem todos os toots…

Peraí. Eu num disse isso, né? Quando alguém posta uma coisa no Mastodon isso se chama um toot, se pronuncia “Tut”.

Então, como eu ia dizendo, é possível acompanhar uma timeline especial onde tem todos os toots públicos dos usuários do seu servidor. É uma maneira bem legal de descobrir gente e conteúdo novo.

E aí, tem a timeline global (também chamada de federada) que é onde estão os toots de todos os usuários que são vistos pela servidor onde você está. Pode ser meio confuso, porque tem gente do mundo todo postando. Tem umas ferramentas pra filtrar línguas nas timelines local e global pra ajudar um pouco nesse sentido.

Pô, mas aí só me complicou. Qual a vantagem?

A vantagem é que cada servidor é administrado por gente diferente. Você com certeza pode achar um servidor onde você vai estar livre de conteúdo que você não quer ver e ver mais do que você quer. Tá querendo um servidor feito para brasileiros? Tem lá (abre em uma nova janela ). Quer um servidor mais voltado pro público LGBTQ? Tem lá (abre em uma nova janela ). Ou de repente cê tá procurando um servidor mais voltado pro público interessado em livros e também tem lá (abre em uma nova janela ). E se quiser derrubar o capitalismo e falar de gatinhos, também tem um cantinho (abre em uma nova janela ).

O que você vê na timeline local vai variar bastante de servidor pra servidor. O que você vê na global vai variar porque servidores podem bloquear conteúdo de outros servidores. Então se você está num servidor que não permite nazismo, fascismo e afins, você provavelmente não vai ver conteúdo desse tipo na sua timeline (e se aparecer, você pode reportar aos administradores e eles provavelmente vão bloquear).

E no final das contas, todo mundo com conhecimento técnico ou um pouco de dinheiro pode botar um servidor novo no ar. Então se você quer fazer um servidor pra fãs do campeonato brasileiro, você também pode. (Tô jogando no ar. Acho que ainda não tem, hein. Corre lá :)

Ah, mas é tipo reddit então?

Não muito, o reddit tem vários fóruns, mas todos são desconectados. No Mastodon você pode seguir gente de todos os servidores, a diferença é só que gente que está no mesmo servidor que você é mais fácil de acompanhar. Alguns servidores até são temáticos (pra agregar gente falando de desenvolvimento de jogos ou de tecnologia), mas não é necessariamente o caso em todos os servidores. Na maioria das vezes o tema do servidor vai ajudar só a juntar gente que pensa do mesmo jeito, mas muitas vezes o servidor existe porque tem um nome de domínio maneiro.

Tá, e como eu escolho meu servidor, então?

Tem um site que tem um pequeno questionário pra te ajudar justamente nessa questão, o Mastodon Instances (abre em uma nova janela ).

Uma coisa importante do servidor é que a administração e moderação é por servidor. Então o quão rígida ou não vai ser a moderação vai depender do servidor que você escolher. É importante dar uma lida nas regras do servidor pra não ser pego de surpresa ao violar uma delas!

Outra coisa importante é que por não ter uma grande empresa por trás de cada instância, é bom dar uma conferida em quanto tempo o servidor está no ar e se ele não costuma sair do ar com frequência, dá pra ter uma idéia usando o fediverse network (abre em uma nova janela ), que mostra um gráfico de disponibilidade dos últimos 30 dias. O site também mostra quando a instância foi descoberta, mas o serviço começou a funcionar no fim de abril/2018, então tem instância que tá listada por volta dessa data mas já existia antes.

Não se preocupe de escolher o melhor servidor logo de cara. Você pode exportar seus dados e ir pra um outro servidor se você não curtir alguma coisa do servidor em que você está.

Toots e tweets

No Twitter ou o seu perfil é fechado e aí ninguém vê seus tweets, ou ele é aberto e todo mundo vê seus tweets. No mastodon tem um controle mais fino disso. Você pode ter uma conta fechada e ainda postar toots pra todo mundo ver, quando quiser.

Além disso, no Mastodon tudo vem sempre em ordem cronológica, e nenhum like dos amiguinhos aparece no meio da sua timeline. Você escolhe o que você quer ver, e ninguém vê os posts que você curte, seus favoritos são sempre privados.

Olha as diferenças entre os toots, no mastodon, e os tweets:

• Os toots podem ter até 500 caracteres⁽¹⁾;
• Os toots têm configurações de privacidade:
  • Você pode postar publicamente (ou seja, todo mundo vê seu toot e ele aparece nas timelines local e global)
  • Você pode postar não listado (ou seja, todo mundo pode ver seu toot, mas ele não aparece nas timelines local e global)
  • Você pode postar privado (e nesse caso seu toot só aparece pra quem te segue)
  • Você pode postar um toot diretamente pra alguns usuários, e nesse caso é parecido com uma mensagem, só os usuários que você citar vão ver.
• Spoiler / alerta de conteúdo: Isso é mara. Você pode marcar enquanto for postar um aviso de conteúdo pra um toot. Aí aparece assim:

  

Emojis

Desde a versão 2.0 tem uma parada que eu acho particularmente bem legal: emojis customizados!

Além dos emojis normais que você acha no seu telefone, os administradores das instâncias podem adicionar outros emojis.

Apagar & usar como rascunho

Imagina que você acabou de fazer aquele toot maneiro e assim que ele foi postado, você notou um erro. Não dá pra editar toots, mas dá pra clicar em “apagar & usar como rascunho”. Isso apaga o toot e manda ele de volta pra caixa de edição junto com as mídas que estavam nele pra você poder corrigir e postar outra vez.

Eu uso isso um monte pra adicionar descrição de texto nas imagens, por exemplo. É super prático!

Isso existe em alguns clientes do Twitter também, mas no Mastodon tem direto pela interface padrão.

Aplicativos

Sim, tem aplicativos pra Android, pra IOS, pra desktop e até mesmo pra uns certos editores de texto 😉

Por exemplo, pra Android os mais comuns são o Tusky (abre em uma nova janela ), Twidere (abre em uma nova janela ) (que funciona tanto pro Mastodon quanto pro Twitter), Mastalab (abre em uma nova janela ), Subway Tooter (abre em uma nova janela ) e 11t (abre em uma nova janela ).

Pra iOS o Toot! (abre em uma nova janela ), Amaroq (abre em uma nova janela ) e iMast (abre em uma nova janela ).

Além disso, ambos Android e iOS recentemente suportam PWAs (abre em uma nova janela ) e por isso você pode usar o próprio site da sua instância como um app no seu celular.

Pra outros sistemas e uma lista mais atualizada, dá pra dar uma olhada nessa lista aqui que é mantida pelo projeto: aplicativos (abre em uma nova janela ).

Como o Mastodon é open-source, a maioria dos seus aplicativos também é. Então você pode dar uma procurada até encontrar um app que te faça se sentir mais em casa.

Ferramentas

Mudar de rede social é um negócio complicado e é por isso que tem ferramentas pra tentar ajudar um pouco na transição.

Mastodon Bridge (a ponte) (abre em uma nova janela ): Criado pelo próprio Eugen Rochko (abre em uma nova janela ), a ponte serve pra descobrir amigos do Twitter no Mastodon e vice-versa. Depois de criar sua conta em um dos servidores, basta ir lá e conectar a sua conta do Twitter e do Mastodon. Aí ele vai mostrar onde você pode seguir seus amigos do Twitter.

Mastodon Twitter Crossposter (postando entre as redes) (abre em uma nova janela ): Essa aí é minha. Você conecta suas contas do Twitter e do Mastodon e aí você pode decidir como você quer postar entre as redes. Do Twitter pro Mastodon, ou do Mastodon pro Twitter, que tipo de posts vão ser postados. É open-source e tem coisa pra fazer, se quiser contribuir.

Segurança de dados

Quando você se inscreve em um servidor do Mastodon (vamos dizer, no masto.donte.com.br (abre em uma nova janela )), seus dados ficam registrados no masto.donte.com.br. O administrador do servidor pode ver suas mensagens, assim como o Gmail também pode ver suas mensagens. O Mastodon por padrão não permite que administradores vejam messagens marcadas como privadas, mas através de denúncias ou olhando o conteúdo do banco de dados, mesmo as mensagens privadas podem ser visualizadas.

Quando alguém de outro servidor (digamos, do mastodon.social (abre em uma nova janela )) te segue ou se você enviar uma mensagem pra um usuário que esteja por lá, os seus posts são enviados também para esse outro servidor e uma cópia desses posts vai ser guardada lá.

Isso quer dizer que administradores de servidores em que você tenha seguidores ou pra quem você envia mensagens podem espiar as mensagens. É exatamente o mesmo caso de servidores de email, se você enviar uma mensagem pra alguém no servidor do trabalho dessa pessoa, a empresa poderia ver as mensagens.

Na prática é tão (in)seguro quanto outras redes sociais.

Mais informações

A página do projeto é um bom ponto pra começar: The Mastodon Project (abre em uma nova janela ). Tem tradução em português por lá. Aliás, falando em tradução: tanto a página do projeto quanto a interface do Mastodon em si foram traduzidas pro português Brasileiro pela Anna (abre em uma nova janela ) 🎉

Tem muito mais informação, muito mais detalhada, no repositório de dosumentação do projeto (abre em uma nova janela ), mas a maioria das coisas ainda não está traduzida pra português ou português do Brasil. (Tá aí uma oportunidade, ó.)

Um pouco mais velho mas igualmente útil é o texto da Qina Liu: What I wish I knew before joining Mastodon (abre em uma nova janela ). Embora esteja desatualizado em alguns pontos, ainda é bem divertido e foi o que me inspirou a escrever esse aqui :)

Um outro também que explica bem vários pontos que eu tento explicar por aqui é o texto da Ginny McQueen: Toot How-To : Intro to Mastodon (abre em uma nova janela ).

Sabe tudo que eu falei sobre instâncias diferentes do Mastodon? O Mastodon na verdade está no Fediverso, e ele não é o único software por lá. Dá uma olhada em mais informações sobre o Fediverso por aqui (abre em uma nova janela ).

[1]: Vale notar que por padrão os toots têm 500 caracteres. Na prática alguns servidores permitem mais, no finado witches.town (abre em uma nova janela ), por exemplo, o limite era de 666 caracteres. 😜

E tem mais um ponto: eu sou a favor dos taxis serem agenciados pelo estado. Acho que taxi, como um transporte público que integra a malha de transportes do estado, também tem que ter suas concessões como parte do planejamento do estado de alguma maneira.

E aí eu andei pensando, e se a gente tivesse a união entre as duas coisas? Senta que lá vem viagem.

Imagina uma mistura entre Uber e EasyTaxi de código aberto. Esse software, que teria seu código disponível pra ser auditado por qualquer um, faria esse papel de controlar a frota e também teria aplicativos para as plataformas de modo que fosse possível chamar taxis por dentro dele, além de efetuar pagamentos também por dentro do aplicativo.

O ideal seria o software ser gerenciado (em termos de custos de manutenção pra manter tudo funcionando) em um esquema de cooperativa entre os taxistas participantes (ou ainda, aproveitando o que já existe, seria coordenado pelo sindicato dos taxistas de cada lugar).

Os custos do sistema seriam um custo fixo para o taxista (que seria pelo custo da infraestrutura) e um custo que viria do gateway de pagamento sendo escolhido pelo sindicato que estivesse mantendo aquela “versão” do aplicativo. Todo o dinheiro da corrida, tirando o custo do pagamento, iria para o bolso do taxista.

Para melhorar, o ideal seria que tivesse alguma maneira (boletos, cartões pré-pagos?) para que quem não tivesse cartão de crédito também pudesse pagar pelo aplicativo.

Todos os dados do sistema estariam disponíveis para serem auditados publicamente, tanto pelo estado, quanto pelos usuários. O estado fica mais eficiente sabendo quanto os taxistas estão ficando ociosos e a duração das suas corridas, e o usuário pode ficar mais em cima de problemas acontecendo nos taxis.

Ao fim de cada corrida, o usuário avaliaria o taxista e no caso de uma nota abaixo da média, informaria os problemas que seriam acumulados no perfil do taxista para uma auditoria posterior.

Claro que tem alguns problemas a serem resolvidos nessa idéia: será que ser gerenciado por cada cooperativa é uma coisa eficiente? Ou será que era melhor fazer uma fundação (tipo a Free Software Foundation) que ficasse responsável pela implementação e manutenção do sistema?

Acho que seria um caminho melhor e mais próximo do que eu acho ideal, mais próximo da socialização do uber. [Socialize Uber]

Uma introdução

No ensino médio conheci um amigo que guardava planilhas com os jogos que ele tinha, os que ele já tinha terminado e os que tinha emprestado.

Nessa época comecei a guardar os meus em uma também, mas em 2003 planilhas eram coisas muito etéreas, quando formatar seu SO (win.. cof.. dows.. cof.. cof..) eram coisas rotineiras, era fácil perder uma por descuido. E várias vezes perdi o conteúdo delas.

Comecei a ler mais portais de jogos e acabei desenvolvendo alguns métodos, ainda que primitivos, de guardar que jogos eu tinha jogado, quais eu queria em alguns desses, principalmente o gamespot.

A internet evoluiu desde então, e com isso, alguns novos serviços apareceram. Conheci sites e tracking de outras coisas: livros, filmes, seriados, cerveja, vinho, lugares. Usei todos os sistemas de tracking de jogos que eu conheci pelo caminho: Raptr, PlayFire, Backloggery, HowLongToBeat, Alvanista, EstouJogando. Nenhum deles me deixou muito feliz, até que recentemente eu voltei a usar planilhas (dessa vez, do Google Drive) pra manter meus jogos e quando eu os terminei.

Conhecendo o Goodreads

Em 2012 conheci o Goodreads. Na época, usava o skoob pra guardar os livros que eu lia. Achei o sistema incrível, diversas edições, suporte a várias línguas, ratings unificados. Era tudo que eu queria pra um site de jogos.

A difícil criação do Internet Video Game Library

O IVGLib ficou em gestação algumas vezes. A primeira vez tentei usar o Google App Engine para fazer, mas java nunca foi minha praia e eu entrei no barco durante os meses que seguiram uma atualização major na plataforma. Na época, o projeto tinha o codinome SEMAG. E com isso ele ficou de lado.

Um tempo depois, resolvi tentar retomar o projeto, dessa vez usando algum framework de PHP. Li sobre alguns, tentei usar o FuelPHP, e mais uma vez a falta de documentação, algumas frustrações pra fazer coisas que eu achava que eram básicas acabaram me fazendo mais uma vez largar o projeto de lado.

Do meio do ano passado pra cá eu vinha tentando aprender Ruby on Rails, fazendo homeopaticamente o tutorial do ruby.railstutorial.org e a parada foi fluindo. Em janeiro, durante as minhas férias, finalmente recomecei o projeto, dessa vez em Rails.

Desenvolvimento e tecnologias

Rails é um negócio incrível, você pensa em fazer uma parada e tem uma Gem pra fazer isso. (o que também é verdade pra muitas linguagens mais novas, antes que me joguem pedras).

Assim que comecei a fazer o sistema e me animei, registrei o domínio (um monte deles, na verdade), defini um MVP e saí fazendo a parada. Passei parte das minhas férias de janeiro debruçado sobre o PC fazendo o início do sistema.

Atualmente, o sistema tá uma sopa de nomes de serviços e aplicações: Tô hospedando o código no Heroku, com a busca usando o ElasticSearch através do SearchBox, usando coisas do Amazon AWS pra armazenamento de imagens e etc.

É muito doido ficar nessa de DevOps, nunca tinha ficado nessa posição antes e tá sendo uma experiência bem curiosa.

Apesar disso, meu MVP tá lá. Mil e umas funcionalidades legais pra implementar nos próximos dias. Diversos jogos pra cadastrar. Enfim, muito trabalho.

Nos próximos dias vai ser tempo de esmagar bugs antes de voltar pro roadmap e implementar os próximos passos. Parece que vai ser um longo e interessante caminho :)

Recentemente o Lulu foi o assunto mais falado de toda a internet. Vários textos foram escritos sobre o app e eu não vou aqui falar sobre o aplicativo em si, mas se você quer ler mais sobre ele, aqui vão ótimos textos pra você:

“Lulu”, machismo invertido? por Marília Moschklovich

Clube da Lulu e a objetificação masculina por Olga

Mas o meu ponto mesmo é sobre privacidade, e aí a gente entra em outro rabbit hole.

Toda vez que converso com pessoas que não tem um background de computação, elas parecem não fazer idéia quanto privacidade é cada vez menos o conceito que se imagina. A privacidade, como as pessoas entendiam há alguns anos atrás, existe menos a cada dia. Cada vez que você escreve um novo post no seu facebook, ou faz uma nova pesquisa no google, mesmo que não esteja realmente associado a você, esses dados criam uma identidade virtual que já tem todas as informações relevantes. Por isso “anúncios relevantes”, por isso quando você busca por um produto que te interessa o facebook mostra sobre aquilo na sua timeline, o google mostra aquilo nos ads que aparecem pra você nas páginas.

A Target, loja americana de varejo, tem um cartão fidelidade que dá diversos descontos. A partir dos dados desse cartão de fidelidade, ela consegue prever quando as suas clientes estão grávidas e quanto tempo aproximadamente falta para elas terem o bebê e com essas informações oferecem cupons de desconto direcionados. [1]

Em outro artigo, entrevistaram especialistas em segurança sobre o que deveria ser feito para ficar anônimo no mundo moderno e as respostas são assustadoras[2]. Dentre elas, um cara descobriu que o dispositivo que ele usa pra passar em pedágios sem pagar (como aqueles usados por aqui na Linha Amarela e em shoppings) também era usado pra rastrear por onde o carro dele passava. Supostamente essa informação é usada para obter informações sobre como está o trânsito na cidade, a partir da massa de dados dos diversos carros que usam o dispositivo. Mas qualquer um que tenha acesso a essa banco de dados também pode saber por onde você anda e quando.

Quando entramos na discussão sobre Facebook, Google Plus, Twitter e diversas outras redes sociais, batemos em vários problemas. Dentre eles, a “censura” de conteúdo. Embora o conteúdo na maioria das redes sociais não seja de fato censurado, o Facebook muda o modo como você se relaciona com as coisas compartilhadas pelos seus amigos escondendo os posts que seus algoritmos julgam apropriados. É fácil de notar isso: escolha um amigo da sua timeline com quem você tenha pouco contato (aquele seu amigo de colégio que você adicionou mas nunca trocou uma mensagem) e você vai ver que nem todos os posts dele apareceram pra você. E mesmo os que aparecem, aparecem numa ordem escolhida pelos algoritmos do Facebook, baseado no que ele acha que é o mais relevante para você. Isso é especialmente notável no caso das páginas que podem ser criados para negócios, pessoas públicas, bandas e etc. Nesse caso, os algoritmos dão ainda mais prioridades para posts pagos, e os que não são pagos muitas vezes não são entregues pra boa parte da audiência. Há diversos posts apontando sobre como possívelmente posts não pagos perdem audiência para posts pagos. [4]

O Google Reader, extinto pelo Google recentemente, usava o protocolo de RSS e Atom, que são dois protocolos abertos de divulgação de conteúdo. Nesse tipo de serviço (hoje em dia disponível através do The Old Reader, Feedly, Digg Reader, etc) TODO o conteúdo compartilhado por um feed que o usuário siga é entregue para o usuário e essa seleção é feita pelo receptor, não pelo serviço que entrega os feeds. Assim, um blog, como este, pode entregar todo o seu conteúdo e o filtro é o próprio usuário e não algoritmos especializados.

Ainda sobre as redes sociais, temos os seus termos de uso e privacidade sempre complicados e com vários poréns. No caso do Lulu (e qualquer outro aplicativo do facebook, na verdade), o catch é que segundo o facebook, sua foto de perfil e seu nome são informações públicas [3], ou seja, quando um amigo seu se inscreve um aplicativo e entrega as informações sobre a rede de amigos que ele possui, a sua foto e o seu nome vão para esse aplicativo, sem a sua permissão, porque você já deu permissão para que isso acontecesse quando criou a sua conta.

O problema é enorme, e há ramificações para todo lado. Um bom ponto de partida sobre o assunto é ler sobre Neutralidade da Rede [5]. Outro ponto de partida é ler sobre como o facebook trata os seus dados, mesmo quando deletados [6]. Por fim, há um artigo sobre vigilância e controle de conteúdo no Capitalismo em Desencanto que fala sobre esses e outros pontos, com ótimos links[7].

Da próxima vez que for compartilhar um dado no facebook, pense duas vezes se aquele dado realmente é público. Porque mesmo quando você não compartilhar ele com o mundo, alguém que você não conhece pode estar vendo ele do outro lado.

[1] – How Target Figured Out A Teen Girl Was Pregnant Before Her Father Did (artigo em inglês)

[2] – Think You Can Live Offline Without Being Tracked? Here’s What It Takes (artigo em inglês)

[3] – Política de uso de dados do Facebook
[4] – Disruptions: As User Interaction on Facebook Drops, Sharing Comes at a Cost (artigo em inglês)

[5] – Neutralidade da Rede
[6] – Think Your Deleted Facebook Posts Are Really Deleted? Guess Again (artigo em inglês)

[7] – Vigilância e controle de conteúdo na internet

A idéia é bem simples, um relógio com uma bateria recarregável que dura até sete dias, que é programável (ou seja, você pode mostrar a hora de diversas formas, na foto aí de cima já tem duas), se liga por bluetooth com seu celular e pode receber notificações de qualquer aplicativo, além de ter acelerômetro e tudo mais que um geek pode querer.

O relógio me ganhou na parte em que ele poderia fazer uma ponte com o RunKeeper e virar uma espécie de Garmin mais versátil.

E aí fica a pergunta, ele entrega o que promete? Ele é mesmo tudo isso? Vamos por partes

O tempo de entrega

A internet não é paciente. A internet não é razoável. O tempo estimado de entrega dos relógios era setembro de 2012. Mas claro, sendo um produto completamente novo, sendo feito em larga escala, por uma equipe que não parece ser enorme e tendo que trabalhar entre estados unidos e china não é uma tarefa fácil. Os caras tentaram ser transparentes: 33 updates no kickstarter desde abril de 2012 até agora, em março de 2013. Mas é complicado, problemas acontecem em qualquer entrega de produto, especialmente em um físico.

No geral, eu achei que eles se esforçaram pra cumprir o prazo, e não fiquei decepcionado com o tempo. Especialmente levando em consideração o produto final. O problema é as pessoas não estarem acostumadas com um modelo tipo Kickstarter, na minha opinião. Onde as coisas podem dar errado e podem atrasar.

O relógio

Peguei meu pebble hoje pela manhã. Provavelmente esse post não vai ser lançado no dia que eu peguei, até pra ter uma impressão maior sobre o tempo de bateria e tudo o mais. Mas desde então, já mudei uma coisa na minha vida: não tem mais vibração ou som no meu celular. É muito mais prático a vibração do relógio, e ver as notificações é bem tranquilo. A coisa não é bem out-of-the-box, mas instalando um appzinho auxiliar, o Pebble Notifier, fica bem tranquilo e as coisas funcionam bem, dando pra ver inclusive várias mensagens de whatsapp de uma vez só. (mas não dá pra ver aquele longo tópico de 23 messagens do grupo da galere, isso não dá.)

Uma parte meio ruim é que a tela é um imã de digital, mas como ela não é touch, não era pra você tocar nela anyway. Mas é inevitável, e em poucas horas, dava pra ver a tela meio sujinha. Nada que passar ele na camisa não resolva.

A caixa

Peraí, a caixa? É, a caixa merece ser mostrada, porque ela é tão bonitinha :)

</figure>

A bateria

A bateria agrada no sentido de que tem durado basicamente o que foi prometido, entre cinco e sete dias. Tive que carregar ele algumas vezes desde que chegou, mas a duração é bem agradável e a notificação de bateria baixa aparece em tempo suficiente pra você ainda aguentar um dia inteiro com ele (da última vez assim que cheguei no trabalho a notificação de bateria baixa apareceu e só fui carregá-lo ao chegar em casa, de noite).

A única vez que ele durou pouco tempo foi durante o Lollapalooza, pois embora estivesse com o bluetooth desligado, estava com a função de acender a tela ao sacudir o braço, e vocês podem imaginar o quanto se sacode o braço durante um fim de semana de shows, né? :)

</figure>

Watchfaces

Ao contrário de um relógio digital tradicional, você pode mudar a cara do seu relógio. E existe um site com muitas watchfaces e mais ainda aparecendo todo o dia, pra agradar a todos os gostos. E em breve, com a SDK mais completa, com certeza aparecerão watchfaces que estão mais pra aplicativos.

Considerações finais

Acho que o pebble foi um investimento muito válido. Não invasivo, ele parece um relógio normal e engana tranquilamente como se você não estivesse permanentemente conectado. Ao mesmo tempo, diminuiu o número de vezes em que pego o celular durante ocasiões sociais porque todas as notificações importantes vão até o relógio. Há ainda algumas arestas a aparar, como o fato de que o Whatsapp, mesmo em mute, ainda notifica no relógio.

De resto, que venham os dispositivos de convergência. Mal posso esperar a época em que estarei com meu pebble fazendo um review do meu mais novo Google Glass :)