💾 Archived View for gemi.dev › gemini-mailing-list › 000384.gmi captured on 2023-11-04 at 12:45:45. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

-=-=-=-=-=-=-

[ANN] Scalar, an experiment for a minimalist chat protocol inspired by Gemini

Simon Heath <icefox (a) dreamquest.io>

Hi, all.  Pardon me if this is a little off-topic, it was suggested I
share this here.  I got annoyed at Matrix's complexity and IRC's
idiosyncracies, and said "I wish there were something like Gemini for
chat protocols".  So I decided to take a weekend and try to make
something like that, and after going over my time budget by a factor of
eight or so I ended up with something I call Scalar: 
https://sr.ht/~icefox/scalar/

It's very WIP still, but there's a minimum viable product specification
and implementation, with much more emphasis on "minimum" than "viable".
However, it's proof that the idea works, and carrying on the design of
the protocol is pretty straightforward. I can't *quite* bring myself to
design something as hardcore minimalist as Gemini, but I still hope it
meets Gemini's design criteria.  No idea if I will keep working on it
in the immediate future, but maybe it will inspire interesting
discussion.

Thanks a lot,
Simon

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Simon Heath once stated:
> Hi, all.  Pardon me if this is a little off-topic, it was suggested I
> share this here.

  A bit off topic, but I don't mind.  I can't answer for others though.  

> I got annoyed at Matrix's complexity and IRC's
> idiosyncracies, and said "I wish there were something like Gemini for
> chat protocols". ...
> I ended up with something I call Scalar: 
> https://sr.ht/~icefox/scalar/
> 
> It's very WIP still, but there's a minimum viable product specification
> and implementation, with much more emphasis on "minimum" than "viable".

  Very minimum, and it doesn't even both with DNS SRV records.  The use of
CBOR is neat (I think it's underrated personally) but you seem to be having
second thoughts about it:

	 One of the annoying things about CBOR is the variable-length
	encoding means it's hard to know what the heck you're doing with
	this until you've actually encoded your message.

  I don't understand what you complaining about here.  Is it the fact you
don't know how much space to use when encoding?  When decoding?  How do
decode in a language like Rust of C that make it difficult to deal with
dynamic data?

	Blob?: Now that I think of it, not sure there's anything terribly
	wrong with sticking small binary data in a message or such? CBOR can
	distinguish the two, though it's a bit of a pain. Consider it.

  Actually, that's one of the easier things to deal with because TEXT is
distinct from BIN in CBOR.  

    /// ALSO TODO: It might be nice to use serde's "internally tagged" 
format, for brevity, but
    /// that messes up with `cbor_serde`'s packed format, probably because 
serde's tags want to be
    /// strings and cb's packed format wants them to be integers.  We may 
just be hitting the
    /// limits of serde, cbor, or both.  Keep thinking about it!

  CBOR tags are integers, but they are semantic tags, not name tags. 
They're there to say "the following string is to be used as a timestamp in
RFC-3339 format" or "the following binary string is a positive big integer". 
I get the feeling you think tags are supposed to be like field names.

> However, it's proof that the idea works, and carrying on the design of
> the protocol is pretty straightforward. I can't *quite* bring myself to
> design something as hardcore minimalist as Gemini, 

  Gemini is basically HTTP/0.9 with 2 digit status codes.  Hardcore
minimalist is Gopher, which doesn't support MIME types, nor status codes.  A
hardcore, minimalist chat protocol would be "one server, one 'room'
everybody chats in."  I've done that in 100 lines of Lua.

> but I still hope it
> meets Gemini's design criteria.  No idea if I will keep working on it
> in the immediate future, but maybe it will inspire interesting
> discussion.

  Perhaps.  But as it stands now, there's not enough to even make a
"proof-of-concept".  Well, maybe, if one just goes ahead to design the
protocol themselves.

  Another comment I have is the use of DNS SRV records.  It's a great idea
(I like it personally) but it makes it just that much harder to use as a
protocol.  Setting up a Scalar server also means updating DNS records.  As
someone who runs their own DNS infrastructure [1] it's easy for me to add
SRV records.  I don't know about that in general (someone else might have to
speak up about that).

  Second, using SRV records in a client isn't easy either.  There's a
(POSIX) standard function getaddrinfo() for returning an A or AAAA record
(IP address), but not one for SRV records.  I think libc on Linux contains
functions one could use to get SRV records, but I don't know off the top of
my head what they might be.  I know there are libraries out there that can
deal with SRV records, but most are crap [2].

  Gemini's only real external requirement is a library for TLS.  So far,
Scalar requires CBOR and DNS, so it might not be so simple.

  -spc

[1]	Yes, I do.  I even had a hand in setting up my server provider's DNS
	infrastructure.  

[2]	I'm biased here.  I looked into half a dozen DNS libraries and found
	them all to be pure crap.  That's why I ended up writing my own [3],
	like I do [4].

[3]	https://github.com/spc476/SPCDNS

[4]	I even have a CBOR library:
	https://github.com/spc476/CBOR

Link to individual message.

Jason McBrayer <jmcbray (a) carcosa.net>

Simon Heath <icefox at dreamquest.io> writes:

> Hi, all.  Pardon me if this is a little off-topic, it was suggested I
> share this here.  I got annoyed at Matrix's complexity and IRC's
> idiosyncracies, and said "I wish there were something like Gemini for
> chat protocols".

So, I'm pondering this, and wondering ? is IRC then the Gopher of chat
protocols? Could you give a quick summary of what your proposal offers
beyond IRC?

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

Link to individual message.

---

Previous Thread: Genini requests with ncat

Next Thread: Fwd: [ANN] New gtk client, with colors