From Newsgroup: comp.infosystems.gemini

Good day,

I was wondering about Gemini, i saw browsers used to navigate through it
and some of the other adjacent protocols and i notice than a lot of the community seems to know and in some cases use IRC, so the question came naturally.

How its the case than the IRC protocol is not used as a complement to
the Gemini protocol so they can cover the issues than one another leave abandoned?

Now, hear me out, i know both protocols were created for different
things but they seems to me like a perfect complement for each other,
let me explain:

- Both, Gemini and IRC when programed for them are simple an very straightforward because they are basically using simple instructions in socket, you aren't doing anything too big or with too much of a hassle
over the line so to need to worrying about some excessive BS like
cookies or such and there is no need for any heavy abstraction over them
which make the work in both of them from a programmatically standpoint
feel very coherent and similar.

- Gemini in his current state cannot support Multi-line text input,
however IRC can and is a way to avoid using POST, PUT or other HTML
based method. What I'm saying here is you can get away with sending an
IRC message instead of POST or PUT in a safe enough way to the GEMINI
server to have an alternative to POST or PUT with minimal hassle, there
are in fact at least a couple approaches than i can think right away
than would allow you to implement this:

A) You could send some cert information in it using IRC straight to the
server together with the rest of the message, you can do this every
message or establish a parallel connection with the GEMINI server itself
in the way of IRC to send several messages than can work as POST or PUT.

B) You could for instance mount the GEMINI service (or daemon, whichever
name you prefer) to also connect to some IRC server and channel as a bot
and make such bot read everything there but only react to the messages
than contains a certain specific watchword assigned between client and
server through the send of the certificate and returned specifically to
the client through the same GEMINI visual page to be understand by the
client. The idea is the Bot will take this message with the watchword
and will consider it a message to the GEMINI server instead of for the channel.

C) I'm certain there are other possible approaches too but all of them
will require at most a couple of new compatibility elements added to the GEMINI protocol in order to make the points of transition to work automatically, which are basically some kind of
Authentication/Identification process in order to keep coherence between actions.

- Put together bot things (IRC and GEMINI) Will allow for a more
community driven experience in the GEMINI space, because if your client require an IRC connection to send data you might aswell make the host of
the site be a bot in IRC and allow both ways interactions:

A) From GEMINI to IRC, the chance to talk with other people who can be
in the same site than you in real time, a thing than HTML doesn't have
by default could be default for GEMINI, making it a lot more community
and interaction driven.

B) FROM IRC to GEMINI, GEMINI allows for, through the simple
introduction and implementation of some possible standard order commands
in the protocol for bots, being able to sail through GEMINI sites and presenting the content of them, again, through the bot to an IRC client, allowing IRC users to actually being able to navigate to sites and other
types of interactions than right now are not possible, without leaving
the comfort of them clients.

I'm right now in disbelieve than nobody has suggested anything like this before, can somebody tell me why? am i crazy or is there something i
haven't seen?

I have done some experiments related to this, have done in the past some
irc bots from scratch using C# and also a very minimal Gemini server
using C#, i think as a proof of concept both projects prove the
potential i'm saying here, i even have some suggested implementations
but let me know what you guys think about and if you guys think is a
good idea, we can talk implementations, if you may, of course.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> wrote:

How its the case than the IRC protocol is not used as a complement to
the Gemini protocol so they can cover the issues than one another leave abandoned?

I'm not convinced this is a great idea. The Gemini protocol, for me,
is about simplicity. It does way with all of the complexity that made
the world wide web the mess it is.

Or, to quote geminiprotocol.net:

"We are out to build a lightweight online space where documents are
just documents, in the interests of every reader's privacy, attention
and bandwidth."

Having to host an IRC server to run a Gemini server isn't simplicity,
and it doesn't seem lightweight to me.

Gemini is about publishing documents, and you don't need things
like query parameters or POST requests for that. I don't think
trying to retrofit features of the world wide web is true to the
goals of the Gemini protocol.

Anyway, just my humble opinion.

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

It seems like you are wanting to bludgeon some kind of Ajax system into
the Gemini protocol. For my part, I have no interest in or desire for
this. I want Gemini to be about serving up simple, elegant hypertext
documents, not creating some kind of asynchronous Web app interface. And
the Gemini protocol itself should remain simple enough that it can be implemented with very simple software programming.
--
Christopher Howard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Well, with all due respect, i read you both but i think you both guys
have the wrong idea of the possible implementations of this proposal
because yes, as Koen correctly says

"Having to host an IRC server to run a Gemini server isn't simplicity,
and it doesn't seem lightweight to me."

That is true, and it would be an issue if that were what i'm proposing,
which is not because we don't need to do that, what i'm suggesting is a
more "parasitic" if you mind, use of the irc servers.

We could simply add a simple instruction in the Gemini document than
indicates where is the bot located and give a wavesign for him to the
client in order for this one (the client) to communicate with it (the
bot), being the wavesign able to be changed daily or so but being the
case that its always shown in the Gemini page, the idea of this is to
identify one specific user of the Gemini capsule without destroying his anonymity, keeping in the act the correlation of identity between the
Gem and the IRC communication, allow me to place an example of such message:

|-#wavesign-#|-#server-#|-##channel-#|-#dataid-#|-#datasended-#|

And thats it, if we use this in the protocol or some variant of it you
could write that in the Gemini capsule and the client know which server, channel and with what wavesign send the data to be received by the bot,
with this you could have a parallel connection for local messaging
without the need to ever install an IRC server, it's technically using
some IRC server of somebody else in a parasitic way of sort but i would
argue than that use would be liked by the people hosting that IRC server
for the most part, at the very least if they approve the use of bots, of course you could use that to make an integrated chat for the gem in some specific server too, making the navigation in GEMINI potentially a more
social experience than http can dream to be, but i digress.

This (interaction between Gemini and IRC) will make a minimal, loginless client to be able to talk between a gem file and an irc server in a
simple, easy and short way, i have one very simple IRC bot myself done
as a proof of concept in C# although i did it to have dices on IRC it
could easily be modified to work with other wavesigns different of those required to run dices.

Bear in mind too that "channel" could be the user nickname for a private bot-client message, avoiding public channels, because that is part of
how the IRC protocol works too so we can make this interaction in IRC
servers in a way than completely avoid public channels if the gem is
establish it that way.

