u/Stevious7

This is an internal discussion I had with myself, but I wanted to hear some outside options on this.

Let's start with the problem: censorship. Should we make a "new Internet" that is censorship resistant? Or should we piggybsck on what we already have? Let's explore that.

#### Should we change the infrastructure

Re-doing the web is basically infeasible. We'd have to convince basically all the population on a new routers, DNS, and NIC specifications to transport the new "new internet" packets. So, we should keep the infrastructure and piggyback on it.

#### Should we change the protocols?

So, far, no. The HTTP/S and WS protocols have been sufficient for what we need them to do. I mean you can't get more hyper text than hyper text am I right?

Also, if we were to make our own custom protocol for our "new internet" we'd have to make browsers that can use the new protocol. So, no the protocols are fine and we can keep them.

#### The main limitation

Currently we have Client-Server and P2P. Each have their own advantages and disadvantages. Obviously Client-Sever is very vulnerable to censorship, but whG about P2P? I've gone through the rabbit-hole of P2P protocols, and they're good but not perfect.

#### The problem with P2P

I've had this talk with a colleague but let's imagine we're building a P2P Discord. Lets see what problems we encounter:

- How are we going to make sure the chats reach everyone? How is that going to affect scaling?

Mesh comes to mind but good luck scaling it past 15 nodes. You can use trees for efficiency, but the trees are too rigid for a dynamic environment like chat rooms. You can use gossip, but it's unreliable. Same problem with small-world. Realistically, the solution would be a mix of the previously mentioned along with some extra code to cover for its the downsides.

- How can discovery work?

Let's imagine you have a server on this app. How are you going to let new people join without being online 24/7? Let's say anyone can join using someone else who is in the same chat room. What if they're offline too? The answer is: this wouldn't work. Something needs to be on 24/7 to listen for join requests.

- How can we protect against state-sponsored swarms?

A state can have swarms of bots/accounts basically tampering with our messages and breaking the message routing we have in place. Even if we have tamper-proof measures in place to ensure authenticity of messages, we can't guarantee that the state-sponsored swarms are going to let our messages get delivered in the first place.

- Difficulties of sending chat history to new online nodes after they were offline.

Let's say two peers were chatting. Then one of them leaves, and a new peer joins and starts chatting. Merging the histories together so that a full conversation history isn't impossible between all online/offline peers, but it's going to take its time for sure.

- Data-hogs like videos. How are those shared?

Storing text is no problem, but videos are beasts. So, we'll have to find a way to make our application store replicas across nodes. If all the nodes are offline, then you're screwed.

All the aforementioned are just few of the limitations that building a censorship-proof application are going to encounter. I'm all ears for how a custom solution would treat this.

This is meant to be a discussion. So I'd love to hear what y'all think.

So, do you guys fully design the application in Figma (or some other software) fully before coding it. Or do y'all YOLO and whatever sticks sticks?

I've been doing the latter for the longest time, basically years, and it definitely pisses me off whenever I have to re-do something because it doesn't work visually or UX-wise. Either that or I gaslight myself into liking it.

I wanted to add a plugins system to my application securely, and it's proving to be a bit tricky.

Obviously plugins are going to be some extra JS that the users load. I want to make it so that the plugins have certain permissions they have to declare in a manifest.json file, and based on these permissions, I could render to the user what kind of "data hooks" the plugin is requesting. The "data hooks" will basically just be a bus subscribe/emit object that takes in callbacks on certain events and fires the associated callback functions. I also want the plugins to declare in the manifest.json what kind of URLs they want to send requests to and show that to user.

Here's the problem though: a plugin could declare that it wants access to a certain piece of information but its JS could be doing all kinds of malicious things. How can I make sure the JS is sandboxed and only the information that I want it to have, it will have? How can I intercept the fetch requests to make sure only the URLs defined in the manifest the plugin is requesting from?

Thanks in advance!

Live: https://fcksignups.com

Going through the submissions on the site has been a pleasure. Especially in the Design & Graphics section.

One of the coolest ones I found was an SVG -> 3D model tool that works in-browser. There was another one called World Monitor, and it aggregates news from different regions and shows conflicts in real-time.

Since the developers behind those tools took the time to make fantastic web apps, it would be a disservice to let the tools die, especially if they were already generous and made the applications open-source.

If you guys have found/made apps that are in-browser, open-source and require no-signups, I'd be honored to have it featured on the site.

Cheers!

GitHub repo: https://github.com/BraveOPotato/FckSignups

I've opened my eyes lately to how capable the browser is. I mean, there's a WebRTC API, WebGPU API, a WASM runtime, maybe an LocalLLM API soon if the Chrome team insists...?

This means that the barrier of using tools should be little-to-none since it should be as easy as opening a browser tab.

Since I'm the audience for no-signup, in-browser, open-source tools, I figured I make a place that curates all of those tools in one place. So, voila!

Contributions are of-course welcome!

GitHub: https://github.com/BraveOPotato/fckSignups/

I'm trying to wrap my mind around custom hooks. As far as I can see, they seemed to be regular functions with React's hooks embedded within. I'm trying to internalize the mental model of how it's all supposed to work to not fall into an anti-pattern. I'm using AI to learn, so I asked about examples of custom hooks and the response made me raise an eyebrow.

The way AI was using custom hooks is to return state and state setters from the custom hook. I guess that works, but that can't be all. Right...? Also, I'm not sure if React allows this, but couldn't we have used OOP to encapsulate the data and the associated methods instead of the custom hook?

What I was making was a data store for the whole application that holds the application's current state (like which tab the user is on right now, which peer is the user currently connected to, etc...).

Could anybody point me to a good example on GitHub that I can reference as good use of custom hooks? When do you guys get the "eureka" that something should've been or should be a custom hook?

Thanks in advance

I considered myself an anti-frameworker and a purist because I prioritized raw speed and bundle-size over developer experience (which I wasn't aware of at the time).

I brushed React and TypeScript to the side as a "hype" and "it'll go away once everyone finds a new shiny toy." Oh boy was I wrong.

I was creating applications with vanilla HTML, CSS, and JS for the longest time. I mean why add a build/transpile step when I could just have raw performance eh? I even dabbled into web components when the time called for it even though I hated how inconvenient they are.

After my applications got decently complicated, adding features became a mine-field of runtime errors and edge-cases. I slowly started craving features that would just make this a bit easier such as self-documenting code via a static type-system, a component system to re-use code chunks, hot module replacement, installable-plugins and modules... wait... this smells like React + TypeScript with Vite... the industry-standard...

So yes, I admit it. I'm liking React + TypeScript. A blasphemous utterance for an anti-frameworker such as myself.

Switching has brought a fresh feel to web development for me. Now, I don't have to make all the features from scratch like drag-n-drop and modals. The industry has already paid that cost, and I should leverage it. Looking back at it in retrospect, not using React + TypeScript for single-page-applications (SPAs) was a crime against web development. I'm now going through the grouly process of re-writing the applications in React + TypeScript because I honestly hit a wall with how inconvenient development has gotten.

I'm not going to lie, I'm reflecting with a bit of a pain. I knew the advantages, and disadvantages of my ways yet still chose the hard way due to stubbornness.

It's true what they say, the ****** of consequences rarely comes lubed.

If you'd like to read the more detailed version about my thought process, it's over here...

https://blog.alkhafaji.dev/#i-cant-believe-i-ever-hated-typescript

NOTE: I know React is a library not a framework, but the idea is still the same.