Web3: Esperanza en los protocolos más que en las plataformas
¿No pudiste asistir a Transform 2022? ¡Vea todas las sesiones de la cumbre en nuestra biblioteca a pedido ahora! Mira aquí.
Al principio había protocolos…
En lugar de volver a escribir sobre Web3, quiero escribir sobre Web1: los años 90. En ese momento, estaba usando algo llamado Communicator. Puede considerarlo como un conjunto de aplicaciones y clientes de Internet. Por supuesto, tenía Navigator, un navegador web, pero también un mensajero para correos electrónicos, un cliente de noticias e incluso un sistema push. Fue un buen ejemplo de cómo funcionaba la web inicial: múltiples protocolos para diferentes propósitos. Puede recordar FTP, SMTP, Gopher y Archie, pero también XMPP y muchos más.
Lo bueno de estos protocolos es que hicieron que la computadora que estabas usando fuera inútil. Abstrajeron el sistema operativo y el hardware subyacentes. Asimismo, estos protocolos tomaron la filosofía de Unix y se enfocaron en una sola cosa para hacerlo bien: compartir archivos, transmitir correos electrónicos, enviar mensajes, etc.
Entonces HTTP y HTML ganaronEl más "abstracto" de estos protocolos era HTTP. Aunque originalmente fue diseñado para transferir documentos de hipertexto, rápidamente se hizo evidente que era bueno para transferir casi cualquier tipo de archivo. De manera similar, HTML vio rápidamente el surgimiento de JavaScript como una forma de hacer que los documentos estáticos sean más dinámicos. La pila web era (y sigue siendo principalmente):
1. Realice solicitudes de descarga de archivos HTML, JavaScript y CSS a través de HTTP.
2. El navegador los "ejecuta" para convertirlos en sitios web y aplicaciones sofisticados.
Esto significó que otros protocolos más especializados podrían simplemente convertirse en aplicaciones además de HTTP y HTML. Si usa Gmail y envía un correo electrónico a otra persona usando Gmail, probablemente no esté usando POP, SMTP o IMAP, solo HTTP y HTML. FTP y XMPP ahora se conocen como Megaupload y WhatsApp, para bien o para mal.
Lo que podría sorprenderte es cuán incorrectos son HTTP y HTML. Después de todo, la especificación HTTP usa Referer en lugar de "referrer", que sería el término correcto en inglés y, a pesar de todos los esfuerzos, HTML nunca pudo cumplir con los requisitos de XML. ¿Ves la ironía? HTML y HTTP, ambos mal diseñados en comparación con otros protocolos y formatos más académicos, eventualmente se hicieron cargo de toda la pila.
Es su simplicidad y versatilidad lo que ha hecho que HTTP, HTML y JavaScript sean tan poderosos para ser adoptados en todas partes y para todo.
402: Reservado para uso futuroSin embargo, la especificación HTTP tenía un buen conjunto de características, incluidos los códigos de estado HTTP, para indicar a los clientes cómo comportarse con los archivos descargados. Incluye mecanismos para redirigir a los usuarios cuando los recursos han cambiado, o indican que el usuario no está autorizado para acceder a ellos, o que ahora no está disponible. ¡Probablemente hayas oído hablar del famoso 404!
There are docenas de estados, incluido 402, para que los servidores los usen para indicar cuándo se requiere el pago. Resulta que la especificación para esto aún está reservada para uso futuro.
Esto significa que todos los sitios web y aplicaciones (incluidos los que reemplazaron los protocolos) que usaban HTTP y HTML tuvieron que averiguar cómo monetizar por sí mismos y así es como terminamos con los anuncios publicitarios y la economía de la atención.
Al poco tiempo, algunos de estos sitios web y aplicaciones se dieron cuenta de que, para ser más rentables, necesitaban crecer. Se dieron cuenta de que cuantos más datos recopilaban, más atención recibían, más encerrados, más rentables podían ser (¡no solo más ingresos!). Así es como las plataformas quedaron atascadas en medio de Internet.
PlataformasPara mantener el confinamiento, las plataformas han _privatizado_ los protocolos y además han aplicado sus propios términos de servicio: así es como F...
¿No pudiste asistir a Transform 2022? ¡Vea todas las sesiones de la cumbre en nuestra biblioteca a pedido ahora! Mira aquí.
Al principio había protocolos…
En lugar de volver a escribir sobre Web3, quiero escribir sobre Web1: los años 90. En ese momento, estaba usando algo llamado Communicator. Puede considerarlo como un conjunto de aplicaciones y clientes de Internet. Por supuesto, tenía Navigator, un navegador web, pero también un mensajero para correos electrónicos, un cliente de noticias e incluso un sistema push. Fue un buen ejemplo de cómo funcionaba la web inicial: múltiples protocolos para diferentes propósitos. Puede recordar FTP, SMTP, Gopher y Archie, pero también XMPP y muchos más.
Lo bueno de estos protocolos es que hicieron que la computadora que estabas usando fuera inútil. Abstrajeron el sistema operativo y el hardware subyacentes. Asimismo, estos protocolos tomaron la filosofía de Unix y se enfocaron en una sola cosa para hacerlo bien: compartir archivos, transmitir correos electrónicos, enviar mensajes, etc.
Entonces HTTP y HTML ganaronEl más "abstracto" de estos protocolos era HTTP. Aunque originalmente fue diseñado para transferir documentos de hipertexto, rápidamente se hizo evidente que era bueno para transferir casi cualquier tipo de archivo. De manera similar, HTML vio rápidamente el surgimiento de JavaScript como una forma de hacer que los documentos estáticos sean más dinámicos. La pila web era (y sigue siendo principalmente):
1. Realice solicitudes de descarga de archivos HTML, JavaScript y CSS a través de HTTP.
2. El navegador los "ejecuta" para convertirlos en sitios web y aplicaciones sofisticados.
Esto significó que otros protocolos más especializados podrían simplemente convertirse en aplicaciones además de HTTP y HTML. Si usa Gmail y envía un correo electrónico a otra persona usando Gmail, probablemente no esté usando POP, SMTP o IMAP, solo HTTP y HTML. FTP y XMPP ahora se conocen como Megaupload y WhatsApp, para bien o para mal.
Lo que podría sorprenderte es cuán incorrectos son HTTP y HTML. Después de todo, la especificación HTTP usa Referer en lugar de "referrer", que sería el término correcto en inglés y, a pesar de todos los esfuerzos, HTML nunca pudo cumplir con los requisitos de XML. ¿Ves la ironía? HTML y HTTP, ambos mal diseñados en comparación con otros protocolos y formatos más académicos, eventualmente se hicieron cargo de toda la pila.
Es su simplicidad y versatilidad lo que ha hecho que HTTP, HTML y JavaScript sean tan poderosos para ser adoptados en todas partes y para todo.
402: Reservado para uso futuroSin embargo, la especificación HTTP tenía un buen conjunto de características, incluidos los códigos de estado HTTP, para indicar a los clientes cómo comportarse con los archivos descargados. Incluye mecanismos para redirigir a los usuarios cuando los recursos han cambiado, o indican que el usuario no está autorizado para acceder a ellos, o que ahora no está disponible. ¡Probablemente hayas oído hablar del famoso 404!
There are docenas de estados, incluido 402, para que los servidores los usen para indicar cuándo se requiere el pago. Resulta que la especificación para esto aún está reservada para uso futuro.
Esto significa que todos los sitios web y aplicaciones (incluidos los que reemplazaron los protocolos) que usaban HTTP y HTML tuvieron que averiguar cómo monetizar por sí mismos y así es como terminamos con los anuncios publicitarios y la economía de la atención.
Al poco tiempo, algunos de estos sitios web y aplicaciones se dieron cuenta de que, para ser más rentables, necesitaban crecer. Se dieron cuenta de que cuantos más datos recopilaban, más atención recibían, más encerrados, más rentables podían ser (¡no solo más ingresos!). Así es como las plataformas quedaron atascadas en medio de Internet.
PlataformasPara mantener el confinamiento, las plataformas han _privatizado_ los protocolos y además han aplicado sus propios términos de servicio: así es como F...
What's Your Reaction?