Another possible approach and even lighter is if we just use the
connection message as the standard to send the information, in that case
the bot/gemini server just need to being able to receive the initial communication in irc format straight to a port of himself, but instead
of establish a parallel communication to work as a regular IRC server he
just take that, process the added part of the request similar to a POST
or PUT message and prepare an IRC answer in which wrap the actual answer
to the specific request, we just need to add the wavesign for the bot to receive it in order to identify whom is the author and the rest of it
can be content or IRC protocol, in other words we would be using the
shape of the IRC protocol to establish communication in this case, not
the full implementation, to this approach i call it Fake Communication
Request (FCR onwards).

In both regards IRC is very "grassroots", very lightweight as a protocol
and very simple to implement, and the best part is we don't need that
much added complexity because of that very same reason (both are very
simple to implement) and also, mainly because of the modularity between
the two. This is without mentioning that because the GEMINI capsule was already served when any of this interaction starts, the machine will be
open to any other future interaction, i.e. it can work in his own thread
or in the very same the GEMINI capsule was originally called upon
because up to that point that thread is clean of that interaction, we
don't even need to implement it completely either (the IRC protocol) in
some approaches, as mentioned with the case of using FCR.

This is neither an attempt to put AJAX or anything similar on Gemini
either, i get why Christopher think that tho, because he's probably
thinking "if you are adding something like post, you probably want the
result to reflect immediately" in that regard he's thinking on something
like the old days chats created with AJAX back in the day, i get it, but
i would argue than this is not necessary.

Fist, think about it in the very same idea of the bot that is also a
gemini host, if you really want an update at realtime you dont need to
put an scripting lenguaje on top of it, you could perfectly fine use the
IRC connection interaction, being through an IRC server or through FCR
to send back to the client the instruction of the data change.

Here is an examples that how can the answer be wrapped through any of
those styles of IRC interaction, we could wrap something like this as
the answer to any of those interactions:

|-#wavesign-#|-#dataid-#|-#answer-#|

And that could update somewhere in your Gemini capsule, that open the
question how could you mark the place where the answer should be in the
Gemini capsule?

dataid<

Of course this are only examples, and i havent even mentioned than the
dataid could be separated internally to serve your needs of appling the content at your taste, really, using services which can be both irc bots
and gemini hosters at the very same time is powerful because of the simplicity, you could with the very same backend do very cool operations
for your GEMINI gems avoiding any overbloating because you are working
only with backend in a very limited fashion, all of this very easily
under half a MB or less.

And thats it, the client could make the update if you want to without an issue, no ajax or js used at all only working with simple already there backend in a limited simple fashion designed by you, that very same type
of answer could come wrapped in the IRC connection request too, making
it so than you dont need a parallel continuous communication with the
server necessarily, you can have that, but you can also have a simple
one time requests using FCR in IRC straight to a listening port through
the bot keeping that way the simplicity of the system and keeping the decentralization too.

This open the door to another type of internet too, a much more
console-based one which also empowers the permacomputer approach a lot,
if we can interact with a sort of web through full console we can have a
far more dynamic minimalist web which can be very powerful in emergency because of the lightweight of the very same.

Plus, as also mentioned before, that gives IRC a way to get direct
access to GEMINI sites, which makes IRC a web on his own, you could pass
IRC server A to GEMINI, from GEMINI to IRC server B and such and such,
GEMINI in a way will become "a net of nets" on his owns, curiously enough.

If i'm crazy or wrong please dont doubt in saying it, i appreciate
honest opinions with justification, about the bot and the minimal GEMINI server i have, i would gladly release them under MIT or something so we
can implement this if people think its a good idea. Questions or other comments are also welcomed too and thanks for your time guys.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> wrote:

|-#wavesign-#|-#server-#|-##channel-#|-#dataid-#|-#datasended-#|

I don't know what 'wavesign' is. It's some commercial product according
to my web search?

without the need to ever install an IRC server, it's technically using
some IRC server of somebody else in a parasitic way of sort but i would

So I either have to run my own IRC server or I have to rely on someone
else's IRC server. I'd like my gemini capsule to not have a dependency
on any other service.

If i'm crazy or wrong please dont doubt in saying it, i appreciate
honest opinions with justification, about the bot and the minimal GEMINI server i have, i would gladly release them under MIT or something so we
can implement this if people think its a good idea. Questions or other comments are also welcomed too and thanks for your time guys.

By all means, don't let us stop you from implementing all this, but also
expect the majority of gemini users to not be very interested in this.
The simplicity is the power of the protocol. Adding complex links with
other protocols and external servers to add something that is not needed
(in my humble opinion) is counter to what attracted me to the protocol
in the first place.

Are you aware of the Titan protocol?

https://communitywiki.org/wiki/Titan

It's a companian protocol that allows upload of content for gemini
capsules. It's not been very popular I believe, and looks to have
been abandoned by its original creator.

GmCapsule supports Titan:

https://gmi.skyjake.fi/gmcapsule/

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

I don't know what 'wavesign' is. It's some commercial product according
to my web search?

Its not, another names for it is "parole" in a non judiciary use, and
also called sign - countersign, being the case that it is a word, when
one part says the sign and then the other answer with a countersign,
this allows to both partys to recognize each other as part of the same
group or so, in this case the server/bot gives the countersign and it
doesn't expect a sign, because the sign is the call to the gemini part
of the server.

So I either have to run my own IRC server or I have to rely on someone else's IRC server. I'd like my gemini capsule to not have a dependency
on any other service.

Not really, and i would like for you to let clear to me in which way you
think my approach NEED according to your words an IRC server because in
none of both ways i suggest there is a need for connecting to an IRC
server, there is an optional benefit in one of the routes, yes, but then
there is the other route (FCR) which doesn't require it at all and use
that protocol only as a wrapper for limited interaction.

You really seems to not be aware of how little code is necessary to do
any of those implementations, specially in comparison with mounting your
own IRC server which is a huge ordeal, yes, but that is very far from
this, and it seems you are not really aware of the modal difference
either, so please if it was my writing that would lead to that
confusion, I'll appreciate to show me were that modal confusion is
generated in order to clarify it appropriately.

That being said if you hate the idea by the idea itself, appreciate the
honest advice, but would appreciate too if you just orient me where and
whom are the ones who keep maintained this protocol in order to move my
ideas there, answers rejecting it based on projection and/or misunderstanding/scarecrows aren't exactly useful to no one and at the
end of the day my proposal is to fix with some minimal non-invasive
additions the problem of not having something like post/put, it just so happens than this also add, with minimal intervention, a very big door
of possibilities imho to whomever want to take this approach, which by
design is very optional, again i would really like to see from where you derivate the idea than adding this somehow makes NECESSARY irc.

