What the eff Is Gemini?(gem.ajroach42.com)
gem.ajroach42.com
What the eff Is Gemini?
https://gem.ajroach42.com/posts/2022-11-07-What-the-eff-is-gemini.gmi
97 comments
one of the "feature" of ads is that they track you in a cross website way. and as no having cookies & co, gemini makes this job a lot harder for an advertiser.
In addition, I _know_ that if I follow a gemini:// link I'm not gonna have to defend myself against aggressive JS or too much unpleasant design that I can't override, whereas you never have that guarantee on HTTP.
You can make an http web browser not store any cookies. This may limit the operation of some existing sites that rely on cookies though because they can't maintain client side session information or other state. Tracking cookies are not inherent to http. http is just the content transfer protocol. I feel like campaigning against tracking cookies within http, and advocating for http browsers to have more stringent handling of 3rd party cookies (like what Firefox offers, but maybe even more) is more likely to get wider adoption than coming up with a complete replacement for http.
Also most clients do not render images at all or only render images if you click on them. Very few clients support any kind of animations or sounds. Of course someone could still do marketing and post some text-only ads if they want to. If it is too annoying I guess I will not visit that page again. If it is not too annoying I can just ignore it and keep reading. An ad is not automatically a dark pattern.
Good, because gemini doesn't claim to solve the problems of the web. It's a different space, like IRC or emails.
Psst, thanks for all your good work keeping the riffraff out.
My response the last time your post was here: https://news.ycombinator.com/item?id=30067400#30068447
My response the last time your post was here: https://news.ycombinator.com/item?id=30067400#30068447
tiledjinn(2)
What would be your outline for a protocol that cannot transmit advertising? How would it work?
As I always say, the biggest issue I have with Gemini is TLS and encryption in general, for several reasons.
The first one is obvious: Gemini is supposed to be simple and not evolutive. TLS fits neither points.
The second one is more philosophical
From the article: "The big deal is that the modern internet sucks. It started as something to share knowledge, and quickly became a platform for survielance and exploitation". Gemini was created in reaction to that.
Now, think of what https really is for, what drove its adoption, and why the modern web needs it. And that's e-commerce! The biggest use case by far is so that you can safely send your credit card number to pay for stuff. In the early days, that's almost exclusively what it was used for. Google for instance strongly pushes for https everywhere, what do you think it is for? Your privacy or for commercial transactions?
Now, think about how to keep the commercial activity that lead to the modern web out of your little community. Ban encryption, do not mandate it! No encryption means no credit card numbers, no passwords, no accounts, no access control, you will get something that it hardly exploitable, and therefore less likely to be tainted by the "modern web". If you just want to share knowledge, there is no point hiding it with encryption.
But what about privacy? Well, you achieve that simply by not putting private information on a public network. And if you really want privacy, for example because you are about to share or browse sensitive or illegal data, then TLS is quite limited. There are networks that are explicitly designed for that use case, such as FreeNet, these are a much better option than using an encryption scheme that was primarily designed to facilitate e-commerce.
The first one is obvious: Gemini is supposed to be simple and not evolutive. TLS fits neither points.
The second one is more philosophical
From the article: "The big deal is that the modern internet sucks. It started as something to share knowledge, and quickly became a platform for survielance and exploitation". Gemini was created in reaction to that.
Now, think of what https really is for, what drove its adoption, and why the modern web needs it. And that's e-commerce! The biggest use case by far is so that you can safely send your credit card number to pay for stuff. In the early days, that's almost exclusively what it was used for. Google for instance strongly pushes for https everywhere, what do you think it is for? Your privacy or for commercial transactions?
Now, think about how to keep the commercial activity that lead to the modern web out of your little community. Ban encryption, do not mandate it! No encryption means no credit card numbers, no passwords, no accounts, no access control, you will get something that it hardly exploitable, and therefore less likely to be tainted by the "modern web". If you just want to share knowledge, there is no point hiding it with encryption.
But what about privacy? Well, you achieve that simply by not putting private information on a public network. And if you really want privacy, for example because you are about to share or browse sensitive or illegal data, then TLS is quite limited. There are networks that are explicitly designed for that use case, such as FreeNet, these are a much better option than using an encryption scheme that was primarily designed to facilitate e-commerce.
> Now, think of what https really is for, what drove its adoption, and why the modern web needs it. And that's e-commerce!
No, it's keeping the ISPs from spying on, blocking, and adding advertising to any and all data they can get into.
> Well, you achieve that simply by not putting private information on a public network.
You have no idea what information will become sensitive in a few years.
"If you're not doing anything wrong, you have nothing to hide" fails because I don't know what I'll eventually need to hide.
No, it's keeping the ISPs from spying on, blocking, and adding advertising to any and all data they can get into.
> Well, you achieve that simply by not putting private information on a public network.
You have no idea what information will become sensitive in a few years.
"If you're not doing anything wrong, you have nothing to hide" fails because I don't know what I'll eventually need to hide.
TLS doesn't prevent blocking by ISPs, it is limited in term of spying prevention (metadata are still available), it does prevent tampering by ISPs, but I think that part would be more effectively achieved with digital signatures (ex: PGP blocks) that not only prevents tampering by ISPs, but also by someone who controls the server or by forgers.
As for information you share that will become sensitive, yes sure, but if you think that, don't publish anything at all on public networks. But if you want a technical solution to still be able to post what you think is or may be sensitive in the future, then, TLS is probably not the right solution. Hacker News uses TLS for instance, and it won't help me at all if one of my comments gets me some unwanted attention, I am sure my username alone is enough to get back to me for someone with enough motivation.
As for information you share that will become sensitive, yes sure, but if you think that, don't publish anything at all on public networks. But if you want a technical solution to still be able to post what you think is or may be sensitive in the future, then, TLS is probably not the right solution. Hacker News uses TLS for instance, and it won't help me at all if one of my comments gets me some unwanted attention, I am sure my username alone is enough to get back to me for someone with enough motivation.
> TLS doesn't prevent blocking by ISPs
They can block it or they can let it through unmodified. They can't keyword-filter it and add advertisements to it.
> it is limited in term of spying prevention (metadata are still available)
Granted. However, "Your customer connected to this IP address" is much less marketable than "Your customer is reading information about stew recipes" and much less actionable than "Your customer is reading information about encryption and is therefore a traitor" and so on.
> it does prevent tampering by ISPs, but I think that part would be more effectively achieved with digital signatures (ex: PGP blocks) that not only prevents tampering by ISPs, but also by someone who controls the server or by forgers.
Digital signatures only guarantee that the data is from who it says it's from (which Gemini doesn't enforce because it specifies TOFU) and that hasn't been modified. They don't protect against spying, for advertising or any other reason. They also still rely on a cryptographic library, which undermines your point about how Gemini shouldn't be burdened with the complexity of TLS or SSL.
> As for information you share that will become sensitive, yes sure, but if you think that, don't publish anything at all on public networks.
Here, I'm not talking about what I post but what I access and read. It seems like you want to give everyone the ability to snoop on who uses the library and for what, and I have a hard time not attributing nasty motives to something like that.
They can block it or they can let it through unmodified. They can't keyword-filter it and add advertisements to it.
> it is limited in term of spying prevention (metadata are still available)
Granted. However, "Your customer connected to this IP address" is much less marketable than "Your customer is reading information about stew recipes" and much less actionable than "Your customer is reading information about encryption and is therefore a traitor" and so on.
> it does prevent tampering by ISPs, but I think that part would be more effectively achieved with digital signatures (ex: PGP blocks) that not only prevents tampering by ISPs, but also by someone who controls the server or by forgers.
Digital signatures only guarantee that the data is from who it says it's from (which Gemini doesn't enforce because it specifies TOFU) and that hasn't been modified. They don't protect against spying, for advertising or any other reason. They also still rely on a cryptographic library, which undermines your point about how Gemini shouldn't be burdened with the complexity of TLS or SSL.
> As for information you share that will become sensitive, yes sure, but if you think that, don't publish anything at all on public networks.
Here, I'm not talking about what I post but what I access and read. It seems like you want to give everyone the ability to snoop on who uses the library and for what, and I have a hard time not attributing nasty motives to something like that.
two words: “Cambridge Analytica”. It all happened over TLS.
I'll keep that in mind when I connect to Facebook's Gemini servers.
I used a household example. Try running pi-hole in your network if you don’t already. The amount of tracking and spying just about anywhere is astoundingly depressing.
Transport encryption just shrinks the number of people at the party of eating the pie of your personal data. The pie still gets eaten, just by different people. And still without your consent. And absolutely nothing is done about it.
The only tangible benefit I see from this “encryption everywhere” (which by the way mostly got triggered in the industry by Snowden files) is three letter agencies being forced to be more creative when dealing with mass-vacuumed data. Undeniably a good thing, but far from total hallelujah.
Transport encryption just shrinks the number of people at the party of eating the pie of your personal data. The pie still gets eaten, just by different people. And still without your consent. And absolutely nothing is done about it.
The only tangible benefit I see from this “encryption everywhere” (which by the way mostly got triggered in the industry by Snowden files) is three letter agencies being forced to be more creative when dealing with mass-vacuumed data. Undeniably a good thing, but far from total hallelujah.
We're talking about different threats.
If a Gemini server I connect to somehow has tracking, yes, that will track me. However, the threat I'm talking about is ISPs tracking me, which TLS protects against. It's interesting that people seem to be unwilling to see that even as a topic, and keep veering off into other discussions.
If a Gemini server I connect to somehow has tracking, yes, that will track me. However, the threat I'm talking about is ISPs tracking me, which TLS protects against. It's interesting that people seem to be unwilling to see that even as a topic, and keep veering off into other discussions.
Maybe because it was a mostly theoretical problem for most of them.
Could you supply some references about the issue which would document the ISPs tracking the users and selling their data ?
I remember of only one case of some operator in the US injecting some html, which promptly caused a massive shitstorm and they stopped. In my ~30 years of internet use, I have never seen the ISP messing up my internet connection, other than the captive portals (which now simply block me when they expire).
How big is really the problem we are paying all this worldwide complexity tax for ?
Could you supply some references about the issue which would document the ISPs tracking the users and selling their data ?
I remember of only one case of some operator in the US injecting some html, which promptly caused a massive shitstorm and they stopped. In my ~30 years of internet use, I have never seen the ISP messing up my internet connection, other than the captive portals (which now simply block me when they expire).
How big is really the problem we are paying all this worldwide complexity tax for ?
> How big is really the problem we are paying all this worldwide complexity tax for ?
How big is the problem we're paying the complexity tax of envelopes for letters for?
Certain things should be expected, culturally, and it should be a big deal if that expectation is breached. It should not be breached casually, and there should be a distinct boundary which must be penetrated in order to breach that expectation. Privacy in communication is one of those things.
Only encrypting the "sensitive" stuff marks you out as someone who we should keep an eye on, since you do things you encrypt, you're more "sensitive" than normal, upstanding people, eh? What are you hiding? How long will we have to keep you at the station to get the real answer out of you?
Also, if most traffic isn't encrypted, it's easier for ISPs to get various ideas. It's also easier for the courts to get ideas about expectations of privacy, which is an important concept under the law: Is unencrypted traffic in plain view? Why not? It isn't encrypted. Is it prima facie evidence of wrongdoing to encrypt traffic, if most traffic isn't encrypted? Why not? Why do you go to the trouble?
Finally:
> I remember of only one case of some operator in the US injecting some html, which promptly caused a massive shitstorm and they stopped. In my ~30 years of internet use, I have never seen the ISP messing up my internet connection, other than the captive portals (which now simply block me when they expire).
Given the massive uptake of HTTPS, I think I can come up with an explanation of why this is, and a prediction of what would change were HTTPS to be dropped.
How big is the problem we're paying the complexity tax of envelopes for letters for?
Certain things should be expected, culturally, and it should be a big deal if that expectation is breached. It should not be breached casually, and there should be a distinct boundary which must be penetrated in order to breach that expectation. Privacy in communication is one of those things.
Only encrypting the "sensitive" stuff marks you out as someone who we should keep an eye on, since you do things you encrypt, you're more "sensitive" than normal, upstanding people, eh? What are you hiding? How long will we have to keep you at the station to get the real answer out of you?
Also, if most traffic isn't encrypted, it's easier for ISPs to get various ideas. It's also easier for the courts to get ideas about expectations of privacy, which is an important concept under the law: Is unencrypted traffic in plain view? Why not? It isn't encrypted. Is it prima facie evidence of wrongdoing to encrypt traffic, if most traffic isn't encrypted? Why not? Why do you go to the trouble?
Finally:
> I remember of only one case of some operator in the US injecting some html, which promptly caused a massive shitstorm and they stopped. In my ~30 years of internet use, I have never seen the ISP messing up my internet connection, other than the captive portals (which now simply block me when they expire).
Given the massive uptake of HTTPS, I think I can come up with an explanation of why this is, and a prediction of what would change were HTTPS to be dropped.
Your reply doesn’t have the facts I have asked for.
So let me share what I know on why the encryption everywhere skyrocketed, and hopefully it is useful for anyone. It’s long and has some detours, to convey my point (which is outside the simple “encryption is good”/“encryption is bad” dichotomy) better.
In 2014 Snowden released the famous papers about the NSA snooping.
Following that, the IAB (the Internet Architecture Board in IETF, not to be confused with Interactive Advertising Bureau), prepared a statement here: https://www.iab.org/2014/11/14/iab-statement-on-internet-con... - which specifically mentions https://www.rfc-editor.org/rfc/rfc7258 also quickly prepared during that IETF meeting.
“Let’s encrypt”, although pre-existing, was publicly announced at the same time: https://en.m.wikipedia.org/wiki/Let%27s_Encrypt
And due to its simplicity and being free of charge you can see the stats counting up pretty happily, and it is the reason behind the current abundance of TLS: https://letsencrypt.org/stats/
In parallel, the above mentioned statement also helped ensure the http/2 and later being fully encrypted with very little being exposed. However, I return to this later in (X).
This is the factual real reason behind: the widespread agency surveillance, the revelations of which was the straw that broke the camel’s back.
There were always “evil ISPs mangling the traffic”, but they were never enough a big deal (because as I said - it’s just few disjointed industry anecdotes, and you haven’t given any factual references otherwise).
With the stated goal of encryption in transit being a barrier against the state pervasive mass surveillance - it arguably was a successful measure and I am willing to say the complexity is worth the goal.
It still doesn’t change the fact that the endpoints (and due to complicated nature of HTML/JS/CSS - much more than your expected endpoints) have the full access to your data under the encryption.
So my viewpoint is your OPSEC should not change on whether there is transport encryption or not - there were and they are the actors collecting your data; they are just different. If you specifically become an object of interest for the government, your data will be copied and analyzed. And the endpoints will be subpoenaed for the decrypted data/metadata. Pretending now things on the web are magically “secure” without these caveats is not responsible towards the users who don’t know better. Even the TOR, which is strictly stronger measure than a simple transport security, has caveats: https://tor.stackexchange.com/questions/7339/what-metadata-d...
(And I am not sure whether a simple img src on an .onion site to a non-onion source will leak your real IP these days but it was a valid attack vector at some point).
In that regard it can be argued that if your OPSEC is “trust as if all the data you send is being monitored by all possible adversaries”, then absence or presence of the encryption doesn’t matter much, and it is what the proponents of “no encryption” are saying.
(X) there is a reason involving the “evil ISP sniffing the traffic”, which http/2, formerly known as QUIC, tackled: and this is about the protocol evolution. The early internet protocols were fairly easy to snoop and man-in-the-middle with, and this gave the grounds for two kinds of devices:
1) “tcp protocol optimizers” for connections with crappy UX like satellite (huge RTT)
2) bandwidth policers. Pervasive use of poorly written p2p file-sharing apps by the internet users clogged the pipes for the ISPs, and made the more “polite” TCP traffic used by the vast majority of the users perform much worse - so it was a question of their service continuity to do something.
Since then, LEDBAT working group at IETF has tackled that at the protocol level, but something had to be done “in the moment”, and there were companies who made a good money on selling these kinds of boxes.
These both were a fairly widespread practice probably all the way before 2010, and made it almost impossible to do any modifications to plaintext internet protocols without breaking some faulty assumptions by the deployed middle boxes and thus making said evolutions impossible to deploy. (A small, much more obvious example is the widespread usage of transport-leaves NATs prevented the deployment of SCTP at internet scale until (too late) when it got UDP encapsulation…)
So, while technically it is the “ISP meddling with the traffic”, it was done for a completely different set of reasons. (As for the ISPs doing Lawful Intercept - it didn’t go anywhere with the advent of the encryption, see https://en.m.wikipedia.org/wiki/Communications_Assistance_fo...)
(Edit: formatting).
So let me share what I know on why the encryption everywhere skyrocketed, and hopefully it is useful for anyone. It’s long and has some detours, to convey my point (which is outside the simple “encryption is good”/“encryption is bad” dichotomy) better.
In 2014 Snowden released the famous papers about the NSA snooping.
Following that, the IAB (the Internet Architecture Board in IETF, not to be confused with Interactive Advertising Bureau), prepared a statement here: https://www.iab.org/2014/11/14/iab-statement-on-internet-con... - which specifically mentions https://www.rfc-editor.org/rfc/rfc7258 also quickly prepared during that IETF meeting.
“Let’s encrypt”, although pre-existing, was publicly announced at the same time: https://en.m.wikipedia.org/wiki/Let%27s_Encrypt
And due to its simplicity and being free of charge you can see the stats counting up pretty happily, and it is the reason behind the current abundance of TLS: https://letsencrypt.org/stats/
In parallel, the above mentioned statement also helped ensure the http/2 and later being fully encrypted with very little being exposed. However, I return to this later in (X).
This is the factual real reason behind: the widespread agency surveillance, the revelations of which was the straw that broke the camel’s back.
There were always “evil ISPs mangling the traffic”, but they were never enough a big deal (because as I said - it’s just few disjointed industry anecdotes, and you haven’t given any factual references otherwise).
With the stated goal of encryption in transit being a barrier against the state pervasive mass surveillance - it arguably was a successful measure and I am willing to say the complexity is worth the goal.
It still doesn’t change the fact that the endpoints (and due to complicated nature of HTML/JS/CSS - much more than your expected endpoints) have the full access to your data under the encryption.
So my viewpoint is your OPSEC should not change on whether there is transport encryption or not - there were and they are the actors collecting your data; they are just different. If you specifically become an object of interest for the government, your data will be copied and analyzed. And the endpoints will be subpoenaed for the decrypted data/metadata. Pretending now things on the web are magically “secure” without these caveats is not responsible towards the users who don’t know better. Even the TOR, which is strictly stronger measure than a simple transport security, has caveats: https://tor.stackexchange.com/questions/7339/what-metadata-d...
(And I am not sure whether a simple img src on an .onion site to a non-onion source will leak your real IP these days but it was a valid attack vector at some point).
In that regard it can be argued that if your OPSEC is “trust as if all the data you send is being monitored by all possible adversaries”, then absence or presence of the encryption doesn’t matter much, and it is what the proponents of “no encryption” are saying.
(X) there is a reason involving the “evil ISP sniffing the traffic”, which http/2, formerly known as QUIC, tackled: and this is about the protocol evolution. The early internet protocols were fairly easy to snoop and man-in-the-middle with, and this gave the grounds for two kinds of devices:
1) “tcp protocol optimizers” for connections with crappy UX like satellite (huge RTT)
2) bandwidth policers. Pervasive use of poorly written p2p file-sharing apps by the internet users clogged the pipes for the ISPs, and made the more “polite” TCP traffic used by the vast majority of the users perform much worse - so it was a question of their service continuity to do something.
Since then, LEDBAT working group at IETF has tackled that at the protocol level, but something had to be done “in the moment”, and there were companies who made a good money on selling these kinds of boxes.
These both were a fairly widespread practice probably all the way before 2010, and made it almost impossible to do any modifications to plaintext internet protocols without breaking some faulty assumptions by the deployed middle boxes and thus making said evolutions impossible to deploy. (A small, much more obvious example is the widespread usage of transport-leaves NATs prevented the deployment of SCTP at internet scale until (too late) when it got UDP encapsulation…)
So, while technically it is the “ISP meddling with the traffic”, it was done for a completely different set of reasons. (As for the ISPs doing Lawful Intercept - it didn’t go anywhere with the advent of the encryption, see https://en.m.wikipedia.org/wiki/Communications_Assistance_fo...)
(Edit: formatting).
Nothing you say engages with anything I said.
> But what about privacy? Well, you achieve that simply by not putting private information on a public network.
But what about shielding my behavior from snooping? Like my DNS queries, the web sites I visit.
I would also like to be able to identify myself and have others do so, with some assurance that nobody is impersonating me or them.
These are cases where I do want to, and must, put private (meta-)information on the public network.
But what about shielding my behavior from snooping? Like my DNS queries, the web sites I visit.
I would also like to be able to identify myself and have others do so, with some assurance that nobody is impersonating me or them.
These are cases where I do want to, and must, put private (meta-)information on the public network.
As I already mentioned, TLS is a poor choice for snooping prevention. It does offer some protection since you don't know the exact resource you are requesting, but the domain is clear. If you really need that kind of privacy, I think there are more appropriate options.
And also, why would you want to identify yourself? AFAIK, Gemini is very limited in term of uploading: there are no forms or PUT requests. The only reason I can think of would be access control, but that's something I would rather not have.
On the server side, TLS only guarantees you that you are on the right server, but not that it is the right content, that part would be better served by something like a PGP block. Another advantage of using these kinds of digital signatures is that it wouldn't force additional complexity. It is just text: the server don't have to care about that, verification can be made client-side.
And also, why would you want to identify yourself? AFAIK, Gemini is very limited in term of uploading: there are no forms or PUT requests. The only reason I can think of would be access control, but that's something I would rather not have.
On the server side, TLS only guarantees you that you are on the right server, but not that it is the right content, that part would be better served by something like a PGP block. Another advantage of using these kinds of digital signatures is that it wouldn't force additional complexity. It is just text: the server don't have to care about that, verification can be made client-side.
I also think that it is problematic that TLS is mandatory in Gemini. (I think it would be good to make it optional.) There are some other problems with Gemini as well, such as the lack of any equivalent of a (optional) "Content-Length" header like HTTP has, and that it uses Unicode, and a few other things.
I suggested using "insecure-gemini" as the URI scheme name for the non-TLS variant of Gemini.
You could have TLS and non-TLS service on the same port number, since I think that it can be distinguished from the first byte received from the client. However, TLS service programs that I have checked do not seem to have this capability.
I suggested using "insecure-gemini" as the URI scheme name for the non-TLS variant of Gemini.
You could have TLS and non-TLS service on the same port number, since I think that it can be distinguished from the first byte received from the client. However, TLS service programs that I have checked do not seem to have this capability.
Check out Spartan, it's apparently a protocol that is inspired by Gemini but doesn't have TLS.
Sorry no links, I just read about it when I was semi-active in Gemini but never bothered to follow up.
Sorry no links, I just read about it when I was semi-active in Gemini but never bothered to follow up.
My issue with the TLS requirement is the artificial limit it places on systems which can access Gemini. It's blocks small systems, anything really DIY, vintage computers, etc.
Gemini could have a really cool niche as a protocol which supports a lot of weird and wonderful systems, allowing them to be more useful and fostering a community interested in that stuff, but the TLS requirement completely prevents that.
I'd love to write a Gemini client for System 6 for example, but that just isn't feasible.
I guess my problem is partly that Gemini isn't useful to me, but even more broadly I don't understand who it's really useful for at all.
Gemini could have a really cool niche as a protocol which supports a lot of weird and wonderful systems, allowing them to be more useful and fostering a community interested in that stuff, but the TLS requirement completely prevents that.
I'd love to write a Gemini client for System 6 for example, but that just isn't feasible.
I guess my problem is partly that Gemini isn't useful to me, but even more broadly I don't understand who it's really useful for at all.
> Gemini could have a really cool niche as a protocol which supports a lot of weird and wonderful systems.
To give an example, thanks to its simplicity the IRC protocol was used for a lot of weird and creative things besides chatting. On the top of my head: bootstrapping P2P networks, controlling botnets or as a generic pubsub broker.
To give an example, thanks to its simplicity the IRC protocol was used for a lot of weird and creative things besides chatting. On the top of my head: bootstrapping P2P networks, controlling botnets or as a generic pubsub broker.
> and quickly became a platform for survielance
I think what the author meant by this is that there can be code embedded on an HTML/JS page that sends data to third parties, tracking you. HTML/JS also has cookies and numerous other features that can be used to track you.
Gemini has none of this - you ask a server for a Gemini document, you get a document, there are no cookies or JS-style embedded code involved.
> But what about privacy? Well, you achieve that simply by not putting private information on a public network.
Gemini supports client-side certificates - so you can "privatize" your capsule or a portion thereof if you want.
I think what the author meant by this is that there can be code embedded on an HTML/JS page that sends data to third parties, tracking you. HTML/JS also has cookies and numerous other features that can be used to track you.
Gemini has none of this - you ask a server for a Gemini document, you get a document, there are no cookies or JS-style embedded code involved.
> But what about privacy? Well, you achieve that simply by not putting private information on a public network.
Gemini supports client-side certificates - so you can "privatize" your capsule or a portion thereof if you want.
From [0]:
> What Gemini is doing, is saying “we don’t need no videos, images, stylesheets, nor JavaScripts, because we want to have a lightweight web experience, so we throw all that crap out!”. Fine, sounds great. But why does it require a new protocol for that? Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
[0]: https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst...
> What Gemini is doing, is saying “we don’t need no videos, images, stylesheets, nor JavaScripts, because we want to have a lightweight web experience, so we throw all that crap out!”. Fine, sounds great. But why does it require a new protocol for that? Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
[0]: https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst...
You can absolutely include links to media (images, audio, video) in a Gemini document if you want. You just have to download them to view them. Some clients will render them inline when you click on them.
> Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
- So Google/Microsoft doesn't ruin it.
- So you don't need to rely on huge applications basically emulating operating system functionality at this point with millions of LOC and opportunities for vulnerabilities just to publish some text or links.
- So you don't need to really rely on any application at all. `openssl s_connect` will get Gemini pages in a text file just fine if/as needed.
- Gemini's line format is easy to parse for scripts.
> Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
- So Google/Microsoft doesn't ruin it.
- So you don't need to rely on huge applications basically emulating operating system functionality at this point with millions of LOC and opportunities for vulnerabilities just to publish some text or links.
- So you don't need to really rely on any application at all. `openssl s_connect` will get Gemini pages in a text file just fine if/as needed.
- Gemini's line format is easy to parse for scripts.
>- So Google/Microsoft doesn't ruin it.
Google/Microsoft/etc are already shifting away from the web as we know it to HTTP/3. Once their money making properties are all QUIC/udp based it won't be long before they start depreciating tcp HTTP/1.1 support "for security" reasons. And from a megacorp/institutional/for-profit point of view that makes perfect sense.
>So you don't need to really rely on any application at all. So you don't need to rely on huge applications. Gemini's line format is easy to parse for scripts.
HTTP/1.1 can serve these same functions as Gemini with immeasurably broader support. As the commercial web switches to HTTP/3 the demographic left will reflect these aspirations.
Google/Microsoft/etc are already shifting away from the web as we know it to HTTP/3. Once their money making properties are all QUIC/udp based it won't be long before they start depreciating tcp HTTP/1.1 support "for security" reasons. And from a megacorp/institutional/for-profit point of view that makes perfect sense.
>So you don't need to really rely on any application at all. So you don't need to rely on huge applications. Gemini's line format is easy to parse for scripts.
HTTP/1.1 can serve these same functions as Gemini with immeasurably broader support. As the commercial web switches to HTTP/3 the demographic left will reflect these aspirations.
I really enjoy gemini because it is its own little world. It is the feeling of surfing the www in the 90's again. Everything is rendered the way I want it to be rendered, in whatever client I feel like using. Anyone can code their own client or server without much effort (I'm told).
It does not have to have immeasurably broader support or use standard protocols. Gemini's protocol is orders of magnitude simpler than any version of HTTP ever was and gemtext is far simpler than any version of HTML. Not everyone has to like it. Installing a gemini client is such a low barrier anyway for those that want to try one.
It does not have to have immeasurably broader support or use standard protocols. Gemini's protocol is orders of magnitude simpler than any version of HTTP ever was and gemtext is far simpler than any version of HTML. Not everyone has to like it. Installing a gemini client is such a low barrier anyway for those that want to try one.
> HTTP/1.1 can serve these same functions as Gemini with immeasurably broader support. As the commercial web switches to HTTP/3 the demographic left will reflect these aspirations.
So ... because TCP-based HTTP/1.1 might be deprecated on major browsers in the future ... then it's great that Gemini has it's own browsers (optional), application-level protocol, and port, and that it doesn't currently depend on existing HTTP infrastructure?
So ... because TCP-based HTTP/1.1 might be deprecated on major browsers in the future ... then it's great that Gemini has it's own browsers (optional), application-level protocol, and port, and that it doesn't currently depend on existing HTTP infrastructure?
I am a bit invested in Gemini on the Elixir side and am writing a few tools for it.
some comments
- Gemini don't want to fix the Web, it wants to be something else entirely
- Gemini is deadly simple, so simple that anybody with basic programming skills can write a client for it or a server. Even if nobody will use them, it's still a good exercise and you can implement the full standard not a limited subset of dubious usefulness because basically no web site will render correctly
- Gemini makes search engines an affordable problem space again
- Gemini is not trackable client side, but not necessarily ad free, just a different kinds of unobtrusive ads (I sketched some ideas)
- Gemini is very old school, it doesn't allow anything that's modern and flashy and that's its atrentgh, a subset of HTML will always be rendered on the usual big 3 browsers, it takes too much discipline to not abuse of it
- the protocol is what makes Gemini independent, by the virtue of not being subject to any external "standard committee" 100% controlled by the usual suspects
- Gemini is not cool, and that's great for some like me
some comments
- Gemini don't want to fix the Web, it wants to be something else entirely
- Gemini is deadly simple, so simple that anybody with basic programming skills can write a client for it or a server. Even if nobody will use them, it's still a good exercise and you can implement the full standard not a limited subset of dubious usefulness because basically no web site will render correctly
- Gemini makes search engines an affordable problem space again
- Gemini is not trackable client side, but not necessarily ad free, just a different kinds of unobtrusive ads (I sketched some ideas)
- Gemini is very old school, it doesn't allow anything that's modern and flashy and that's its atrentgh, a subset of HTML will always be rendered on the usual big 3 browsers, it takes too much discipline to not abuse of it
- the protocol is what makes Gemini independent, by the virtue of not being subject to any external "standard committee" 100% controlled by the usual suspects
- Gemini is not cool, and that's great for some like me
> Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
"Just use HTTP" is something I've thought about, and the idea does have merit. Python includes an HTTP server, so for getting a site up in less than a minute, it's a thought.
I'm not sure how easy it is for a browser to recognise and render new content type. I imagine it's quite difficult.
I guess I have something in mind like "gopher, but fixed".
"Just use HTTP" is something I've thought about, and the idea does have merit. Python includes an HTTP server, so for getting a site up in less than a minute, it's a thought.
I'm not sure how easy it is for a browser to recognise and render new content type. I imagine it's quite difficult.
I guess I have something in mind like "gopher, but fixed".
You can serve text/gemini over HTTP, although it is rare (I have only seen it once). (I have a old version of Firefox that I was able to customize so that it can display text/gemini files, both remotely over HTTP(S), and local files (including inside of ZIP archives).
HTTP is messy, but does have some helpful features, such as the "Content-Length" response header (if it is known; it might not always be known but if it is then it would be helpful to include it), and range requests.
I also have idea how you could serve files in any format and be able to specify a response header to interpret it (and/or linking to alternative representations, perhaps using the existing "Link" header) if the client software does not already have that capability. (The end user should also be able to configure their own interpreters, which override those specified by the server, if any.) In this way, you can use Gemini files, as well as various picture formats, audio/video codecs, etc.
HTTP is messy, but does have some helpful features, such as the "Content-Length" response header (if it is known; it might not always be known but if it is then it would be helpful to include it), and range requests.
I also have idea how you could serve files in any format and be able to specify a response header to interpret it (and/or linking to alternative representations, perhaps using the existing "Link" header) if the client software does not already have that capability. (The end user should also be able to configure their own interpreters, which override those specified by the server, if any.) In this way, you can use Gemini files, as well as various picture formats, audio/video codecs, etc.
I miss inline images in most Gemini browsers. Though, most ebooks don't have images and people love reading those.
But I love the small, human-scale web idea and I'm glad there continues to excitement around Gemini.
But I love the small, human-scale web idea and I'm glad there continues to excitement around Gemini.
Elaho on iOS and Lagrange everywhere else seem to support in-line images fine.
Does Elaho work for you? It doesn't load any content for me (iOS 15.6.1)
Loads gemini://cosmic.voyage/ships/ and other pages for me fine. (iPad Pro M1 16.2)
Thanks! I installed it on another iDevice and it worked there. No clue why it's not working on my main phone but I can live with that.
I actually made a friend I’ve been talking with a year and half of gemspace. I’m not even active on it anymore but I’m grateful it connected me to such a cool person.
Not sure if it's just me, but this did nothing to clear up "what the eff" Gemini was for me (and I also thought it was the crypto company at first). It's clear that it's a protocol but I'm unclear what I do with it or why I would use it. Is there, like, a tangible example or a screenshot that would clarify this?
The Wikipedia page (linked) is a good introduction: https://en.wikipedia.org/wiki/Gemini_(protocol)
My take
Kinder: an updated Gopher
Snarkier: a technical solution to a social problem
My take
Kinder: an updated Gopher
Snarkier: a technical solution to a social problem
After reading more, "an updated Gopher" sounds like a good summary. I am too young to have interacted with Gopher in its heyday, but I've always thought the idea was neat, and I love the idea of a closer-to-text-mode interface to this stuff. Thanks for the comment!
A tool to carve out a space without the social problem. There are phenomena on the web that can just never happen on Gemini, for better or for worse. (E.g. autoloading images) And that will keep the size of the social gathering permanently down and avoid Eternal September.
Exactly. The tech is the gatekeeper to ensure that the social group is self-selecting.
Everything that can be used to solve widespread problems in a lasting way is technical. People snark a lot about social problems and the supposed contrast with merely technical solutions, but the gap at which this gestures is that we do not have enough understanding of societies (or other large groups of people) to engineer socially technical solutions with designed consequences.
I like gemini, and have a "capsule" hosted over on sdf. Gemtext files are great for writing technical documentation.
I have a capsule hosted privately on my desktop, for speedier access. The SDF site often runs slowly.
Setting up the whole TLS security stuff is a chore, mind and will likely take awhile if/when I upgrade my system.
One thing I do have is a proxy server that serves gemtext files as gophermaps. It's a pretty simple perl script, and I've ironed out most of the bugs. That took a little while, because there were a lot of corner cases to get right.
There's an alternative protocol called Spartan, which is very very similar to Gemini, but without TLS. I wrote a little Spartan server in Go, so when I want to get an internal site up quickly, I can just "go run sss.go" and bam, there we are. I think there's also another protocol, called Mercury, that is Gemini without the TLS. I haven't heard much about it, though.
I have a capsule hosted privately on my desktop, for speedier access. The SDF site often runs slowly.
Setting up the whole TLS security stuff is a chore, mind and will likely take awhile if/when I upgrade my system.
One thing I do have is a proxy server that serves gemtext files as gophermaps. It's a pretty simple perl script, and I've ironed out most of the bugs. That took a little while, because there were a lot of corner cases to get right.
There's an alternative protocol called Spartan, which is very very similar to Gemini, but without TLS. I wrote a little Spartan server in Go, so when I want to get an internal site up quickly, I can just "go run sss.go" and bam, there we are. I think there's also another protocol, called Mercury, that is Gemini without the TLS. I haven't heard much about it, though.
My main issue with Gemini remains the hard requirement of TLS. It makes it useless in a bunch of situations where it could actually excel.
I guess ultimately it doesn’t matter, Gopher has more content, more services, and more users.
I guess ultimately it doesn’t matter, Gopher has more content, more services, and more users.
Afaik Gemini has considerably more active use than Gopher does at this point (I use both)
I abandoned gopher several years ago because I had to rely on proxy servers for access from the web. But at least lynx [1] supports the gopher protocol. Gemini requires either a niche browser or reliance on a proxy. No thanks...
[1] https://en.wikipedia.org/wiki/Lynx_(web_browser)
[1] https://en.wikipedia.org/wiki/Lynx_(web_browser)
You're apparently fine using a HTTP browser for browsing HTTP, but for some reason you refuse to use a Gopher browser to browse Gopher.
I don't get it. Why can't you just realize "I am not interested in Gopher" and move on?
I don't get it. Why can't you just realize "I am not interested in Gopher" and move on?
> Gemini requires either a niche browser
You mean like Lynx?
You mean like Lynx?
Lynx is the oldest web browser still under development. It is also arguably the best gopher browser. It is a standard utility available on a host of *nix and other platforms. I started using it 25 years ago as a DOS port...
I hate to say this, but it’s a poor choice of names. It’s going to be overshadowed by the crypto company.
I'm not a huge fan of the protocol but I do believe it will survive the crypto company.
I have been hearing about the protocol for at least 2 years but never heard of a crypto company.
I would say the name is rather unfortunate in the sense that any search will lead you first to the NASA program and zodiac signs.
I would say the name is rather unfortunate in the sense that any search will lead you first to the NASA program and zodiac signs.
When I click the link gemini://cities.yesterweb.org/ in my Safari browser, it launches an installed app I have named Gemini.
What even is "small" or "human scaled" when dealing with tools such as computers? I still can't figure it out. It seems to depend on how much leverage one gets from the computer, and any insistence on human-scaling is prone to underestimate that. The Web is definitely too large for comprehension, to be clear, but there is more room to play in than used by Gemini.
I don't have any problems with TLS; one probably already has OpenSSL around. More or less TLS is too big (in popularity) to fail - there are smaller implementations like BearSSL too. If it really is an issue, one has a perfectly fine protocol removing the TLS wrapper; it won't be Gemini though.
I don't have any problems with TLS; one probably already has OpenSSL around. More or less TLS is too big (in popularity) to fail - there are smaller implementations like BearSSL too. If it really is an issue, one has a perfectly fine protocol removing the TLS wrapper; it won't be Gemini though.
I have to admit gemini leave me confused as well.
gemini is a simple easy to understand protocol.
simpler then http? a specification of which I can put in this comment?
http: a bunch of newline separated key=value pairs followed by a double newline everything else is the content.
gemini is a simple easy to understand protocol.
simpler then http? a specification of which I can put in this comment?
http: a bunch of newline separated key=value pairs followed by a double newline everything else is the content.
your description specifies the syntax, not the semantics of the key/value pairs nor the protocol state machine.
A fair point but my point is that http is a very simple easy to use specification, and for content html can be a very simple easy to use document format, gemini is fine, I think it is great that people are having fun on the internet, you will however have a hard time convincing me that http/html is too complicated. Note that html can be too complicated, but it does not have to be, not everything needs to be some sort of monstrous framework heavy single page javascript encumbered anomaly.
> Note that html can be too complicated, but it does not have to be, not everything needs to be some sort of monstrous framework heavy single page javascript encumbered anomaly.
The philosophy of Gemini seems to be that it's not enough that people can create Gemini's austere's experience with the web, but that everyone must be forced to conform. I guess "punk" has lost all of it's meaning.
The philosophy of Gemini seems to be that it's not enough that people can create Gemini's austere's experience with the web, but that everyone must be forced to conform. I guess "punk" has lost all of it's meaning.
> but that everyone must be forced to conform
One thing I like about smolweb stuff, including Gemini, is that they really aren’t being gatekeepers. Sure, they have strong opinions (and they encode them in protocols) but it comes off like a DM trying to make a good campaign.
One thing I like about smolweb stuff, including Gemini, is that they really aren’t being gatekeepers. Sure, they have strong opinions (and they encode them in protocols) but it comes off like a DM trying to make a good campaign.
You're free to express yourself within the technological limitations. Sometimes that's more freeing than having an overload of functionality. It also makes it more of an open platform because anybody can re-implement it if they want. That's plenty "punk" to me.
Alternatively, use the flying spaghetti codebase monster duopoly, also known as Chromium and Firefox.
Alternatively, use the flying spaghetti codebase monster duopoly, also known as Chromium and Firefox.
Or you can, like, ensure that the HTML content you write is usable in lynx or w3m. I do.
>You're free to express yourself within the technological limitations. Sometimes that's more freeing than having an overload of functionality. It also makes it more of an open platform because anybody can re-implement it if they want. That's plenty "punk" to me.
Being satisfied with expressing oneself within technological limitations has never been "punk."
Punk is pushing a system to its bleeding edge, breaking it, undermining it, using it in ways it was never intended for and not giving a damn about keeping things tidy. The web in all its hypercomplex madness and ugliness is far more punk than Gemini is even capable of being. Gemini doesn't even allow site authors control over the design or layout of their content - that's entirely implemented by the browser.
Punk is rebellion against authority and systems of control, while Gemini is rebellion against freedom and the imposition of control for the sake of ascetic minimalism. Punk is anarchy, while Gemini is orthodoxy. It gets points for being anticapitalist, though.
Being satisfied with expressing oneself within technological limitations has never been "punk."
Punk is pushing a system to its bleeding edge, breaking it, undermining it, using it in ways it was never intended for and not giving a damn about keeping things tidy. The web in all its hypercomplex madness and ugliness is far more punk than Gemini is even capable of being. Gemini doesn't even allow site authors control over the design or layout of their content - that's entirely implemented by the browser.
Punk is rebellion against authority and systems of control, while Gemini is rebellion against freedom and the imposition of control for the sake of ascetic minimalism. Punk is anarchy, while Gemini is orthodoxy. It gets points for being anticapitalist, though.
> Gemini doesn't even allow site authors control over the design or layout of their content
Of course not. End users should have control of their experience. Why should someone else get to control what my software does on my machine? Why should some designer somewhere be the authority? I'm going to pick the fonts and colors and styles I want.
Seems like a pretty punk-rebellious attitude to me.
Of course not. End users should have control of their experience. Why should someone else get to control what my software does on my machine? Why should some designer somewhere be the authority? I'm going to pick the fonts and colors and styles I want.
Seems like a pretty punk-rebellious attitude to me.
>Why should someone else get to control what my software does on my machine?
For the same reason someone else gets to control the layout of a magazine you buy. The browser is yours, but the page you're accessing is not. It is the creative expression of someone else, why should they not have the right to express themselves freely? Why are you insisting on absolute creative freedom and editorial control over other people's property?
I mean, ignore javascript entirely. Why should someone publishing to Gemini not be able to set the background and font on their site? Gemini doesn't even allow even the tiny bit of individualism offered by the old web.
>Seems like a pretty punk-rebellious attitude to me.
You're view is literally rebelling against other people's freedom because what they do might not suit your tastes, and you don't feel others should have the right to violate your sense of aesthetics. Wanting to control everything isn't punk, it's textbook authoritarianism.
But I doubt we're going to see eye to eye on this.
For the same reason someone else gets to control the layout of a magazine you buy. The browser is yours, but the page you're accessing is not. It is the creative expression of someone else, why should they not have the right to express themselves freely? Why are you insisting on absolute creative freedom and editorial control over other people's property?
I mean, ignore javascript entirely. Why should someone publishing to Gemini not be able to set the background and font on their site? Gemini doesn't even allow even the tiny bit of individualism offered by the old web.
>Seems like a pretty punk-rebellious attitude to me.
You're view is literally rebelling against other people's freedom because what they do might not suit your tastes, and you don't feel others should have the right to violate your sense of aesthetics. Wanting to control everything isn't punk, it's textbook authoritarianism.
But I doubt we're going to see eye to eye on this.
> But I doubt we're going to see eye to eye on this.
It does seem unlikely - our perspectives are so different! - but it's an interesting conversation. Thank you for engaging.
You seem to be conflating the concepts of property ownership and copyright. We're not disagreeing about the idea of controlling other people's property, but about whose property it is.
The magazine example is a good one: the publisher owns the masters, and retains the copyright, but the copy of the magazine - the physical object I bought - is no longer the publisher's property, but mine, to do with as I please. If I want to mark it up, cut it up, or dust off my decades-obsolete paste-up skills and entirely redo its layout, that's my right as the owner of that copy of the magazine.
The same is true on the web. The original page, on the server you own, certainly is your property: but when I visit your site, and my browser downloads a copy of the page, that new copy, stored and processed on my computer, belongs to me. You retain the copyright, but you do not own the copy, and I am free to munge its bits in any fashion that suits me, because I own it.
> Why should someone publishing to Gemini not be able to set the background and font on their site?
It would be contrary to the purpose of the medium. It's like complaining that a haiku magazine won't publish your sonnet, or a podcast site won't host your videos; that might well be a fine thing to do, but this is not the place for it.
> Gemini doesn't even allow even the tiny bit of individualism offered by the old web.
Yeah, it's maybe less like the old web and more like "what if the old plain-text Internet, and the BBS scene before it, had developed into a hypertext medium?"
It does seem unlikely - our perspectives are so different! - but it's an interesting conversation. Thank you for engaging.
You seem to be conflating the concepts of property ownership and copyright. We're not disagreeing about the idea of controlling other people's property, but about whose property it is.
The magazine example is a good one: the publisher owns the masters, and retains the copyright, but the copy of the magazine - the physical object I bought - is no longer the publisher's property, but mine, to do with as I please. If I want to mark it up, cut it up, or dust off my decades-obsolete paste-up skills and entirely redo its layout, that's my right as the owner of that copy of the magazine.
The same is true on the web. The original page, on the server you own, certainly is your property: but when I visit your site, and my browser downloads a copy of the page, that new copy, stored and processed on my computer, belongs to me. You retain the copyright, but you do not own the copy, and I am free to munge its bits in any fashion that suits me, because I own it.
> Why should someone publishing to Gemini not be able to set the background and font on their site?
It would be contrary to the purpose of the medium. It's like complaining that a haiku magazine won't publish your sonnet, or a podcast site won't host your videos; that might well be a fine thing to do, but this is not the place for it.
> Gemini doesn't even allow even the tiny bit of individualism offered by the old web.
Yeah, it's maybe less like the old web and more like "what if the old plain-text Internet, and the BBS scene before it, had developed into a hypertext medium?"
Really, now? Since when is anyone being "forced to conform"? It's an alternative protocol stack that people can use if they want. I don't see anyone saying "you have to use Gemini, or else" - but I do see people attacking it for being its own thing, rather than part of the web.
yes, the argument goes that because html can be too complicated gemini was designed to actively prevent and limit these complications. Of course html can be used in a simple gemini- or gopherlike way as well. But some purists want nothing to do with the complexities, distractions from and corruption of pure textual information.
> http: a bunch of newline separated key=value pairs followed by a double newline everything else is the content.
This is a webdev's idea of what HTTP is
This is a webdev's idea of what HTTP is
And... I have built http servers in shell, really, that is all it has to be, It can, and usually is more, but it is trivial to build a simple http server. in fact that is sort of the genius of http, how simple and human readable it is.
I think that NNTP making a comeback would be better than a simpler HTTP or adding more features to Gopher. But people can already have that with a Reddit clone or phpbb.
As the saying goes, I support the rhetorical goals of this creator — but I would be hesitant to tout as an anti-capitalist project something that actively forbids personalization.
In what way does it forbid personalization? Is it because the client enforces styling?
I got around that in my (deactivated) site with some ascii art and unicode glyphs.
Most capsules are quite distinct with regards to these elements.
I got around that in my (deactivated) site with some ascii art and unicode glyphs.
Most capsules are quite distinct with regards to these elements.
jslql(2)
> Gemini is the web reimagined through the lens of human scale anticapitalism. (Emphasis added)
IMO, I'd much rather have a web that is anticommunist. The gatekeepers today act quite a bit like a politburo and the "content" that is allowed feels a bit like Pravda's editors were involved.
IMO, I'd much rather have a web that is anticommunist. The gatekeepers today act quite a bit like a politburo and the "content" that is allowed feels a bit like Pravda's editors were involved.
Who are the “gatekeepers” stopping you from running a webserver with whatever “content” you want?
Gemini has even fewer gatekeepers than the normal web. There aren't any corporations trying to establish themselves as "the AOL of Gemini" or whatever. If it leans in any direction it's anarchist.
gemini like http is decentralized
The gatekeepers are exclusively capitalist companies.
You realize one of the goals of capitalism is to replace all public services with private, for-profit ones?
You realize one of the goals of capitalism is to replace all public services with private, for-profit ones?
There are plenty cases where I have no problem with private companies and their products. But software is one situation where I just can't convince myself anymore to buy perpetual licenses for, when it's blackbox, and usually spyware. And they go the extra mile to handicap it for profit, when the MVP would be cheaper without it anyways.
The only things I think are worth paying for digitally are art, games (which I guess are art), and services. But I'm not paying a license for a text editor, for example. Running proprietary code feels... subpar and janky, I guess?
The only things I think are worth paying for digitally are art, games (which I guess are art), and services. But I'm not paying a license for a text editor, for example. Running proprietary code feels... subpar and janky, I guess?
See also a longer form writeup of similar issues: https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst...