u/Stevious7

Just found this site, and I can't verify the authenticity of the submissions but it looks very 1996-y to me.

https://www.cs.earlham.edu/~jeremiah/linux-pix/linux-logo.html

I thought it was pretty cool so I wanted to share it here!

NOTE: This post wasn't sponsored by big-browser, I just happen to really like the capabilities of modern browsers.

Here's the advantage of the web: distribution.

Everybody and their mama has a browser, I can guarantee that.

Your users, whether on tablet, PC, phone will all get the application just by visiting a link. That's cool asf!

Now, I wanted to address some concerns you, a desktop application dev, might have:

• "The web app won't be as performant" Browsers have a WebAssembly and WebGPU capabilities, so anything from 3D acceleration to compute heavy video editing, even ML can be done natively in browsers.

• "I want users to install my app" Progressive Web Apps (PWAs) let you do that.

• "I want my app to work offline" Service Workers let you do that. They'll help you cache the entire application so that it works completely offline (provided you architected it right).

• "I want to interact with the users files" File System Access API got you covered.

• "I want to do some peer 2 peer stuff" Take a look at WebRTC. That's exactly what that's for.

These were the common concerns I've seen desktop devs have about web apps. I wanted to show them how capable browsers have gotten, and that it has become a very viable build target.

Obviously there will be cases where an application needs to be installed like when you'd like to directly talk to sockets, or do something more intrusive, in which case, you can proceed with Electron.

If y'all know any other cool browser-native technologies let me know. I'd love to take a look and mess with them.

I'm going to make this as an experiment, and I'd love to see what others come up if they decide to make this too.

The idea is simple: feed the image into an AI to extract facts from the image, store the facts as a file, then when the user wants to see the image, have the facts fed back into the model to recreate the image.

The theory is that storing facts as text is cheaper than storing a compressed image. It may or may not be true, which is why I'd love to see the outcome.

Obviously the output isn't the same image that was fed in but it'll be interesting to see how close it gets using various techniques. Maybe encoding the facts along with a super super low res version of the image to see what it would make.

I figured whoever makes this should try it with WebGPU so that people can easily try it out and have fun with it.

NOTE: this isn't a serious proposition at a 'better compression algorithm', it's just a fun idea to try out and have fun with to see what happens.

My day job isn't software development related, so I don't read a whole lot of code. The only code I read is the one I write and that's a problem.

Since I'm very interested in open source, I figured I should get comfortable reading code I didn't write, and I found a pretty amazing solution: debug AI code.

Here's what I did: after I mess with LLMs and (of course) an unintended behavior appears (bug), I challenge myself to dig in and find it manually. Since I generated the code, and didn't actively write it, it has the same feel as reading other GitHub repos except a bit more comforting since I already know an abstract way of how it works.

The one thing this taught me is that I don't need to fully understand how the whole system works end-to-end, I just ended to understand the pieces about the behavior I want to change. So, no more tracing everything from *main.py* for example.

I'd like to think that this training regimen has improved my code-reading skills by a mile! I'm not as afraid to dig into someone else's code since it's just as foreign (or familiar) as AI code. Obviously this only holds true for TypeScript + React since that's my preferred stack, but still!

I wanted to share this with anyone interested in open-source but is frightened from reading open-source repos.

I've been binging WINE documentation and articles about how it works under the hood so that one day I can contribute to it!

What do you guys think about this training regimen?

I figured let's all chat about what NOT to do, what didn't work out, or what to avoid.

In my case, back when I was 1st year CS, made a static site generator with Python that uses JSON as a templating language.

Obviously it sucked HARD. You basically wouldn't be able to use it if you didn't know it fully worked end-to-end. Also, no type safety at ALL. So sometimes I would use it and nothing happens, and would spend a shit load of time figuring out I messed up EITHER the syntax of the templates or the JSON fields.

I've heard the term "surprise cloud bill" associated a lot with AWS as relative to other platforms. it could be a sampling bias since many more people use AWS. If I'm deploying a simple personal project that might require a VPS, for example a TURN server, how can I make sure I never get a surprise bill?

Is there a way to set maximum budget for a certain timeframe that way I don't get $2000 bill when I was expecting only $20? (Fake numbers since I haven't calculated EC2 costs).

I have been doing research on WASM because at one point I wanted to port `croc` CLI to WASM.

Here's what I figured out which I wanted to share with you guys if any of you is interested in WASM to basically know it's capabilities / use-cases without going down the rabbit-hole and be disappointed.