Are you aware of the Titan protocol?
https://communitywiki.org/wiki/Titan

It's a companian protocol that allows upload of content for gemini
capsules. It's not been very popular I believe, and looks to have
been abandoned by its original creator.

No i haven't, appreciate you send me in that direction tho, in a rapid
reading i can see the reasons of not being used that much, the CGI
thing, the name and the need for another lateral protocol went against
it for certain, but i think it can be beneficial talk to him and see
what he thinks about it, what he remembers of when he tried to do it,
the reason and history of all, so i appreciate the information very
much, thanks.

Cheers,


Obsdark
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> writes:

to fix with some minimal non-invasive additions
the problem of not having something like post/put,

To clarify, is this a correct interpretation
of your idea? What you claim is:

1. Not having support for a POST/PUT feature
is a problem. 2. as a simple problem, it should
be solved simply. 3. IRC is some simple protocol,
it allows sending data. 4. Let's make all Gemini
servers and clients implement IRC, thus allowing
users to send messages to a server.

Is this outline correct? If so, then:

1. Most Gemini users don't think not having
POST/PUT is a problem, in my experience.

2. POST/PUT are not really easy problems, there
are many things to consider and agree upon
between clients and servers. Encoding
things, and compression things, formatting
things, do you allow files to be uploaded,
split into chunks? Is there some protocol
for negotiating the request properties? The
POST/PUT features in HTTP are massively
complex, once you account for all edge cases
needed by all kinds of users and use-cases.

3. IRC is not as simple as you may think. It
is more likely simpler to just extend Gemini
protocol itself than have to bring in all
the complexity of the IRC protocol itself
into every Gemini client.

4. Fundamentally, this is a politics issue, not
a technical issue. What you're proposing is
possible, and anything can be done, if you
really put your mind to it, but Gemini is a
/network/, and with networks come network
effects; you have to play games of adoption.
Convincing developers of server and client
software is not just going to happen. The
usual way is to actually implement the idea
yourself, build the software and let it be
proven useful by the users, other projects
will start adopting the feature if it proves
in demand by users, and the developers don't
hate it. Only real life experimentation can
show us, collectively, all the angles of the
idea, its usefulness, and true limitations.

Also, the idea you're presenting is not very
outlandish or new. Many communities use IRC bots,
or bots on other chat services, like Telegram, to
allow the submission of things by users, providing
various services. Nothing even prevents you from
pointing your users to connect to some IRC server
to submit things, right now. Just add connection
information to your own published texts, and other
users can connect using existing clients and send
you whatever they want. Most IRC clients/servers
even support sending binary files.

Personally, I would think a more interesting
experience is to use such a setup for /chat/, and
not for file uploads. In other words, turning the
gem site into a "place", visiting it would prompt
you to join its IRC channel, and perhaps meet the
author or other visitors. This would be a client
only feature, no need for anything special on the
server. Just some kind of agreed upon string that
you put on your site, and the client would prompt
the user to join a channel when it sees the string
and gathers the connection details from the string
itself. Anyone can create an IRC channel on any
server, and include that string on their page, and
users can join it when they visit the page.

Likely won't happen though, because YAGNI,
plus, most people publishing gemlogs are not there
to have a real-time chat community, with all the
expectations, drama, and moderation requirements
that come with that.

Anyway, Good luck with your IRC idea, if you
decide to implement it, then you might find a few
interested users here, perhaps. Post it when you
have a first working version :)


Best Regards,
Lumin Etherlight
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

To clarify, is this a correct interpretation
of your idea? What you claim is:

1. Not having support for a POST/PUT feature
is a problem. 2. as a simple problem, it should
be solved simply. 3. IRC is some simple protocol,
it allows sending data. 4. Let's make all Gemini
servers and clients implement IRC, thus allowing
users to send messages to a server.

Is this outline correct? If so, then:

Almost, the 4th point is incorrect in a certain grade than can be caused by a misunderstanding, i though my last messages were implicit
enough in the fact than the IRC implementation was partial, minimal and
not complete, although it opens the door to other very interesting interactions i though that in the descriptions of the idea i send before
were clear enough, but being the case that it seems than that wasn't the
case let me clarify point by point everything in order to solve any misunderstanding than can come from this.

1. Most Gemini users don't think not having
POST/PUT is a problem, in my experience.

2. POST/PUT are not really easy problems, there
are many things to consider and agree upon
between clients and servers. Encoding
things, and compression things, formatting
things, do you allow files to be uploaded,
split into chunks? Is there some protocol
for negotiating the request properties? The
POST/PUT features in HTTP are massively
complex, once you account for all edge cases
needed by all kinds of users and use-cases.

Indeed POST/PUT and the like are not really easy problems to solve and for that type of communication yes, you absolutely need to do A LOT of
work, i completely agree with that, that is why my approach plan is not
to implement POST/PUT as such but instead something than is far simpler
and cheaper in code lines, some limited TLS/SSL in the shape of the
already mentioned FCR, let me describe it properly and give some
examples in order to show how and why i think this can be a good
substitute for POST/PUT in the GEMINI protocol case:

first thing first, you put in your .gmi something like this, this
doesn't need to be rendered by the gemini browser at all visually:

|-#signal-#|-#server-#|-##channel-#|-#subsignal-#|

or this (bear in mind than the subsignals are optional)

|-#signal-#|-#<locationurl.something>-#|-#subsignal-#|

and somewhere else you put this, this doesn't need to be rendered
inmediatly by the gemeni browser either, more on that later:

dataid<

This examples will be called for easy reference, marks.

Observation: I'll be using the marks i just propose next as placeholders
to represent the data they content to ease up the understanding of how
would this work.

Now to the explanation:

The first mark work as a location at some server in IRC, the second mark
work as a location to send a TLS/SSL package as an FCR (Fake
Communication Request), i will continue to call them like and use FCR to
refer to them that but i'm open to other names.

