[sneak]

I don’t hate it, but I question the use. You can use HTTP to do what it does, but better.

The modern web is opt-in. I build and use sites that aren’t SPAs and shitted up with 3p resources and images and code.

HTTP is great, and deserves our time and attention. I get that they seem upset with the modern web, and I am too - but it isn’t HTTP’s fault. It’s the sites you visit.

If you want to build new and smaller communities, I really think we should be building for browsers. Perhaps a website design manifesto is in order.

[treve]

The limits of the medium and the creativity this enforces is why people like it. It caters a niche audience with a shared set of values. I get why people don't really care for it personally or on a technical level (myself included), but it always surprises me that it's hard for people to understand that others do.

[jay_kyburz]

I agree the limitations are what makes the platform great, but I really wish they had included a simple image block in the spec.

Text only is just a little to limiting if you ask me.

[rainingmonkey]

Many browsers will render a link to an image as an embedded image block!

[MrVandemar]

> The modern web is opt-in. I build and use sites that aren’t SPAs and shitted up with 3p resources and images and code.

That is a microscopic subset of the modern web.

I don't use Gemini— though I am highly tempted —but I expect some of the attraction is that you can click on any link and pretty much guaranteed not to be socked in the face with a sign-up-for-my-newsletter or cookies-accept-all-yes-later or paragraph-ad-paragraph-ad-paragraph-ad or fiddling with NoScript to find the minimum amount of Javascript that will let you read some article that looks interesting. In Gemini, all that friction just goes away.

[sneak]

You can achieve that on HTTP with a browser extension or customized browser that checks for certain tags in the page, or disables certain features altogether. It isn’t the transport’s fault.

[bayindirh]

With all respect, this viewpoint rivals the infamous Dropbox comment.

[rglullis]

Problem: you are looking for a way to get rid of the annoying issues of the modern www. What is the solution that solves this with the least amount of work?

A) Develop a whole new transport protocol that does less than HTTP, develop client applications that use this protocol, convince a sufficient number of people to use this protocol, at least to the point where the majority of your activity happens there?

or

B) Install a handful of browser extensions that block ads and other nuisances on the modern www, and have it working right away?

[bayindirh]

Option “B” implies a cat and mouse game, which you can never win.

You can’t win a game designed and implemented by a mega corporation which is specially made to earn them money and protect their monopoly by being reactive and defending all the time. Instead you have to change the game and play with your own rules.

That’s option “A”.

[rglullis]

> Instead you have to change the game and play with your own rules.

That only works if you can convince the a substantial part of the participants to also play your game.

It's very easy to create an alternative internet where we can take away the power from incumbents. The hard part is creating all the activity that is taking place in the current one.

"Oh, but I can mirror the parts I want from the current internet into the new one!"

Not without playing into the same cat-and-mouse game.

[sneak]

Not really. You could have tinyweb/oldweb sites identify themselves with a meta tag, and have a browser that only browses those. A opt-in, web-within-a-web. And turns off js, cookies, and images.

You don’t need another transport protocol.

[_Algernon_]

The benefit with A is that it also removes higher order effects of the modern web. You may for example remove adverts by installing an ad blocker, but that wont change the incentives that advertising creates (eg. clickbait, engagement maximizing, etc.). With A you can guarantee that the content is not shaped by these incentives.

[rglullis]

> With A you can guarantee that the content is not shaped by these incentives.

Without those incentives, you will quickly find out that there will not be much of an Internet out there.

If you don't believe me, check how many people are on YouTube talking about Open Source, when PeerTube exists and already can reach millions of people.

[shakna]

Considering "B" is becoming less possible, thanks to Google dropping Manifest 2, and going out of their way to enforce a lot more tracking, "A" looks like a lot less effort - you don't have to fight FAANG.

[rglullis]

Chrome is not the only browser out there. Firefox is still a good browser. If you depend on Chromium: Brave is keeping Manifest v2 and their ad-blocking extensions work out of the box.

[fiverz]

It's not FAANG anymore, it's GAYMMAN now

[zzo38computer]

In some ways, A is easier, but not in all ways. Each has its own difficulties.

These are not the only possibilities, though; a third possibility might be:

C) Make a simpler set of features which are compatible with some parts of WWW and implement that.

However, you can do two or all three things if you want to do; you are not limited to doing only one thing. I think all three of these (A, B, C) have their own benefits, so you don't need only one.

[uamgeoalsk]

What's more fun? Definitely A.

[rglullis]

You are not solving the stated problem. You are just admitting that working on a new protocol is a masturbatory, "the journey is the reward" kind of exercise.

[Gormo]

The answer is "A". Perhaps some people are avoiding saying this too explicitly because it might sound a bit elitist, but I'll put how I see it as frankly as possible for the sake of clarity.