What's WASM?

WASM (WebAssembly) is compiled code from non-web languages like Go, C++, Rust and more (I believe Java too).

This means that the performance is off-the-charts when it comes to compute task, and that's going to be its only use case. It's only ever going to be a compute API for you.

What can't WASM do?

WASM can't talk directly to sockets, so porting to `croc` doesn't work (at least not as easy as compiling the Go code to WASM). WASM is also sandboxed by the browser's JavaScript, so if JavaScript can't do something WASM will definitely not.

So if WASM is sandboxed by JavaScript, and doesn't unlock anything new, why should I use it?

Well, if you have a compute heavy task, you can off-load it from the server and have it run in the client. For example, video editing, photo editing, audio editing, and similar tasks. Instead of sending the video to the server and have a back-and-forth, just use WASM.

A prime example of WASM is Figma. It's a React wrapper with WASM handling the compute-heavy tasks.

So why not just have WASM process everything?

There's a tax you pay with WASM, and you need to evaluate it on case-by-case basis. Crossing the barrier between JavaScript to WASM, and back to JavaScript takes compute. So, before throwing WASM at something, make sure that WASM will yield much more performance than what you pay by crossing the barrier.

That basically concludes my very brief intro to WASM. Let me know if this helped at all or if I got something wrong in the explanation.

tldr: don't allow users to use your GitHub token unrestricted.

Hi!

I just wanted to share this experience I had today (technically yesterday night).

### What I did wrong

Basically didn't want to deal with the hassle of storing & converting suggestions/submissions/reports into issues. I figured I could just use a fine-grained token from GitHub and put it in my serverless worker to submit issues directly to the repo. That way, users won't have to signin/signup to GitHub to submit issues.

### Cherry on top

Basically, I posted about the GitHub token setup, and how overwhelmed I am currently with issues. Basically, I handed what will get to me on a silver platter to any bad actor.

### The attack

Around ~11:30pm today, I kept getting alerts that I issues kept getting submitted at an abysmal rate. I'm talking each time I refresh, there's 100 additional issues.

### The counter

I've dealt with cyberattacks before at my job, so all I had to do was revoke the token, setup a Python automation to close the offending issues, and put on some music to delete the issues.

Obviously that's not enough to thwart a future attack, so I went an extra step and setup rate-limiting and IP bans.

### Reflection

It's kinda cool to see someone put effort into bothering you for whatever reason. It's a pretty dumb mistake I'll be the first to admit that. I'm taking this as a lesson to think twice before exposing a powerful token to the end-users.

Hi y'all,

My repo recently blew up and now I have a shit load of issues I have to sift through.

To put it in context, I launched about a month ago, and I have closed around ~350 issues, and I still have about ~80 to go.

How are there so many issues? basically I used my GitHub Fine-Grained token to allow a serverless function to make a GitHub issue from my account onto my own repo on the user's behalf. That way, they don't have to signup/signin GitHub to make an issue.

Some are workable, and a good bit are not. I made a tool to make the workable ones easier to add, so that's cool. The unworkable ones are the ones that take the most time.

Basically the website is a collection or open-source, in-browser, no-signup tools. The mixture of unworkable issues I get are either:

- in browser, but requires signup

- no signup, but requires installation

- in browser and no signup, but not open source.

Obviously because I don't wanna do anyone dirty, I have to take due diligence and make sure the closed source ones are indeed closed source. So I have to search around to make sure there really is no repo for the tool.

The "automation" I currently have is that whenever someone submits a repo that closed-source, it automatically gets flagged as "missing GitHub link." The thing is that some of the entries genuinely are just missing the repo link, which is why I search.

Is there a way to automate this, or at least some of the time-consuming parts?

TLDR: Backwards compatibility

I'm not sure where I heard this but the web's ethos is that websites made all the way back at the inception of the web will be guaranteed to continue working.

That's obviously great but I feel like we're stuck because of it. How? I believe the specs for the web is reaching 100k pages, so no wonder why it's difficult to make a browser from scratch (s/o to the LadyBird project).

Now, obviously the opposite end of that isn't great either. I mean imagine you visit a website and it responds with:

"418. Can't load. Install Web 3.0 browser/plugin."

Maybe at the 50th anniversary of the web we should just make a refined set of specs with modern features and call it WebV2.

Maybe this new web will be TypeScript native, or something of that sort. What do y'all think?

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.