Web Development

sAT Protocol (s@) is a decentralized social networking protocol based on static sites. Each user owns a static website storing all their data in encrypted JSON stores. A client running in the browser aggregates feeds and publishes posts. It does not rely on any servers or relays.

In plain terms, s@ is designed for you and your friends, and no one else. This applies to both the technical implementation and the user experience. At the technical level, data only moves from your own website to your friend's browser. There are no servers (like Mastodon) or relays (like the AT Protocol) in the middle1. And unlike almost all social media platform today, s@ is not designed for influencers. To see a friend's post or to have a friend see your post, you must follow each other2.

A user's identity is their domain name. Identity is authenticated by HTTPS/TLS - fetching content from a domain proves the domain owner published it.

Source [web-archive]

Related: https://github.com/remysucre/satellite (Social networking over static sites...)

Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site's performance in Google Search results. To give site owners time to make any needed changes, we're publishing this policy two months in advance of enforcement on June 15, 2026.

You can do batches too via json. Very nice

La web presenta un bajo nivel de profesionalismo y una atención al cliente deficiente. El sistema de recuperación de cuentas resulta completamente ineficaz, ya que no ofrece soluciones reales cuando se intenta recuperar el acceso. En mi experiencia con Hostinger, el soporte no responde de forma útil ni oportuna.

Por estas razones, no se puede considerar una plataforma confiable ni con un servicio de atención adecuado.

These days, developer experience (DX) is often the strongest case for using JavaScript frameworks. The idea is simple: frameworks improve DX with abstractions and tooling that cut boilerplate and help developers move faster. The tradeoff is bloat, larger bundles, slower load times, and a hit to user experience (UX).

But does it have to work like that? Do you always have to trade UX for DX? And are frameworks really the only path to a good developer experience?

On Jan 13th, 2025, we noticed strange 404 errors in our backend logs, originating from Bunny Storage.

Is there any good courses that cover the more technical aspects of backend development? Here are some examples, not even limited to this, but I want to hear more than the basics and also some security things to look out for in like a yt video or something, potentially includes, CORS, Cookies, JWT, server side sessions, server side rendering, websockets, server side events, html patterns (e.g the backend returning html components to be place into the browser). Status Codes, GET and POST, GRPC, file transfers.

Right now, I have it set up so that the initiator for the connection does a peerConnection.restartIce(); if the peerConnection.iceConnectionState is failed or disconnected when peerConnection.oniceconnectionstatechange is triggered. This triggers a peerConnection.onnegotiationneeded event where I handle sending a new offer as the start of renegotiation which is then followed up by the initial negotiation steps.

The problem is that after all of this, the remote streams for both peers are frozen where they were when the webRTC failure happened. Does anyone know how to handle this so that the remote streams continue playing after recovery? If possible, I would like to do this without setting up new peer connections as it would be simpler.