In the first case it will said that the bot/server standing there will
be doing some intermediary job, delivering the gem to whomever wants to
see it there (in IRC) and interacting with the specific commands
designed for this in IRC to allow "bot browsing" or IRC browsing, i
would not go deep explaining this because its not the point in this
specific email, however, i would mention than the bot/server would also
be receiving wherever specific data is sended to it using the |-#signal-#|
in the gem from IRC, and it will be showing that data in that specific
.gmi, in the place that it should, in this case that place would be the
one marked with third mark, in other words >dataid<, the reason of this
would be clearer when i explain how the |-#signal-#| works later.

In the second case, you will be sending something to the specific url
and port specified in the |-#<locationurl.something>-#| and through that
the bot/server will be receiving a TLS/SSL call message which will
interact as if it were a post/put or other type of similar call to it,
but far simpler, that should probably look something like this:


|-#signal-#|-#messageItself-#|-#subsignal-#|

which should look in real life like (again, subsignals are optional):

|-#signalOfTheGem-#|-#Hello there from Client!-#|-#ASubSignalOftheGem-#|


And the answer for that signal shall be something like (dataids are
optional)

|-#signal-#|-#dataid-#|-#success/failure-#|


If for some reason it requires more than one answer and/or more than one point, then:

|-#signal-#||-#dataid-#|-#success/failure-#||-#dataid-#|-#success/failure-#|

So it counts any item to the right like linked to the closest |-#dataid-#|
to the left of them. The use of single "|" and double "||" is there to facilitate cut all of that to a string array or similar easier, looking
with that to make easier the extraction of the data to facilitate the communication.

If there was other data than must be received by the client in the
answer other than success/failure, then it shall be send like this in
the relevant cases (in this cases dataid is obligatory, because is the
way to know where the messageItself from the answer shall be showd):

|-#signal-#||-#dataid-#|-#messageItself-#|-#success/failure-#||-#dataid-#|-#success/failure-#|

And then the communication can be closed, its good to mention than the
idea of the signal is to indicate the client to send such signal through
a QUERY as would normally send data in order to the server to recognize
whom is asking without really deanonymize the client user, this allow to
load the answer marks, as for instance >dataid<, with the corresponding
answer data without really forcing the deanonymization of the client. Of course after loading the new call a new signal shall be given through
the gem.

If it is required another new interaction from that point (being the
point than an FCR interaction has already been solved) the new signal
will be added with the last one, only two signals can be added this way
at any given time, this will look like this (again subsignals are optional):

|-#OldSignal_NewSignal-#|-#messageItself-#|-#subsignal-#|

This will allow the repetition of the data present in the old answer to
be repeated in his newest version with the answer data obtained from the
new answer, provided the OldSignal is added together with the new one,
this will indeed make the new answer to become bigger but that is the
cost required to keep anonymity through the call, of course the client
could just ignore this last part and just send the NewSignal as an
original call and just keep the data from the OldSignal in the client
too, the idea is for clients to have both this routes available for any
client to choose between them as they prefer and with wherever criteria
they would prefer.

The idea of sending both signals separated by a "_" is than if any
change pass to the data linked with the OldSignal the client can update
that data as such too if sended this way (|-#OldSignal_NewSignal-#|), but still the choice is given to keep Gemini clients flexible, being the
case those clients, wherever they are browsers, bots or something else
will allow them to work with it in different context as it could be IOT,
IRC, etc.

To activate the sending of such data the client just send a new TLS/SSL
comm to the address referred in this mark which its better if its not
visible in the gem itself:

|-#signal-#|-#<locationurl.something>-#|-#subsignal-#|

As was stated before at the beginning of this explanation.

It should be noted than maybe some text area input windows can be
necessary from the client so to being able to send data without the need
to necessarily mount that text area inputs in some location in the
capsule as HTTP does, as such i'll recommend that the second mark, being
this one:

|-#signal-#|-#<locationurl.something>-#|-#subsignal-#|

Is implemented as a button to press than open a window where you can put content of some nature to send through FCR, being the case than each
subsignal represent a different context of use inside that determined
gem, which to be recognized as such because it have his own proper
signal, therefore allowing several different input windows in different contexts inside the same capsule. If its not obvious, this will allow to
even old forums being able to be worked on in GEMINI.

This way we can have some sort of minimal API/REST behavior without
inputs or forms of anything like that than they have in HTTP(S), this
with minimal intervention and making the GEMINI protocol also far more flexible and interesting to be used in IOT applications, forums and a
lot of other things which were present in the good old web without
deviating from the objectives and boundarys than the GEMINI protocol has intended for itself.

And that is it really, that is the entire size if not almost the entire
size of the proposal, except for bot browsing, which i mentioned very
briefly here but i think that opens his own world and is more command oriented.

Go without saying tho than, as you clearly said:

Also, the idea you're presenting is not very
outlandish or new. Many communities use IRC bots,
or bots on other chat services, like Telegram, to
allow the submission of things by users, providing
various services. Nothing even prevents you from
pointing your users to connect to some IRC server
to submit things, right now. Just add connection
information to your own published texts, and other
users can connect using existing clients and send
you whatever they want. Most IRC clients/servers
even support sending binary files.

Personally, I would think a more interesting
experience is to use such a setup for /chat/, and
not for file uploads. In other words, turning the
gem site into a "place", visiting it would prompt
you to join its IRC channel, and perhaps meet the
author or other visitors. This would be a client
only feature, no need for anything special on the
server. Just some kind of agreed upon string that
you put on your site, and the client would prompt
the user to join a channel when it sees the string
and gathers the connection details from the string
itself. Anyone can create an IRC channel on any
server, and include that string on their page, and
users can join it when they visit the page.

Yes, indeed, a bot will facilitate and make far simpler a lot the
related connection and coding related to implement a chat in the gem,
given the case somebody wants to do that, reducing severely the need for
a true full fledge IRC client in the gem browsers and will allow for
people to meet between each other "in the gem/capsule" far different to
the lonely experience provided from HTTP(S), but although it do
facilitate that by a lot, i also want to notice than that will
facilitate the communication with the gem from a normal IRC client
interacting with the gem through an IRC server without the GEM being an
IRC server on his own at all.

It is also true than the idea is not new because a lot of people use
bridge bots to connect different services every day but i still think
there is a mayor benefit for the GEMINI community to implement this
instead of only placing your channel credentials, because implement this
will:

A) Give access to it to another, new audience, through "bot browsing", a
thing than today is not even possible to do with web 2

B) Give a solution to send/receive data and files which doesn't add up
too much of a hassle.

