Hoje eu vou começar a falar um pouquinho sobre Web3, vou contar um pouco do que veio antes e como as coisas evoluíram até chegar a esse ponto. Também vou falar por quais motivos eu trato o nome Web3 mais como marketing do que propriamente uma mudança tecnológica na arquitetura da Web. Para quem quiser realmente se aprofundar nessa história, eu recomendo o documentário do Discovery Chanel, “A Internet”, são capítulos curtos que contam sobre algumas fases da criação da internet, mas eu vou fazer um resumo aqui, baseado no que eu me lembro.
A internet surgiu a partir do protocolo de comunicação ARPANet [Advanced Research Projects Agency Network], da DARPA [Defense Advanced Research Projects Agency], que é um órgão americano de pesquisa em defesa, no final da década de 60. Os militares precisavam de uma forma de trocar e compartilhar informações que permitisse a descentralização das mesmas e que fosse capaz de se comunicar em longas distâncias. Na época da criação, a rede foi estruturada em cima das já existentes linhas de telefone e telégrafo, e o tráfego de dados se dava em baixíssima velocidade. Em pouco tempo o sistema foi ampliado para suportar comunicação via rádio e, posteriormente, satélite. Como o tempo, essa infraestrutura de backbones foi sendo ampliada, inicialmente com rede metálica, seguida por fibra ótica, possibilitando aumentar significativamente a velocidade dos dados trafegados dentro dessa rede. Atualmente o Elon Musk está desenvolvendo toda uma infraestrutura de satélites nova, o Star Link, que promete velocidades absurdamente altas de transmissão de dados.
Quando a rede foi aberta para pesquisa e desenvolvimento de forma não militarizada, uma das primeiras coisas necessárias era um protocolo de comunicação ponta a ponta, então surgiu a primeira camada da internet, que é o protocolo TCP/IP [Transmission Control Protocol/Internet Protocol]. O IP fornece uma identificação única para cada computador plugado dentro da rede e até pouco tempo atrás se usava o padrão de IPv4, agora nós estamos migrando pro padrão IPv6, e a diferença de um para o outro é a quantidade de dispositivos que podem ser identificados de forma única. O TCP é um protocolo de mensagem persistente, ou seja, quando uma mensagem é enviada, precisamos ter certeza absoluta que essa mensagem foi recebida, então o protocolo TCP/IP fica esperando até que essa mensagem seja recebida pelo destinatário e retorne um acknowledgement [ACK], mesmo que a resposta dessa mensagem seja o servidor não existir ou não responder. A gente tem outro protocolo, o UDP [User Datagram Protocol], que é o “irmão feio” do TCP, que justamente corta a parte de persistência do processo. Então no TCP você manda uma mensagem e tem garantia de entrega e no UDP você manda uma mensagem sem garantia de entrega. Um exemplo de utilização do UDP são os jogos de MMORPG, o protocolo é usado para informações que precisam ser enviadas em quantidade e numa velocidade muito rápida, mas que não há a necessidade de ser recebida, de fato, por todo mundo. Mas o que mais diferencia o TPC do UDP, tirando a parte técnicas de socket, é a questão do cabeçalho da requisição. O protocolo UDP não envia um cabeçalho de requisição, porque o servidor não vai devolver o ACK. No caso do TCP a gente precisa endereçar aquela mensagem para algum IP específico. Grosso modo, a internet é isso, um protocolo de comunicação. Em cima do protocolo TCP/IP foram criados vários outros tipos de protocolos: protocolo SMTP para email, protocolo HTTP pra Web, e por aí vai. Existem várias camadas sendo feitas em cima do TCP/IP, para fins específicos.
É comum escutar que o Tim Berners-Lee criou a Web, na prática ele criou o WWW [World Wide Web], o HTTP [Protocolo de Transferência de Hipertexto / Hypertext Transfer Protocol] e o HTML [Linguagem de Marcação de Hipertexto / HyperText Markup Language], que são a base da Web para sites. O protocolo HTTP foi feito numa camada acima do TCP/IP e é utilizado até hoje. Nós estamos numa transição da versão 2.0 pra versão 3.0, embora não haja uma implementação 100% do protocolo HTTP/2 e ainda existam inúmeras aplicações que utilizam a versão 1.1. O HTTP é um protocolo direcional, então um computador vai mandar uma requisição para um IP e uma porta [por conversão internacional, a porta para o HTTP é a porta 80, e a porta para o HTTPS é a 443] usando a base do protocolo TCP/IP e enviando uma mensagem que contém o cabeçalho de informações e o corpo da requisição. Por convenção, o HTTP tem tipos específicos de retorno, os status de retorno, e podem conter informações de retorno ou não. Fundamentado nessa estrutura básica, mais ou menos o que acontece é um sistema de “ping pong”, você manda pro servidor um “ping”, e o servidor te responde o “pong”, é basicamente isso um servidor Web. Para fazer uma requisição HTTP, precisa ter na ponta que está sendo requerida um servidor que entenda o protocolo HTTP e faça respostas coesas das requisições, assim como qualquer outro protocolo na rede, você precisa ter um client e um server, isso a gente chama de protocolo direcional, um manda a pergunta e o outro responde.
O HTTP até a versão 1.1 é um protocolo de socket direcional, mas foram criadas várias ferramentas ao longo do processo para contornar alguns dos problemas. Dos anos 90 até o começo dos anos 2000, os sites eram estáticos, você clicava em links e era redirecionado. Não existia interatividade, era muito difícil um site que tinha cadastro, não existiam métodos de pagamento, não existia e-commerce, a internet servia basicamente pra ler alguma coisa. No começo dos anos 2000, surgiram alguns serviços para fazer alguns tipos de postagens, mas eram ferramentas bem rudimentares ainda. Quando chegou mais ou menos em 2008, a Microsoft estava fazendo um projeto pra acessar o Outlook, um sistema para email que vinha instalado nos computadores, via browser. A tarefa dos engenheiros era construir uma forma de conseguir a mesma funcionalidade do Outlook direto no navegador. Foi quando eles criaram o XMLHttpRequest. Pra vocês entenderem a importância desse protocolo, ele foi responsável pelo termo Web2.0 e é usado até hoje. Se na primeira fase da Web as páginas eram estáticas, a gente clicava em links e era redirecionado para aquelas URLs (não vou entrar em questões muito técnicas com relação a DNS nem URLs), com o surgimento do XMLHttpRequest, as requisições HTTP poderiam ocorrer em background, usando JavaScript. Até então o navegador tinha o JavaScript embutido bem rudimentar, para fazer coisas muito simples, com o XMLHttpRequest se tornou possível fazer requisições HTTP em segundo plano. Isso possibilitou criar telas de loading e solicitações de informações em background sem precisar recarregar a tela sem precisar dar refresh. O Gmail foi a primeira grande aplicação em uma página que aplicava muito bem o XML. Depois cunharam o termo Ajax [Asynchronous JavaScript e XML], pra nomear esse serviço de requerimentos assíncronos. Na primeira vez que eu ouvi esse termo, Ajax, eu quis aprender a fazer a barra de progresso e eu comecei a pesquisar para tentar achar coisas em inglês, o JavaScript era uma coisa horrorosa, horrível de se programar, ele só passou por uma mudança grande lá por 2015, mas eu gostava muito e eu estava muito a fim de fazer um serviço com a barrinha de progresso, então eu fiquei meio aficionado por esse negócio.
Foi nessa na época também que começaram a surgir coisas dinâmicas na internet. Surgiu o Flash, então da MacroMedia, que implementou o XMLHttpRequest acoplado a um sistema de criação de animações e era muito melhor do que o CSS e o JavaScript, então virou uma febre os sites em Flash, dinâmicos. Em paralelo, o Java Script estava evoluindo, hoje ele é completamente diferente, ainda não é 100%, mas já tem muito mais coisa do que tinha na época. A primeira versão do YouTube e de outros concorrentes para streaming de vídeo utilizavam Flash para fazer o player, que era a tecnologia de ponta na época, rodava em vários dispositivos e tinha suporte a vários tipos de codec de vídeo diferentes. Quando começaram a surgir os primeiros players de vídeo, eu estava trabalhando numa agência que tinha o site de um jornal do estado e eles queriam colocar vídeos, então eu tive que mexer muito com Flash. E aí veio o Steve Jobs e “sepultou” o Flash, tirando o suporte nos iPhones.
Olha que cenário “horroroso” a gente tinha no começo dos anos 2000, não tinha e-commerces, a maioria das páginas eram páginas estáticas, a gente estava começando a ver algumas coisas surgindo de interatividade… Começaram a surgir algumas linguagens de backend, que interagiam melhor com o protocolo HTTP, onde era possível fazer cadastros e passar informações. Mais ou menos nessa época também começaram a aparecer algumas aplicações de pagamento, tipo PayPal, que depois foram se popularizando e, com elas, surgiram os e-commerces, foi quando surgiu a Amazon e, enfim, a gente estava num processo evolucionário, a chamada Web2.0. A Web1.0 era meio tenebrosa, só quem era muito entusiasta utilizava esse negócio. Eu só fui dar valor de fato à Web muitos anos depois do meu primeiro contato, aí eu fui fazer curso de Web Designer, tudo isso usando protocolo HTTP1.1.
Em 2015 houve a convenção do ECMA, um órgão sem fins lucrativos que tem no seu corpo de colaboradores Apple, Microsoft, Google, FaceBook, entre outras, para definir quais eram os próximos passos evolucionários da Web, e aí surgiram o ES5 e o ES6, que nós utilizamos até hoje no JavaScript. Foi definida a implementação de sockets bidirecionais, websockets, a implementação do Canvas no HTML para fazer uma “prancheta de desenho”, a orientação a objeto e mais uma séria de questões importantes pra linguagem ficar mais robusta. Foi nessa convenção também que definiram que seriam implementadas funcionalidades para integração com Assembly e GPUs. O WebGL e o WebAssembly foram criados, o WebSound, para múltiplos canais de áudio no browser, bibliotecas nativas de codificação de vídeo e o surgimento da tag “vídeo” dentro do HTML. Perceba, por que é que as maiores empresas do mundo se uniram e fizeram uma convenção de coisas que deveriam ser adicionadas na Web para mexer com GPU, mexer com Assembly, poder fazer leitura de códigos binários, um socket bidirecional, Canvas pra desenho? Quando você para pra pensar, os caras estavam vendo 20, 30 anos pra frente eles já estavam querendo fazer um sistema operacional dentro do browser, criar hardwares em casa menos complexos, deixando os processamentos mais grossos pra Web. Sistemas como o NVIDIA GeForce NOW e o Google Stadia são mais ou menos isso: se você não tem grana pra comprar uma máquina foda, você paga uma mensalidadezinha e consegue jogar qualquer jogo nessas plataformas, só precisa ter um computador ou um celular básico pra fazer o streaming. E tem muita gente no mercado de jogos falando que esse é o próximo passo evolucionário dos games, os jogos por streaming, não sei se eu concordo 100% com isso porque a gente ainda tem a questão das latências.
Então o HTTP até então era um protocolo passivo, que dependia da interação ou da página ter funções para solicitar ao servidor informações atualizadas sob demanda em background via XMLHttpRequest. A partir do momento que a gente adiciona um socket bidirecional, o servidor pode mandar informações pra os navegadores sem a necessidade de uma requisição do cliente. Uma das primeiras coisas feita de fato usando sockets bidirecionais foram os push notification, que tem gente que adora, tem gente que odeia. Você acessa o site, aparece aquela janelinha “você gostaria de receber notícias do site”, e aí quando você está navegando, brota aquele popup falando “fulano de tal mandou mensagem do site tal”, você clica e é redirecionado para o site. Perceba, é um serviço que roda em background no seu navegador, você pode estar navegando em qualquer página e é impactado diretamente por uma mensagem que foi enviada pelo proprietário desse opt-in. Ao clicar em “sim” o que você esta fazendo na prática é mandando pro servidor a liberação do seu push. Perceba, a gente passa de um cenário onde os servidores eram passivos e só ficavam esperando uma requisição, agora o servidor também é ativo, o servidor pode mandar informações. Isso abre um leque de opções de coisas que podem ser implementadas. Outro exemplo simples de como é que é essa aplicação pode funcionar na vida real: nas redes sociais que ou até mesmo no WhatsApp, aparece “fulano está digitando”, esse tipo de interação em real time é um processo de socket bidirecional. Dava pra simular esse comportamento dentro de um protocolo HTTP1.1? Dava, você podia ficar fazendo o JavaScript ficar mandando requisições, mas não era performático, porque, de novo, o protocolo HTTP tem um cabeçalho que consome muitas informações, ele é muito grande em termos de volumetria de bits. Quando você tem um socket bidirecional a conexão é feita uma vez só e não precisa ter um cabeçalho de resposta e retorno, porque o servidor mantém uma conexão persistente com o cliente, então ele sabe quem é quem. Quando você tem um protocolo HTTP seco, ele não sabe que é que está fazendo a requisição, você é um socket qualquer que vai receber uma identificação básica e vai passar uma séria de informações.
Já que o HTTP é um protocolo que não tem persistência de informação, o servidor precisa conseguir identificar o usuário, para isso foram criados os processos de sessão. Em uma sessão, o servidor que está recebendo a requisição vai receber junto, no cabeçalho, alguma informação que identifica o usuário, foram desenvolvidas várias formas diferentes de identificação, até que o padrão de mercado se tornou o JWT [JSON Web Token]. Hoje em dia praticamente todos os sistemas usam IAM para [Identity and Access Management] para fazer a autenticação e o JWT como token de validação de sessão. Então aqueles serviços de “Logar com FaceBook”, “Logar com Google” são JWT e IAM. Dentro do protocolo HTTP1.1 o token contém uma quantidade de informação grande e é obrigatório passar esse token via header a cada requisição, se não o servidor não consegue identificar quem é o usuário. Pra tentar melhorar um pouco foi criado um negócio que se chama cookies, que são, em sua essência, dados armazenados localmente no browser do usuário que vão ser enviados para o servidor quando for feita uma requisição. Esse é o comportamento básico de um cookie: o servidor te manda uma informação que é armazenada localmente e, a cada nova requisição, essa informação é reenviada para o servidor. Então, na base da Web2.0, quando a gente fala de autenticação, nós enviamos a requisição de login, usuário e senha para o servidor, que cria uma sessão. Essa sessão recebe uma etiqueta, um endereçamento, que é enviado para o browser depois que a gente termina a autenticação, essa informação cria um cookie. Inclusive nós conseguimos criar cookies via o próprio cabeçalho da requisição HTTP, tem uma função chamada “set cookie” que você envia para o browser criar aquela informação e o browser automaticamente devolve aquela informação dos cookies que estão na máquina do usuário.
Isso é muito útil, mas também cria outro cenário, que, no meu entendimento, é a parte mais complicada, que são os retargeting [eu vou deixar linkado no final o post em que eu falo sobre o fim do retargeting e o começo do metaverso]. Como a gente tem esse comportamento do HTTP e dos cookies, começaram a criar formas de conseguir identificar os usuários e cruzar informações com relação ao que você vê e o que você consome. Imagine o Google, uma empresa gigantesca, que tem N serviços que nós utilizamos todos os dias, ele consegue criar todo um perfil seu na internet. Ele consegue te identificar, consegue saber onde você mora pelo seu IP, consegue ver as buscas que você está fazendo, saber os vídeos que você vê no YouTube, consegue ver suas fotos, porque você tem o Google Fotos com as fotos que você nem sabe que tem, enfim, uma série de coisas. Com todas essas informações ele consegue entender que tipos de produtos te chamam a atenção. Esse é o grande diferencial do Google perante todos os outros serviços do mundo, ele consegue ter uma lista de contatos, uma lista de emails gigantesca, ele consegue te impactar de N formas diferentes e ele sabe exatamente o que você gosta, quem é você, e por aí vai. Por esse motivo, o mundo inteiro está criando uma série de leis de proteção de dados, inclusive aqui no Brasil a gente fez uma cópia “maravilhosa” da GDPR, da lei de proteção de dados da Europa, e essas leis visam reduzir a quantidade de informações que essas empresas estão capturando dos usuários, porque chega a níveis perigosíssimos. Quem nunca, conversando com um amigo sobre um determinado assunto, sei lá, “mulher grávida”, você mal falou sobre, mas já começa a pipocar um monte de anúncios no seu feed, de fralda pra bebê, de curso pra cuidar de criança, todo mundo no mundo já passou por isso. Com essas informações que são trafegadas via cookie nas requisições HTTP, essas inteligências artificiais de retargeting podem enviar informações relacionadas à sua necessidade de consumo imediata. Teve até um caso de um pai que abriu um processo contra uma empresa, porque essa empresa começou a mandar propagandas de coisas de bebê pra filha dele, menor de idade. De fato, a menina estava grávida, ela não tinha falado pro pai, mas o processo de seu porque eles estavam coletando dados de uma menor de idade. A partir desse caso, obviamente tiveram outros casos, a Europa decidiu que precisava ter formas mais rígidas de controle de dados. Quem não se lembra do Mark Zuckerberg tendo que ir ao senado americano explicar quais tipos de dados o FaceBook coleta, e aí surgiu esse movimento de leis de proteção de dados, aplicando multas bilionárias uma atrás da outra, no Google, no FaceBook, na Apple. Por isso, no meu ponto de vista, é que a Web está caminhando para esse metaverso, pra gente ficar numa zona cinzenta com relação às questões de privacidade de fato.
Com o websocket bidirecional, o HTTP passa por uma atualização para suportar nativamente, dentro do protocolo, tanto requisições direcionais, como a gente tem hoje, quanto requisições chamadas streamings. Quando você vê um vídeo no YouTube, por exemplo, você está fazendo, na prática, requisições de streaming. O servidor tem um vídeo de vários Gb e ele vai picotando essa informação em vários chuncks, pequenos pedaços, e vai te mandando à medida que você precisa dessa informação. Existem vários serviços de streaming, Netflix, Spotify, tudo que você precisa pegar uma grande quantidade de informação, picotar em partes e enviar on demand. A barrinha de progresso em baixo no YouTube, que vai carregando a medida que você vai assistindo, é um streaming. Mas esse passo evolucionário do HTTP2 e toda essa questão dos servidores se comportarem de forma mais ativa ainda não criam a tal da Web3.0. Perceba que a gente ainda “vive” na Web2.0, ainda temos cookies, ainda temos HTTP1.1, ainda temos problemas enormes de privacidade. E agora finalmente a gente vai entrar na questão da Web3.0, que surgiu com o advento das criptomoedas. Eu vou dar a minha opinião sincera com relação a isso e vou comentar um pouco sobre essa história. De novo, esse nome, Web3.0, pra mim é muito mais marketing do que propriamente mudanças tecnológicas. Eu acho que mudanças tecnológicas demoram muito, mas essas mudanças não necessariamente estão sendo feitas com um objetivo de evolução propriamente dita da Web como um todo. Todas essas mudanças têm aplicações específicas, cunharam esses padrões para fins específicos, eu não acredito que nada disso tenha sido feito “pelo bem da humanidade”.
Mas isso vai ficar para um próximo post…
Vou deixar aqui o post que comentei sobre retargeting e metaverso:
Também vou deixar uma publicação falando sobre a mais nova evolução do protocolo HTTP, o HTTP/3:
O conteúdo deste post foi inspirado pelo vídeo “Afinal o que é Web 3 – Parte 1”:
