💾 Archived View for bbs.geminispace.org › s › Gemini › 4947 captured on 2023-09-08 at 16:25:58. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
The purpose of this essay is to sketch out the notion that Gemini is and should be understood as a growing family of allied protocols. In doing so, I will address much of what counts as anti-Gemini criticism.
::: N.B. 1: By "Geminispace" I mean the totality of the Gemini network and its realized and yet to be realized possibilities, not the service called "geminispace.org" run by skyjake. :::
::: N.B. 2: The first draft of this article was completed 6 months ago. For reasons of time, I'm not going to re-find and provide links. If you have been poking around Gemini for a while, you'll have seen many of the things I mention. In the end this is more of a think piece than an academic paper. :::
Here is how some critics have characterized the Gemini Protocol
This essay will explain how thinking of Gemini as a Bootstrap Protocol will help us get around various dead-end thinking the critics above have been engaging in and encouraging.
You will see that the Gemini Protocol is
A network with sufficient capacity to regenerate itself is a bootstrap network. To be a bootstrap network, Gemini needs a few things:
Presently we are lacking only a code repository, but @skyjake is apparently working on that (circa early 2023).
Ignore for the moment the fact that the above list does not include things like compilers; obviously by "bootstrap" I do not mean Gemini appears *sui generis*. Rather I mean that Gemini could re-specify itself, and recode itself from within itself.
Not only is the Gemini network bootstrap, so is the protocol. It is easy to understand, learn from, and adapt, and thus lays the groundwork for anyone play with. In this sense, the Gemini protocol is akin to Adorino (the programmable chip system popular with hobbyists) except for a web-like experience. Gemini protocol is sufficient to produce Geminispace, and Geminispace is sufficient to facilitate any number of projects and experiments within that space--including modifying Geminispace.
But this sufficiency is limited. There is a great deal that Gemini cannot do, was not made to do, and given its uncompromising restrictions, will *never* do. This is because Solderpunk designed Gemini as a <u>compromise resistant</u> protocol in part by making it *no-version*, meaning there will never be a version 2 of the Gemini protocol. It is meant to stay what it is, forever.
Let's examine some reasons why that is.
The attraction of a no-version protocol derives in part from how Gopher survived pretty much as it began, eventually coming to serve as a cultural counterpoint to the now bloated and decadent HTTP web. Part of that was, no doubt, due to public indifference to the Gopher protocol. Most people by 1995 were already engaging with and excited by the much more dynamic world of HTTP. But it was also because the Gopher protocol, like most of the important original Internet protocols (ftp, nntp, mail, etc) were highly resistant to change. HTTP changed a lot, against all odds, and not necessarily for the better, primarily because of major corporate influence to squeeze ever more "productivity" from the protocol. The consequence of this has been dramatic: convenience and fun that thinly veils a totalitarian web that spies on everyone, exploits everyone, deranges everyone, and ultimately harms everyone. Gopher, because it "failed", never adapted (like pretty much all the other old protocols). And because it never adapted, it retains some of the spirit of the old network. At the very least, it doesn't actively try to secretly poison you.
This is the underlying significance of Gemini being a no-version protocol. Like Gopher, it promises a slice of the "old world", in part because it will never change.
As HTTP developed and grew, it came to outpace the individuals who built and populated it. Today it is no longer possible *even for corporations* to write a fully featured web browser. There are only three browsers in the world with any significant market share. Google Chrome and its variants hold about 75% of market share, while Firefox, the only multi-platform alternative (Safari is Apple-only), has less than 3% market share.[Source] If Firefox disappears, the web will be dominated by one company, with the only alternative a trick used to enforce software ecoysystem lock-in (Apple).
[Source]: Usage share of web browsers (Wikipedia)
It is in light of this that feature creep takes on *political* dimensions. Every new feature of the web has reduced the autonomy of the individual to face off against the power of corporations and governments. Why? Because at a certain point, the individual cannot implement the feature-set. Because of this, today the individual has practically no power on the web, and is merely a subject to feudalistic powers vying for digital rulership over the entire globe. And even the ruling population is shrinking fast (i.e., even Internet Explorer is dead).
Meanwhile, through it all, Gopher remained a human-scale network. What are some of its features?
1. Human-scale protocol: easy to understand and implement, even with its growing list of exceptions and hacks.
2. Human-scale native format, plaintext: easy to type into any text editor. No machine-driven visual noise in the format, like HTML, CSS, Javascript, XML, or JSON.
3. Human-scale network: Gopher is essentially a network of lists of links. It is more like web rings or the curated web, with each entry manually placed, or at least appearing at a pace at human scale.
Gemini has reproduced all of these. Notably, Gemtext extends plaintext into the modern era with very simple markdown that retains Gopher functionality and degrades gracefully to plaintext. By using TLS, Gemini extends basic privacy guarantees to the end-user. (Ignore for the moment Gemini's controversial TOFU arrangement with TLS).
Being no-version means that the Gemini protocol, like Gopher, can never get more sophisticated than it presently is. It can never grow beyond human scale. But being more modern than Gopher (TLS, UTF-8, etc.) means the space for innovation is greater than that network. Because it is modern, we can do more within Geminispace than Gopherspace.
As I said, a bootstrap protocol enables the creation of other protocols, or *allied protocols*. Gemini is so simple, any number of other allied protocols can be derived from it, by adding or removing a feature. Allied protocols are good for getting the functionality we want out of Gemini without altering the Gemini protocol itself. They advance Geminispace, without losing Gemini.
We can even see that Gemini is an allied protocol of Gopher. Gemini derives from Gopher by adding TLS, Gemtext, UTF-8, and other various bits and pieces including a rationalized set of error codes. Spartan derives from Gemini by removing TLS but keeping everything else. What distinguishes allied protocols from other protocols is that they degrade gracefully into one another. Gopher, Gemini, and Spartan are each only a feature or two away from being identical, and thus share much of the same infrastructure.
::: *Protocol Smearing:* the way allied protocols can interoperate and interpret one another with a high degree of accuracy, owing to their proximity. For example, Gemtext renders in an intelligible way in Gopher. Try reading typical HTML or JSON documents in Gopher. :::
We see this in Gemini browsers which often allow users to browse Gemini and Gopher spaces. Gemtext looks reasonable on Gopher, even if it doesn't parse the way it's supposed to. Notwithstanding the fact that the protocols live on separate ports, any Gemini browser can parse the simple text and link lists of Gopher.
Bootstrap protocols can also inspire entirely different protocols, like Titan (for uploading to Geminispace) or Misfin, an email replacement for the small web. So long as these protocols themselves are equivalently simple, they too are allied to Gemini. They fit together with Gemini like puzzle pieces to provide a richer ecosystem.
Development in one protocol necessarily extends the spaces of the other allied protocols, without disrupting their existence. This is very much like the relationship between HTTP and Gopher. HTTP brought a lot of innovation, almost none of which touched Gopher. What's different this time around is that the protocol itself is in question. This is Gemini's fundamental cultural innovation. It's not just "what can we transmit via this protocol" but "what protocols like this can we invent to make new forms of transmission possible?"
(Maybe just as important: what protocols of the past can be saved from oblivion?)
There is a great deal of resistance to introducing features to Gemini. Part of this is understandable, as many people are sick of the featureful decadent HTTP/S web. Partly it arises from misunderstandings. But either way, it's an unnecessary concern because we've all already agreed to not change the Gemini protocol. Instead of saying no to innovation, we need to conceive of innovations in Geminispace in two ways, as a
1. **Network enhancement:** An innovation that works *within* the Gemini protocol. For example, adding Markdown to Gemini fits perfectly within the scope of Gemini's MIME type capabilities. It is also something the protocol designers were not against.
2. **Protocol enhancement:** An innovation that requires changing the Gemini protocol. *Since we don't change the Gemini protocol, we add an allied protocol.*
This is an example of a network enhancement.
People get anxious about the idea of Markdown in Geminispace. Some claim it is antithetical to Gemini. (It isn't, as you shall soon learn.) Sometimes this anti-Markdown sentiment comes from outside Gemini. For example, some don't like Markdown because some of its features don't conform to their idea of a "semantic web". I don't find this argument compelling in part because the "semantic web"--as a way of making human documents machine-readable--is ideologically inappropriate to Gemini anyway.
More compelling critical observations about Markdown in Gemini came from within the Gemini mailing list itself, as the protocol was being specified, mainly by Solderpunk and Sean Conman.
Sean Conman argued that there were too many versions of Markdown:
"The issue I have with Markdown is that there is no one standard for it."
---Sean Conman, Gemini mailing list (Sun Aug 18 22:32:53 2019)
This sounds like a good reason, but really isn't. An obvious solution is to just pick the best, or best-supported flavor. Both CommonMark and Github-flavored Markdown qualify as top candidates. Gemini could have picked one and made it the protocol standard.
But it isn't so easy. Since Gemini by design doesn't have HTML, what is Markdown supposed to render to? For example, \*\*bold\*\* renders to \<strong\>bold\</strong\>, which is then rendered by the browser to **bold**. But Gemini doesn't have HTML, and nothing is going to change about that. Solderpunk:
It's occured to me that I don't think Markdown or any similar language has ever been specced in any way other than specifying how to translate it to HTML. Which, as JFM has mentioned, is a whole tech stack we don't want or need. How do you write a spec explaining how to render itemised lists in Markdown into plain text suitable for printing in a terminal? That's way fiddlier than speccing how to translate it into HTML and let the browser worry about wrapping and indenting.
---Solderpunk, Gemini mailing list (Mon Aug 19 18:15:07 2019)
A major problem for using existing Markdown solutions is that they almost all use HTML as a render target. That means almost no existing Markdown solution could be used by Gemini devs.
If Gemini doesn't have HTML, what would Markdown render to? For terminals, it will be some mix of ANSI codes and text formatting. For graphical interfaces, though, it would have to be something else since ANSI codes aren't native. And probably it would be many different things, for each different windowing environment.
To help solve this problem, b__m__e suggested using an intermediary representation called AST, which can then output useful variations for different circumstances:
If that route were chosen, I think we would need to create parsers that return an AST in a variety of languages and make the libraries available to developers to use in their gemini projects. This would be a pretty big undertaking and I do not know that it is exactly in scope.
---b__m__e, Gemini mailing list (Sun Aug 18 23:37:57 2019)
Solderpunk responded to this, agreeing it is not in scope:
I like Markdown as much as anybody but this feels massively out of scope to me. We have already defined a way for Gemini to serve Markdown (just by specifying text/markdown). It's not our fault if nobody knows what that means.
---Solderpunk, Gemini mailing list (Mon Aug 19 18:15:07 2019)
Tomasino agreed:
Let Gemini stay simple. End the spec there and let clients decide what to do with the markup, if it's used at all. In another year the markup of the masses may change. We don't need to bundle that into Gemini from the beginning.
---tomasino, Gemini Mailing list ( Mon Aug 19 15:23:53 2019)
In the end, it was agreed to pencil-in Markdown via a MIME-type specification (text/markdown) and leave it to future developers to figure out how that would work.
What does this tell us? That Markdown is not antithetical to the Gemini Protocol. It was left out for a few good reasons:
1. Adds too much immediate complexity to the spec.
2. Makes first generation browsers too hard to code.
3. No obvious target to render to. <- The *real* problem.
4. Gemini has the `text/markdown` MIME-type that offers future developers an opportunity to solve the problem, if it is solvable.
These are good reasons to have settled on Gemtext as the protocol document, but they are not good reasons not to have Markdown today. Markdown isn't protocol breaking. It is an idea that can fit comfortably *within* Gemini space as it is, and should be an ambition of Geminispace because of the benefits of Markdown.
(Benefits like: more than 3 levels of headers and nested lists, *which this very post requires*, proving that such features are not desired outlandishly but represent a practical requirement of long-form writing.)
This is an example of a protocol enhancement.
As part of his restrictive protocol design, Solderpunk chose to limit himself to a single method: GET, with a restriction of 1024 bytes. This was hacked by Solderpunk into a way of sending up to 1024 bytes to the server. And so, we find services all over Geminispace that use GET to send data to servers. At least, that's how I understand it.
This has two unfortunate consequences. The first is that much of Geminispace is a Twitter-clone for anyone who doesn't have a hosted capsule. All your thoughts have to fit inside ~700 characters, or they don't go through to services like Geddit or Station. This has seemed to me to be a flaw of the Gemini protocol, amplified by cultural indifference in the fact that the average person is not able to host their own servers, for a variety of reasons, ranging from a lack of technical aptitude to security concerns. (Try securing a domain name without getting on a list!)
The second unfortunate consequence is that people hold onto this limitation with religious fervor. "No you may not dream of posting more than ~700 characters! How dare you change the Gemini Protocol!" My response is that ~700 characters is not enough space for a reasonable thought, no matter what the Twitter mobs have told you.
The fact Gemini only has one method, GET, is a consequence of a decision pertaining to the Gemini Protocol, does not justify the ~700 limit in interaction. But there is yet another refrain: "Gemini is a read-only protocol." Well, if this were true, then why does the protocol include a method for sending data to the server *at all*? It seems Gemini is a grab-bag of contradictions., which are sorted through by advocates of various sides to confirm one bias or another. It's probably no different for me.
But there is a way around all these issues: enter the **Titan Protocol**, which enables file uploads to servers. At first I thought this would be the solution to everything. But I found (in late 2022 / early 2023) few services used it, and I never got it to work the one time I tried. I quickly came to the conclusion that Gemini+Titan wasn't providing a solution at all.
However, my opinion has recently (early 2023) changed with the appearance of Bubbles, a social media application by @skyjake. This software enables users to upload long posts easily using Titan. This proves that Gemini+Titan is a plausible solution to the problem of long posts. The problem is finally solved, and Gemini purists can sleep easily knowing the Gemini Protocol has not changed.
This is a good example of using an allied protocol to solve a limitation of Gemini without breaking its protocol. Gemini doesn't change, Titan is simple and easy to implement (at least when somebody shows you how it's done). Together, they solve a general use-case that is essential for growing a strong community of users whose minds require more than ~700 characters. (Like *this* post.)
Although Gemini is no-version and will always remain human-scale, a family of allied protocols could grow beyond human scale. If we add more and more features, each with their own protocol, eventually there will be so many features and protocols that it will become infeasible for a single developer or even a small team of motivated devs to code up the full spec.
For that reason, Gemini serves as a good <u>discipline</u> for protocol developers: if a protocol can pretty much fit inside Gemini (except for this one or two features that will extend it in an interesting direction), then it will be human scale; and whatever falls outside it will probably remain human-scale, too. Even if an allied protocol becomes bigger than human scale, we will always have Gemini to retreat to.
Is it possible that a flotilla of Gemini-adjacent protocols might become controlled by a corporation, leading to a gradual contamination of principles that eventually breaks Gemini? Yes, but with highly reduced probability so long as the allied protocols put Gemini first. If they do that, the contents of the Gemini Alliance will always be available and degradable to a new human-scale network.
For this reason, the continued existence of Gemini-as-it-is serves as political error correction: so long as Gemini remains what it is, and so long as allied protocols put Gemini first, the contents of the Gemini Alliance will always be a hop, skip, and a jump away from Gemini itself, and will remain forever human-scale--*until one day it isn't*.
On that day, the day of Grand Politics in Geminispace, the community will split between the astronomically ballooning post-Gemini space controlled by governments, corporations, and probably AI, on the one hand, and the Gemini Patriots who fight to maintain Geminispace as the human-centric smallweb that it presently is. This will involve information warfare, and making hard decisions about who gets to stay and who has to leave.
We should not fear this future. Instead of playing it safe today in the hopes of avoiding such a confrontation, we should live dangerously in expectation that this day will inevitably come. We need Geminispace to be actively resistant to any such takeover, now or in the future. But we also need it to be dynamic and growing in the right ways.
Even if we can build upon the Gemini Protocol without destroying it, it can be instructive to examine another small protocol that has developed very differently: Nostr.
Nostr *was* a very simple microblogging protocol. It was designed sidestep the centralization tendencies of both Big Tech like Twitter and the Fediverse (Mastadon) by placing identity in the hands of the individual poster. Technically, users send their content to relays, which then send them on to clients. A user can send their content to any number of relays, thus no single relay can block a user's content. Likewise, no relay can take away a user's digital identity, since they control the private keys on their own device.
The protocol "event" involves sending an almost absurdly simple JSON file ([Source]):
{
"id": "b9fead6eef87d8400cbc1a5621600b360438affb9760a6a043cc0bddea21dab6",
"kind": 1,
"pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
"created_at": 1676161639,
"content": "this is going to work",
"tags": [],
"sig": "76d19889a803236165a290fa8f3cf5365af8977ee1e002afcfd37063d1355fc755d0293d27ba0ec1c2468acfaf95b7e950e57df275bb32d7a4a3136f8862d2b7"
}
[Source]: protocol from the Nostr website
[From the Nostr website]:
Nostr at a high level
* There are two main components: clients & relays. Each user runs a client. Anyone can run a relay.
* Every user is identified by a public key. Every post is signed. Every client validates these signatures.
* Clients fetch data from relays of their choice and publish data to relays of their choice. Relays don't talk to one another, only directly to users.
* For example, to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.
[From the Nostr website]: the Protocol
Because it used encryption and was decentralized by design, Nostr has attracted the attention of web3 enthusiasts in 2022, even though it featured no blockchain or crypto currency or token. Ironically, after 15 years of building pie-in-the-sky blockchain "solutions" that went nowhere, Bitcoin enthusiasts found their Twitter-killer in this almost ridiculously simple protocol. The nostr.com website brags Nostr is "a decentralized social network *with a chance of working*" \[emphasis mine\], underlining the incredible failure of web3 to even produce one social network anybody cared about. @jack, co-founder and former CEO of Twitter, declared it as one of only three significant decentralization and anti-censorship technologies currently available, alongside Bitcoin (of course) and ....? *I forget.*
But the milk quickly soured when it was discovered in 2023 that Nostr was highly vulnerable to spam. The generally accepted solution to this has been to turn to pay relays.
If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays. ([Source])
The obvious consequence of this has been a trend toward centralization of traffic around a much smaller number of super relays. Nostr enthusiasts are fine with that:
For the network to stay healthy, there is no need for hundreds of active relays. In fact, it can work just fine with *just a handful*[.] (Emphasis mine [Source])
And with this, the possibility of censorship and deplatforming returns. In other words, the very problem Nostr was designed to solve came in through the back door. And since payment the payment method of choice for the Nostr network is Bitcoin, if you are not proficient in that cryptocurrency you are now effectively a second class citizen of the Nostr network.
But how did Nostr become attached to the Bitcoin network? Wasn't it supposed to be a ridiculously simple *microblogging* protocol? It was, until Bitcoin enthusiasts latched onto Nostr as their dream protocol and turned it into the Microblogging Department of the Republic of Bitcoin.
Whereas the Gemini Protocol was cooked up by Solderpunk and Sean Conman and a few others on a mailing list, **Nostr established itself in a very different way, offering itself up as an "open protocol" which meant that it was open to innovations agreed upon by the community, and instantiated in its github repository--just like open source software.** Nostr now has dozens of significant amendments--"Nostr Implementation Possibilities" or NIPs--to add various features. Some of these flesh out microblogging basics like contact lists (NIP-02), event timestamps (NIP-03), encrypted direct messages (NIP-04), handling mentions (NIP-08), and event deletion (NIP-09). Other nips extend Nostr *along the web3 plane*: Nostr marketplace (NIP-15), Nostr Wallet Connect via the Lightning Network (NIP-47), Lightning Zaps (NIP-57).
What we observe with Nostr is the *danger* of innovation in a small protocol
1. Thoughtless, rapid, and unfettered "innovation" that bolts on any and all "features" that magically leads back to centralization and censorship the protocol was ostensibly designed to solve,
2. Spiritual capture by a motivated group whose mania leads twist the protocol to serve their cult-like interests. With Bitcoin enthusiasts that means transforming every human interaction into a microtransaction--a "zap".
Instead of solving the problem of centralization and censorship Nostr now serves the interests of Bitcoin enthusiasts who see no problem with centralization and censorship on Nostr *because they can pay to be first class citizens of the network* through the very payment mechanisms which they have engineered into the protocol. Fundamental problems with the protocol--like spam--will just be papered over--with recentralization--so enthusiasts can move onto the important thing: sending Bitcoin "to the Moon!" To satisfy this more fundamental purpose, Nostr must to scale up as quickly as possible, no questions asked, no matter the cost.
Nostr teaches us that when we keep things simple our protocol designs can be well thought out. And if our protocols are well thought out, they will be complete. And if they are complete, they will be resistant to capture by third parties because there will be little for them to do. The alternative is to follow Nostr and view completeness as an aspiration to be fulfilled by the next big "implementation possibility". This leaves the protocol perpetually at the mercy of powerful, wealthy, or highly motivated third parties who can embrace and extend the protocol to serve *their* purposes.
Nostr also teaches us to take our time and stick to our principles. Instead of rethinking the protocol when faced with the (*entirely predictable*) spam problem, the Nostr community compromised its values of censorship resistance through recentralization via super relays in order to seek continued and immediate growth as a potential Twitter-killer. But in the end success meant failure, as the network undermined its fundamental principles.
If *we* care about *our* principles, it is better to go slow and build something of value that has a chance to stand the test of time.
Having said all that, leveraging Github and an open source philosophy as part of its working process to generate ideas and establish new features provides an intriguing, if risky, method of designing a protocol.
Let's define some principles of Allied Protocols. To do so, we must first know what the principles of the Gemini Protocol are. Not every professed principle may actually count as one. For example, "Gemini is a read-only protocol" contradicts its own 1024 byte upload feature.
I think it comes down to a few things. I call these the **Underlying Principles of the Gemini Protocol**:
1. Simple Connections
2. Text-first & unprocessed Gemtext is human-legible
3. Simple design
4. Restricted design
5. No HTML, No DOM, Javascript
Each of these principles could be expounded upon at length. But let us focus on how these principles resist growth of Gemini beyond human scale.
The simple connections principle means that the user is in control of the connections, not the machine. Since the user only accepts connections which they manually choose, the machine cannot overtake or outpace the user. Each connection produces one document, no more. This allows the user to review the consequences of their activity, and take appropriate action.
(One possible exception here are Feeds updated en-mass in Lagrange, but Feeds are *chosen* and *curated*. Is that good enough to count as following the rules?)
Text-first means Geminspace is human-legible, not machine-legible, privileging human-to-human interaction over machine-to-machine interaction.
Simple design means the protocol is human scale because it can be understood and developed by individuals and small groups.
Restricted design means that a single protocol cannot be extended beyond its initial purpose. One attraction of this is that for every protocol that inches beyond human scale, there will exist a protocol adjacent to it that is closer to Gemini in principle. In the case of a protocol that goes too far, Geminispace can retreat to a similar human-scale protocol.
In rejecting HTTP/S protocol features that help web services scale, Gemini Protocol is designed not to scale. In keeping with this, we should not conceive of technologies with the express purpose of ensuring contents can be sprung upon millions of people simultaneously at the behest of shadowy algorithms. Virality is meaningless in Geminispace.
Simplicity means Geminispace protects user privacy by default. Not through clever use of encryption, or with a proliferation of privacy options and check boxes, but rather in three ways:
1. By making it much harder to embed privacy eroding practices within the protocol itself
2. By keeping things simple enough that the entire transaction can be comprehended at once, which enables average people to make practical privacy choices
3. By resisting web 2.0 algorithmic psychological manipulation that tempts people to compromise themselves
No HTML means no DOM, which greatly erodes the power of Javascript to destroy our privacy, overload our browsers, and make the web fundamentally un-archivable.
All of these taken together prove the Gemini Protocol represents a form a *repudiation of web 2.0*. So long as a protocol adheres to these principles, through *protocol smearing*, we may call it *allied to* the Gemini Protocol. So long as protocols are allied with Gemini, Geminispace becomes stronger. And the stronger Geminispace is the better for individuals and the independent web.
By conceiving Gemini as a bootstrap protocol, we can see that Gemini offers something unusual: **static dynamism**. It is *static* because the Gemini Protocol itself doesn't change, but also *dynamic* because (a) the space of the protocol is large enough to facilitate innovations like Markdown, because (b) everything around it *can* change through innovations in smallweb protocols like Titan that fit directly into Gemini, and because new protocols that *smear* into Gemini can be developed to extend Gemini in new and allied directions--*without losing Gemini*.
So Gemini does not represent the "creative bankruptcy" of the web, or mere "hacker conservativism". It's not a "bespoke hairshirt protocol" meant to pander to "techno-skeptics." It is not just for anti-capitalists, and it is not trying to replace Gopher.
Instead, the Gemini Protocol leads a *Microcosm* of small web protocols which *lean into one another* in new and exciting ways.
2023-08-30 · 9 days ago · 👍 mozz, flipperzero, jcromero, november, aRubes, angryboyd, coderwx, Supernova
Thank you for the detailed essay, it was an interesting read :)
I find myself disagreeing really just on two points: one cosmetic, one important.
The cosmetic point is that I don't think there is appetite for markdown on Gemini. For me at least, writing markdown is too much like work. On my time, I prefer Gemtext :) both reading it and writing it.
More importantly, I can't agree about centralized control being a major problem for the web. The web is currently very good at being what it is; more diversity and choice would be protect against <future> problems, but not change what we have today.
Rather I think what we see is the inevitable result of a many-to-many platform with hundreds of millions of users.
Would Gemini be a fun place if it had a hundred million users tomorrow? I don't think so.
If there's any one problem needs working on to protect the future of Gemini, that gets my vote: people are a problem.
Thanks :)
2023-08-31 · 8 days ago
I think you have some good points, but consider editing down your post! I gave up halfway (have to run) and will try again later, but just as an example, the point that markdown renders to html is made in maybe 5 paragraphs, one after another! I think we get it in the first one.
No disrespect intended, consider it constructive criticism, please.
thanks for this. I bookmarked it to read later and finally had some time.
I like your breakdown of the parts and I think you really get the core tents of Gemini. Framing it as a bootstrap protocol seems to make sense to me. my only concern is splintering. if too many protocols exist and you need 4 or 5 pieces of software to browse Gemini space, it kind of goes against the simplicity. sure, core Gemini is there but to get the 'full experience' we'll end up seeing messages again like "best in internet explorer". currently Lagrange supports most of these things and by including them brings validity and usage to these technologies and unofficial RFCs, but not all browsers include support for things like Titan. I'm just concerned about compatibility. Am I viewing this wrongly?
bemusingly, I had to switch to Titan to finish my long form post...
Also, I liked your run down of Nostr. I saw some folks post about it and when I joined I was a bit appalled with the Bitcoin haven it was with zaps and all that. I was done with it inside of a day. The case study for Gemini is a good one.
overall great article, thanks again for posting.
with your permission, may I repost this elsewhere?
2023-09-01 · 7 days ago
A slight correction: nostr was always Bitcoin-adjacent. Fiatjaf, the person who created it, is a bitcoiner. The public key crypto it uses, secp256k1 and Schnaur signatures, is crypto from bitcoin. I wanna do my own nostr replacement called stonr (pronounced stoner), with a definite anticapitalist flare and inbuilt hostility to corporate sensibility, but it's vaporware so far, because I'm currently trying to convince myself that ActivityPub is the future.
2023-09-04 · 4 days ago