C) Both the Gemini Protocol and IRC use TLS/SSL so is the very same technology, very coherent in the code style perspective.

D) Give a solution than add a lot of flexibility and a lot of new uses
(bot browsing/data receiving/gem meetings/etc.) keeping thing really simple.

But most importantly, as you notice, if you go now and put some IRC credentials in your gem the only thing you are gonna do is tell everyone
you have an IRC, you can do that with a Discord, a Mastodon or a webpage
even, but so far the Gemini protocol is the only one capable of exploit
the advantage of his simplicity allowing other sources of Gemini
explorers from other sources different than browsers.

Besides right now the only use somebody can assign to the Gemini
protocol is for having something similar to a blog, or an old HTML page
but without anything than requires true interaction, its like forcing by protocol to have a really limited CMS but without the flexibility of
actually using one, and from that perspective all I'm saying is than
with very little additions we can add several other new uses taking
advantage of its simplicity without damaging or forcing changing the old
uses at all and without changing that simplicity or breaking the
approach the Gemini protocol takes for things.

I have done some advances in my IRC/GEMINI bot, its showing promise,
will add the capability to receive all this things i mentioned here and
will released it as a MIT. I agree than i need to put something out
there and its coming together, will let you guys know when that happened
in this thread too.

May you both have a nice day
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

first thing first, you put in your .gmi something like this, this
doesn't need to be rendered by the gemini browser at all visually:

|-#signal-#|-#server-#|-##channel-#|-#subsignal-#|

I'm not going to pretend to understand everything about your proposal,
but this is the most fundamental problem I have with it: I don't want
gemtext documents to have additional markup and, in particular, metadata
added to them. The appeal of gemtext is that it is basically nothing
more than a text document with hyperlinks and a very simple and
not-distracting markup, going to clients that are guaranteed to have at
least UTF-8 support. This is what makes it so distinctive from Markdown
and from HTML, while still allowing for a web (lowercase) of hyperlinked documents and some essential organizational semantics, like organization
into headers.

One of the core values of gemtext is that, if you just dump it to the
terminal or the line printer, it should still be elegant and
human-readable. Nothing should need to be hidden from the reader, or
need to be parsed as special code not intended for the human reader.
--
Christopher Howard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Christopher Howard <christopher@librehacker.com> wrote:

One of the core values of gemtext is that, if you just dump it to the terminal or the line printer, it should still be elegant and
human-readable. Nothing should need to be hidden from the reader, or
need to be parsed as special code not intended for the human reader.

Hear hear. I can dump a gemtext document in a gopher hole and it's
still perfectly legible (module some line-wrapping issues perhaps),
all of it is targeted at humans, not machines.

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

El 13-06-26 a las 02:38, Koen Martens escribi||:

Christopher Howard <christopher@librehacker.com> wrote:

One of the core values of gemtext is that, if you just dump it to the
terminal or the line printer, it should still be elegant and
human-readable. Nothing should need to be hidden from the reader, or
need to be parsed as special code not intended for the human reader.

Hear hear. I can dump a gemtext document in a gopher hole and it's
still perfectly legible (module some line-wrapping issues perhaps),
all of it is targeted at humans, not machines.

Cheers,

Koen

The thing is, you already have metadata on GEMINI, please look at the
initial lines in the added image. So it's kinda already there.

BTW my proposed changes should still make GEMINI compatible with gopher without affecting the already present wrapping issues mentioned before
of course.

https://imgur.com/a/f0evfXU




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

The thing is, you already have metadata on GEMINI, please look at the
initial lines in the added image. So it's kinda already there.

In my view, there is a big difference between putting metadata into a
gemtext document, vs. having metadata in the gemini protocol which
simply specifies the file type and the charset for the file being
downloaded.

If you could explain how to do what you are proposing without making any changes to the gemtext specification, that would be more palatable,
although (for me at least) not any more interesting. The gemini protocol
is, for me, less interesting than the text/gemini document type. But my
general understanding was that the gemini protocol was purposely
designed to prevent or at least resist the addition of new features and extensions to the protocol, as a core value, to keep client requirements simple, and to avoid the privacy abuses of HTTP.
--
Christopher Howard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

El 17-06-26 a las 12:03, Christopher Howard escribi||:

The thing is, you already have metadata on GEMINI, please look at the
initial lines in the added image. So it's kinda already there.

In my view, there is a big difference between putting metadata into a
gemtext document, vs. having metadata in the gemini protocol which
simply specifies the file type and the charset for the file being
downloaded.

If you could explain how to do what you are proposing without making any changes to the gemtext specification, that would be more palatable,
although (for me at least) not any more interesting. The gemini protocol
is, for me, less interesting than the text/gemini document type. But my general understanding was that the gemini protocol was purposely
designed to prevent or at least resist the addition of new features and extensions to the protocol, as a core value, to keep client requirements simple, and to avoid the privacy abuses of HTTP.

Are you seeing what you are saying?

Why do you think that first "20 text/gemini; charset=utf-8" is?

Contrary to your views or believes, in the real world the metadata is
all things you are not seeing than are there in order for the protocol,
any protocol mind you, to work as it should, as a matter of fact the
metadata required is present in any document that subscribe a
determinate protocol and its there because that document follows that protocol, and even more, it have that metadata specifically because that protocol says it should be there for X or Y purpose than the person
doing the document or interpreter want to comply with, being X or Y
something optional or necessary for it to work.

There is no such thing like that difference than you say between
"putting metadata in a gem" and "having metadata in the gemini
protocol", metadata is metadata as dogs are dogs or cats, cats,
its analytically self-evident. They are as they are by the sum an
correlation between them parts and in this case both parts, the protocol definition and document specifications for implementation are part of
what metadata is, metadata as such quite literally is defined in the
protocol in specific ways to be used in the documents who adscribe to
that specific protocol for the finalities than the protocol defines.

I would like you to read this page from the protocol itself:

https://geminiprotocol.net/docs/gemtext-specification.gmi

in the first lines you can find, specifically in the abstract:

"This document specifies the "gemtext" hypertext format. Gemtext is intended to serve as the "native" response format of the Gemini file
transfer protocol, in the same way that HTML is the native response
format of HTTP [RFC7230], although it can be used for any other purpose
for which it is suitable. Gemtext is served via Gemini using the as-yet unregistered MIME type text/gemini.

See also the Gemini network protocol specification"