Gemini is not trying to solve a technical problem with the web. Is trying to solve a cultural problem that arises from the web having become a mass medium, in which every site's focus gradually erodes under pressure to optimize to the lowest common denominator.

Creating a new protocol from the ground up, and requiring users to install a distinct client to access it, isn't just about keeping the software aligned with the project's goals, it's about creating a sufficient threshold of thought and effort for participation that limits the audience to people who are making a deliberate decision to participate. It's about avoiding Eternal September, not about creating a parallel mass-market competitor to the web.

It's not about blocking the annoying ads, popups, and trackers, just to access sites where the content itself is full of spam, scams, political arguments, LLM slop, and other assorted nonsense, and instead creating an ecosystem that's "air-gapped" away from all that stuff, filled with thoughtful content produced deliberately by individuals. It's about collecting needles together away from the hay.

[_Algernon_]

HTTP is intermingled with a lot of the shitty SPAs, advertising and SEO of the web. You can make a simple text only site but the noise of the modern web is only ever a couple of clicks away. Gemini silos itself off. You know that a link you click will be an equally clean text-first site. To me that is the feature.

[mattkevan]

I’ve been exploring this problem for a while, and have been building something which I think might help solve it.

I’m currently building a browser-based static site generator that produces clean, simple code. But it does more than that.

Alongside the generated HTML, sites also publish their public configuration and source files, meaning they can be viewed in more than just a browser, for example in a CLI or accessibility device.

The client interface is also more than a CMS - you’ll be able to follow other sites, subscribing to updates, and build a network rather like a webring. The idea is to provide human-powered discovery and community tools. The reach may be less than if algorithmic, but it’s designed for genuine connection, not virality.

As the client is smart but sites are simple, sites can be hosted on anything, from the cheapest shared host up.

I’d be happy to talk further if that’s interesting in any way.

[CJefferson]

In terms of levels of current support, you would be hard-pressed to find anything better for accessibility than simple, well-formed HTML. It's better even than plain text.

[rglullis]

That sounds a bit like the dat browser, no?

[mattkevan]

Not familiar with dat browser, but I'll take a look.

You can see an early beta of what I'm thinking about here: https://app.sparktype.org/#/sites

[prmoustache]

HTTP is great but with AI crawling being all over the place maybe it is not a bad idea to publish in a safe / niche place if one is not obsessed on how much people will be reached.

I am saying this but I have no idea if AI crawlers have started to crawl gem capsules.

[Gormo]

> I don’t hate it, but I question the use. You can use HTTP to do what it does, but better.

I'm not sure I understand that. HTTP is the fundamental protocol of the web. If your goal is to create an ecosystem that is deliberately set apart from the web, how would using the same underlying tech stack help rather than hinder you in doing that?

> HTTP is great, and deserves our time and attention. I get that they seem upset with the modern web, and I am too - but it isn’t HTTP’s fault. It’s the sites you visit.

And why are those sites so awful? Did they decide to become awful from the outset, or is it because they've gradually adapted to a userbase that has regressed to the mean due to the mass-market nature of the web?

The whole point of developing a new protocol is to create a non-negligible threshold of though and effort for participation, precisely so that it doesn't get popular quickly and end up subjected to Eternal September.

[hombre_fatal]

Though there are any number of nonstandard things you can do over HTTP to restrict your community from the unwashed eternal september noobs from joining it.

Requiring a markdown content-type would probably even be enough.

Consider the fact that TFA is already proxied over HTTP just so more than 3 people will read it, so it seems more sane to be HTTP native.

[Gormo]

> Though there are any number of nonstandard things you can do over HTTP to restrict your community from the unwashed eternal september noobs from joining it.

But why would you bother with that, when your whole goal is to create an ecosystem that's separate from the web in the first place?

> Consider the fact that TFA is already proxied over HTTP just so more than 3 people will read it. Seems more sane to be HTTP native.

Podcasts are often rehosted on YouTube, blog content is often reposted to social media, etc. Making content viewable from the other medium without making it native to the other medium is a common practice, and wouldn't defeat the purpose of trying to build a distinct ecosystem on top of the same foundation that underlies the ecosystem you're trying to avoid.

[SoftTalker]

> Podcasts are often rehosted on YouTube

I actually don't know of any other way to get them. I suspect I'm not alone. That's how pervasive the dominant platforms are.

[Gormo]

> I actually don't know of any other way to get them.

You can't actually get podcasts per se at all from YouTube. YouTube rehosts podcasts as YouTube channels, and doesn't itself expose podcast feeds.

Lots of people subscribe to podcasts through Apple Podcasts, Spotify, a long tail of various aggregators, or just directly subscribing to podcast feeds in their favorite apps.

[selfhoster11]

Check the description and the channel's About page. They usually list alternative routes to get the content.

[sneak]

My argument is not to use the same stack - just the same transport. No need to reinvent the wheel. HTTP and HTML do not necessitate that you use javascript or images or even forms.