Sure, I agree.

Unfortunately, no such solution currently exists or has been widely adopted.

I use an app called Recipe Keeper. It’s amazing because I just share the page to the app, it extracts the recipe without any nonsense, and now I have a copy for later if I want to reuse it. I literally never bother scrolling recipe pages because of how terrible they all are, and I decide in the app if the recipe is one I want to keep.

It also bypasses paywalls and registration requirements for many sites because the recipe data is still on the page for crawlers even if it’s not rendered for a normal visitor.

You’re in the wrong Rochester!

I recently went through these exact pains trying to contribute to a project that exclusively ran through Discord and eventually had to give up when it was clear they would never enable issues in their GitHub repos for “reasons.”

It was impossible to discover the history behind anything. Even current information was lost within days, having to rehash aspects that were already investigated and decided upon.

I disagree. You should have validation at each layer, as it’s easier to handle bad inputs and errors the earlier they are caught.

It’s especially important in this case with email because often one or more of the following comes into play when you’re dealing with an email input:

• You’re doing more than sending an email (for ex, creating a record for a new user).
• The UI isn’t waiting for you to send that email (for ex, it’s handled through a queue or some other background process).
• The API call to send an email has a cost (both time and money).
• You have multiple email recipients (better hope that external API error tells you which one failed).

I’m not suggesting that validation of an email should attempt to be exhaustive, but a well thought-out implementation validates all user inputs. Even the underlying API in this example is validating the email you give it before trying to send an email through its own underlying API.

Passing obvious garbage inputs down is just bad practice.

Yes, but no. Pretty much every application that accepts an email address on a form is going to turn around and make an API call to send that email. Guess what that API is going to do when you send it a string for a recipient address without an @ sign? It’s going to refuse it with an error.

Therefore the correct amount of validation is that which satisfies whatever format the underlying API requires.

For example, AWS SES requires addresses in the form UserName@[SubDomain.]Domain.TopLevelDomain along with other caveats. If the application is using SES to send emails, I’m not going to allow an input that doesn’t meet those requirements.

Honestly I don’t understand what’s wrong with the subscription model. You get YouTube ad free and YouTube music.

Storage is probably the easier aspect to address. Storage is cheap and decentralized storage systems have existed for decades.

The problem is bandwidth and latency. Most residential ISPs do not offer high bandwidth and low latency upstream connections, which means there’s no good way to serve the content you’re storing.

Residential fiber is becoming more common in some areas, but often those residential plans still limit upstream or specifically have terms in their acceptable use policy that forbid such activities. Here’s an example from my fiber provider, which couldn’t be clearer:

You may not use the Services to host any type of server.

It’s a little silly of course, because if you were playing a game and hosting, you’re probably hosting a server! But if I were serving videos to thousands of peers, I’m sure they would notice and take issue.

I don’t understand why your comment is downvoted. Chromium based Edge on Android is a great option.