It even uses the HTML - HTTP references to specify the type of relation,
it basically they says than they both are the protocol, also my proposal
which is an addition was in similar lingo to the gemtext-specification
and additions, mind you, implies that it doesn't modify the things
before it.

Besides i already explain how the new minimal metadata which i propose
here worked and how it keep anonymity without really forcing any capsule
to change.

Aren't you technically savvy enough to add properly that to your gem? or understand it? no matter, don't do it then, in the way i articulate it
its not required to be added to any gem but can be added to any gem to
add functionalities, if added successfully to the protocol new doors are
open for everyone without closing any of the very few that existed
before and without really needing any gem in existence to change unless
they want use this new features of course.

Now i would like you to answer where the definition of all of this is,
besides your feelings of course:

But my general understanding was that the gemini protocol was
purposely designed to prevent or at least resist the addition of new features and extensions to the protocol, as a core value, to keep
client requirements simple, and to avoid the privacy abuses of HTTP.

And as you are in that, would like than you prove how in my proposal i:

1) Destroy the simplicity of it, if you are adding just three lines.

2) Break the "avoid the privacy abuses of HTTP".

3) Where is written than "it was purposely designed to prevent or at
least resist the addition of new features and extensions to the
protocol" in any of the relevant documents of the protocol, with a
citation too.

Here, i give you the relevant links and i want you to show me where
those things are broken in my proposal citing the protocol documents and
what i already written and presented as a proposal, because i assume i'm talking with an adult which his opinion, specially at this point in his
life shall already be based in more than personal feelings and personal baseless interpretations.

Have a look at the documents:

https://geminiprotocol.net/docs/protocol-specification.gmi

https://geminiprotocol.net/docs/gemtext-specification.gmi

And before you add the FAQ there, let me answer you that citing the very
same FAQ because i doubt you will use the quotes in there in good faith, therefore i'm taking two points in there that prove than my point is
perfectly feasible and my proposal reasonable, even if you "don't feel
them":

STARTING QUOTE

1.11 I bet eventually there'll be a Gemini v2.0 with cat GIFs and banner
ads and infinite scrolling

No way, no how, not never, at least not on our watch.

It's not just there are no plans to officially make Gemini any more
powerful than it already is. Design decisions were actually made since
day one to make future extensions as difficult as possible. We know
nobody can be forced to implement our specifications exactly to the
letter, and we know that "embrace, extend, extinguish" happens to
technologies all the time. We've done our best to preemptively fight
back against this, in more ways than one.

Sometimes people are shocked, and strangely enough sometimes even angry,
at how minimalistic Gemini seems, and they wonder why anybody would deny themselves some harmless seeming little features that web users are used
to seeing every single day. More often than not, this preemptive fight
against extension is the reason. The average Geminaut isn't some kind of fanatical ascetic, trying to resist temptation in order to purify their
soul or anything weird like that. We just think that what we have right
now is something pretty special, we'd hate to see it slowly eroded over
the years as well-meaning changes end up pushing us down slippery
slopes, and we think it's worthwhile giving up some small luxuries to
reduce the odds of that happening, even a little.

1.12 So it's completely 100% finished, then?

Not quite. There are still some technical details for the geeks to work
out with regard to how some things work from behind the scenes. It's not exactly minor stuff, and if you're a programmer who might be interested
in implementing Gemini software you should keep an eye on things. But
from the perspective of a regular end user, Gemini is finished. It's
very unlikely than new features that would matter to you as somebody
either reading or writing pages in Geminispace will be added during the finalisation process. If any do squeeze in, you can be sure that they'll
be minor. So you should feel confident that you can dive in to reading
and writing today, and the whole thing won't shift violently under your
feet next year and become unfamiliar. Today's overall user experience is
here to stay.

END QUOTE

I'm complying with everything that its said in the 1.12 without going
against or breaking anything which the 1.11 is trying to protect, i'm literally going for a small set of minor addition than, as stated, add
things, keep the minimalist approach and security of it all with his
implied simplicity without the need for the regular end users to make
any change, its also compatible with the architectures and programming knowledge required already for implement a protocol like this, as an
added and unrequested bonus.

You also said:

The appeal of gemtext is that it is basically nothing
more than a text document with hyperlinks and a very simple and not-distracting markup, going to clients that are guaranteed to have
at least UTF-8 support. This is what makes it so distinctive from
Markdown and from HTML, while still allowing for a web (lowercase) of hyperlinked documents and some essential organizational semantics,
like organization into headers.

One of the core values of gemtext is that, if you just dump it to the terminal or the line printer, it should still be elegant and
human-readable. Nothing should need to be hidden from the reader, or
need to be parsed as special code not intended for the human reader.

Now, meanwhile you are into answering the questions i leave before, how
about if you also prove, as in, provide evidence, on how my additions
break anything in what you mentioned here, because again i assume than
you, as a functional adult, work based on evidence instead of feelings
but you haven't prove that so far yet.

Prove it first, any of the things you say about my proposal and then
i'll attempt to fix those issues, if they exist at all of course, will ya?

Also i will gladly answer any of your doubts or clarify any of the for
you too obscure things than are difficult for your understanding of it, provided of course you can formulate them as specific questions or
specific request for clarifications with reference to the texts
mentioned here.



May you both have a great day

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> writes:

El 17-06-26 a las 12:03, Christopher Howard escribi||:
Why do you think that first "20 text/gemini; charset=utf-8" is?

Maybe I'm missing something, but "20 text/gemini; charset=utf-8" is not
part of the text/gemini document rCo it is the server indicating what kind
of document is served, and what the encoding is. None of the text/gemini
files stored on my server or on my personal computer have "20
text/gemini; charset=utf-8" stored in them.

There is no such thing like that difference than you say between
"putting metadata in a gem" and "having metadata in the gemini
protocol",

First of all, I never said "putting metadata in a gem". Your use of the
word "gem" is ambiguous. I said don't put metadata in the gemtext
document. The gemtext document, or text/gemini, is distinct from the
gemini protocol. The gemini protocol can serve any kind of document or
file, including HTML.

Like I said, if you leave the gemtext document specification untouched,
with no additional metadata added to gemtext documents, the idea you are proposing would be more palatable, though so far nothing about them has
seemed to me either interesting or appealing. On that latter point,
perhaps you could explain again rCo limiting yourself to one or two
paragraphs rCo exactly why the proposed changes are necessary and
beneficial, i.e., what we get out of it in the end. And then also
confirm that there is no added complications for implementing gemini
clients that are not interested at all in said features.
--
Christopher Howard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

El 19-06-26 a las 18:29, Christopher Howard escribi||:

Obsdark <kulturu01@gmail.com> writes:

El 17-06-26 a las 12:03, Christopher Howard escribi||:
Why do you think that first "20 text/gemini; charset=utf-8" is?

Maybe I'm missing something, but "20 text/gemini; charset=utf-8" is not
part of the text/gemini document rCo it is the server indicating what kind
of document is served, and what the encoding is. None of the text/gemini files stored on my server or on my personal computer have "20
text/gemini; charset=utf-8" stored in them.

Yes you are missing something, that is part of the text/gemini document
you might haven't place that there manually by yourself but wherever
hosting software you are using for hosting your capsule is doing that
for you, so yeah, its technically part of the document, it should be in
and added by yourself in case you do all of that manually and the fact
than the hosting software save you from the work of putting it manually doesn't change that fact.

That is part of the data the client software will receive when calling
for a gemini site, it is, in fact, what tells the client software
-whichever software that is- than that specific document is, in fact, in compliance with the gemini protocol and yes that is data than the server
sends to you consistently not to be shown to you but to set things
straight with the client, in this case in the very first line, which is
the hole point of metadata.

There is no such thing like that difference than you say between
"putting metadata in a gem" and "having metadata in the gemini
protocol",

First of all, I never said "putting metadata in a gem". Your use of the
word "gem" is ambiguous. I said don't put metadata in the gemtext
document. The gemtext document, or text/gemini, is distinct from the
gemini protocol. The gemini protocol can serve any kind of document or
file, including HTML.

In fact that is not true, the gemini protocol cant serve any kind of
document, its a protocol, a format if you will or a set of
compromises/rules who determine what to expect and how should it be a
document than comply with said protocol, if you serve a document to the internet, whichever document in whichever specific protocol you choose,
that protocol is there to say to the client application what to expect
and how to interpret his content, the same goes for gopher and http(s).

What serves documents on the internet is the hosting software, whichever software you choose to use for that purpose, and the compliance with the protocol is what allows the client application to know how to interpret
and where to find (in terms of ports for instance) such document, at the
end of the day any protocol is just a set of definitions and rules than
are decided in order to make documents created in compliance with it
able to be consumed, whichever that protocol will be and for wherever
purpose they may the server and client software devs works with that to
define how to make his applications to talk to each other correctly in
the context of such documents, that is literally the purpose of any
protocol out there.

Like I said, if you leave the gemtext document specification untouched,
with no additional metadata added to gemtext documents, the idea you are proposing would be more palatable, though so far nothing about them has seemed to me either interesting or appealing. On that latter point,
perhaps you could explain again rCo limiting yourself to one or two paragraphs rCo exactly why the proposed changes are necessary and
beneficial, i.e., what we get out of it in the end. And then also
confirm that there is no added complications for implementing gemini
clients that are not interested at all in said features.

I added details about all of that in the original answers in long but i
would resume the direct benefits:

Having a simple, code-style-compatible, way to do a lot of the things
you could do in the old web and a lot of new use cases where html just
don't cut well the use case and Gemini with my addition, not
modifications, additions, mind you, will cut it better than html without breaking or twisting the values and objectives the Gemini protocol was intended for.

As simple as that.

For instance, controlling applications remotely, IOT, Hybrid navigation,
old web stuff and a lot of other things will become far simpler to
implement, far cheaper in terms of network uses (which can translate to
money) and far more flexible to implement because they became easier to implement using one protocol instead of another, being that other
http(s), therefore the move will open the door to increased adoption in development space and being able to spread in uses which http(s) is
taking partially the role but is demonstrably worst for it.

One good case but nowhere near the only one of that is IOT where you
could save a lot of network use presenting far smaller pages using
gemini protocol not only for present information but also for generate interaction if my additions are approved, not only that but the need to implement a far simpler protocol also reduce the attack vectors over the servers because they will not need to comply with all the rest of the BS
than the web (https) servers present.

In short, it will make the Gemini protocol useful in the real world for
other things than aren't just show a gopher site with colour and some
symbols because lets face it, right now the Gemini protocol does
basically only that and competes with gopher and with Http(s) in that,
which for both are one of, if not the really strong suit for show
content nowadays.

Both gopher and HTML have a better grasp to show content because the
Gemini protocol also is forced to go through insecure workarounds to
generate minimal, and very limited interactions with very little
security so objectively speaking, right now the Gemini protocol is
playing the worst game it could for adoption, however if my additions
are added it not only fix those issues but it will also open a far safer
door and open far more uses with again, minimal additions.

Additions, mind you, than as such do not disrupt the capsules already
working in the same way than when you add a chapter to a book it doesn't
alter the already written chapters in that book, it may resignify them,
but it doesn't change the written letters on it, that is the basic
concept of additions in documents and is just as basic as the reason why
it will not impact already existing capsules.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> wrote:

For instance, controlling applications remotely, IOT, Hybrid navigation,
old web stuff and a lot of other things will become far simpler to implement, far cheaper in terms of network uses (which can translate to money) and far more flexible to implement because they became easier to

Controlling applications remotely, IOT, money, that's what gemini, if
I'm not mistaken, wanted to leave behind. Please don't introduce all
that crap into something that is fine without it!

One good case but nowhere near the only one of that is IOT where you
could save a lot of network use presenting far smaller pages using
gemini protocol not only for present information but also for generate interaction if my additions are approved, not only that but the need to implement a far simpler protocol also reduce the attack vectors over the servers because they will not need to comply with all the rest of the BS than the web (https) servers present.

If you're using https to do IoT, you're doing it wrong, imho. There are
far better protocols already for that, no need to force the gemini
protocol to be that. For eg, mqtt or CoAP/CoIoT. Wifi is bad for IoT
anyway, not a good fit for constrained devices.

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

You continue to confuse the difference between the Gemini protocol and
the Gemini document type. They are different: they have different specs,
and they have different purposes.

Yes, the Gemini protocol can serve any document or file type whatsoever,
so long as there is MIME type to describe it. Even if there was no
appropriate MIME type, the document still could be served with application/octet-stream though the client wouldn't know how to
interpret it.

The transmission "20 text/gemini; charset=utf-8" is not part of the
gemtext hypertext format. The spec for gemtext specifically says that
the gemtext is "served via Gemini [the protocol] using the as-yet
unregistered MIME type text/gemini". "20" refers to the status code,
which has nothing to do at all with the contents of the document, and
the rest is metadata identifying the type and encoding of the document.

Obviously it is necessary, in some way or another, to communicate (or
assume) the type of a gemtext document and the encoding of it. We can
call that metadata. But doesn't mean that we have slipped metadata into
the document itself.

Even if we did think it was necessary or desirable to have the MIME type
and encoding in the gemtext file, like in a magic byte or shebang, it
wouldn't follow that we need to have any other metadata in the gemtext
file. Document type and encoding are necessary metadata or assumptions.

Also, I reject the goals you described in your last post. It is not a
worthy goal to increase adoption of the Gemini protocol or the gemtext
document format by trying to change and twist it into something suitable
for "controlling applications remotely, IOT, Hybrid navigation, old web
stuff and a lot of other things".

What is the aim of the project? From the FAQ:

In a word, reading!

Reading text with a simple, clear, uncluttered layout without any
animation or embedded videos or sidebars full of distracting,
unrelated extras. If you use the "Reader Mode" in your web browser a
lot and you love it because you think that 99% of the time it makes
webpages ten times easier to use by throwing out all the useless
clutter and just giving you what you want, you'll probably be excited
to hear that everything in Geminispace looks that way all the time by default.

The FAQ also explains that Gemini was designed with different principles
in mind from what you are promoting:

The reason Gemini looks strange is that it wasn't designed according
to "usual" principles, such as:

rCo Make sure it can do as many different things as possible rCo Make sure
it appeals to the widest possible audience rCo Make sure it can have
extra features added gracefully at any time rCo Make sure it can
effortlessly scale up to the entire planet

We had very different ideas in mind.

Please also see section 4.2.3 Non-extensibility.
--
Christopher Howard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

El 22-06-26 a las 13:47, Koen Martens escribi||:

Obsdark <kulturu01@gmail.com> wrote:

For instance, controlling applications remotely, IOT, Hybrid navigation,
old web stuff and a lot of other things will become far simpler to
implement, far cheaper in terms of network uses (which can translate to
money) and far more flexible to implement because they became easier to

Controlling applications remotely, IOT, money, that's what gemini, if
I'm not mistaken, wanted to leave behind. Please don't introduce all
that crap into something that is fine without it!

You say that? Ok, prove it then, where does it say than the objective of
the GEMINI protocol is leaving specific use-cases behind? Where are
those use-case listed?

NOWHERE.

If I'm wrong, please, show me the proof of it, otherwise i would suggest
you stop projecting yourself in that.

One good case but nowhere near the only one of that is IOT where you
could save a lot of network use presenting far smaller pages using
gemini protocol not only for present information but also for generate
interaction if my additions are approved, not only that but the need to
implement a far simpler protocol also reduce the attack vectors over the
servers because they will not need to comply with all the rest of the BS
than the web (https) servers present.

If you're using https to do IoT, you're doing it wrong, imho. There are
far better protocols already for that, no need to force the gemini
protocol to be that. For eg, mqtt or CoAP/CoIoT. Wifi is bad for IoT
anyway, not a good fit for constrained devices.

Cheers,

Koen

MQTT works using binary and is architecturally unflexible, his use-case
is not related to human interaction. CoAP by the other hand keep the
things in a layer of extra complexity and need proxys to be compatible
with http to, for instance, have direct interaction with humans, and
also work over UDP which is not reliable on itself.

Funnily enough Gemini will stay as a point in between CoAP and MQTT,
because being TCP and requiring (not optional as MQTT) the use of TLS
makes it safer than MQTT, which i think is the right move, also its
possible to read it in a human language and use, at the same time, human controls over cheap comms, this makes it already win over http.

One of the best things is you can avoid the HTTP/CoAP ApiRestFull for something far, far, simpler and smaller using a direct hand of TCP, in
other words Gemini will present itself as "the best of the three worlds"
than without being an absolute replace for 2 of them will present itself
as an solid-enough in-between, all of that provided for the simplicity
of itself and his architectural flexibility which those others do not
really have (except http), and that is just one of the use-cases.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> writes:

You say that? Ok, prove it then, where does it say than the objective
of the GEMINI protocol is leaving specific use-cases behind? Where are
those use-case listed?

With the Gemini project, you are free to explore whatever use cases you
would like, so long as you don't try to transform the protocol or the
document type into something that goes against the core aims of the
project. The protocol is designed purposely to avoid being extended, to
avoid this sort of feature creep, to keep client programming simple, and
so forth. The gemini hypertext format is purposely designed to be
simple and elegant for the human experience of reading.

The idea you mentioned rCo if I understood it right rCo of coming up with
some kind of simple interface to devices that isn't as nasty as a Web
interface rCo sounds appealing. If you think the gemini protocol and the
gemini hypertext format gives you something close to what you need for
that, great. But obviously gemini doesn't work for you, in the form in
which gemini was meant and designed to work.

If your goal is specifically to come up with an interface for devices, I
would recommend that you just take the gemini specs, alter them as
desired, and slap a new name on them.

If your goal is to turn gemini pages into some thing like an Ajax Web
app, or add those to the Gemini experience, please go away.
--
Christopher Howard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Christopher Howard <christopher@librehacker.com> wrote:

What is the aim of the project? From the FAQ:

In a word, reading!

Reading text with a simple, clear, uncluttered layout without any
animation or embedded videos or sidebars full of distracting,
unrelated extras. If you use the "Reader Mode" in your web browser a
lot and you love it because you think that 99% of the time it makes
webpages ten times easier to use by throwing out all the useless
clutter and just giving you what you want, you'll probably be excited
to hear that everything in Geminispace looks that way all the time by
default.

Quite so.

Please also see section 4.2.3 Non-extensibility.

1.11 is relevant in this light as well.

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gemini

Obsdark <kulturu01@gmail.com> writes:

You say that? Ok, prove it then, where does it say than the objective
of the GEMINI protocol is leaving specific use-cases behind? Where are
those use-case listed?

NOWHERE.

A lot of this kind of thing was argued out on the Gemini mailing list,
before the mailing list server went down. There may be available
archives.
--
Jason McBrayer | rCLStrange is the night where black stars rise, jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.rCY
| rCo Robert W. Chambers,The King in Yellow
--- Synchronet 3.22a-Linux NewsLink 1.2